66v Forever

CPU상에서의 스키닝 처리

x66vx — Tue, 29 Jul 2008 05:39:16 GMT

셰이더를 꼼지락 거리기 시작하다가 나에게 다가온 첫번째 시련은
'스킨 메쉬'였다.
이게 사실 예정에 없던 거였는데,
덩키형 프로젝트에 셰이더만 제공하고 빠질 계획이었는데,
마침 그 게임이 스킨메쉬를 쓰고 있었던것 -_-

셰이더에서 스키닝을 하는건 별 문제가 되질 않았다.
하지만, 셰이더를 하나씩 하나씩 추가할때마다
일일이 스키닝용 셰이더를 별도로 만들어야 하고,
그 많은 행렬연산을, 그릴때마다 했던짓 또하고 또하고 하는게
심히 낭비라고 생각되었다.

이런저런 궁리를 하다가 결국 CPU상에서 스키닝 계산을 한번에 끝내고
셰이더로 들어가는 부담을 줄이자는 결론에 이른다.

일단 삽질끝에 스킨메쉬의 정점 정보 저장용 데이터구조를 만들고,
for문을 돌려서 D3DXVec3TransformCoord() 로 정점에 행렬, 가중치곱을 다 해줬다.

근데 속도가....

30프레임 나오던넘이 5프레임이 나오는건 뭔가 -_-...

여기저기 돌아다니다가 GPG(www.gpgstudy.com) 에서
무슨 SSE니 뭐니, 히트율이 어쩌구 저쩌구 하는 소리를 들어보니
결국 CPU상에서 원만한 행렬연산을 하기위해선
데이터 구조 작성부터 연산과정까지 최적화를 해줘야 한다는 사실을 깨달았다.

그런 지식이 있을리가.
그 시점에서 깔끔하게 포기하고 손놓고 있었는데....

오늘 우연히 요 자료를 발견하게 된다.

Optimized CPU-based Skinning for 3D Games
http://cache-www.intel.com/cd/00/00/17/21/172124_172124.pdf

씹휴 스키닝을 위한 최적화... -0-

이제서야 발견 되어도 이미 늦었다고!

어쨌든 나중에 다시한번 씹휴 스키닝을 손 대게 된다면
저 자료로 공부해서 도입시켜 봐야지.

(그래도 솔직한 심정에 GPU로 다 스키닝 돌리는게 속도도 더 잘나오고 속편하다고 본다 -_-
어지간히 셰이더 패스가 많이 않는 이상은.)

윈도우 사이즈 지정

x66vx — Wed, 16 Jul 2008 02:30:47 GMT

우선 해결하는데에 도움을 받은
http://blog.naver.com/wzblue?Redirect=Log&logNo=10033054847
암흑햏자님께 감사드립니다.

윈도우 사이즈를 대충 지정하다가
타이틀바, 좌우엣지 때문에
클라이언트영역 크기가 지정 수치보다 작게나와서
백버퍼 크기 짐작에 큰 애로사항을 겪은 기억이 있는 바,
클라이언트 영역을 원하는 수치로 지정하고자 한다.

문제가 발생하는 코드>
    // Application Window를 생성한다.
    _hWnd = CreateWindowExW(0L, kWindowClass, kWindowTitle, WS_OVERLAPPEDWINDOW,
                                       (GetSystemMetrics(SM_CXSCREEN) / 2) - (kWindowSizeX / 2),
                                       (GetSystemMetrics(SM_CYSCREEN) / 2) - (kWindowSizeY / 2),
                                       kWindowSizeX,
                                       kWindowSizeY,
                                       GetDesktopWindow(), NULL, _wc.hInstance, NULL );

우리가 원하는 것은
클라이언트 영역 크기를 kWindowSize로 잡는것이다.
하지만 CreateWindow함수는 윈도우 영역 크기만을 인자로 받는다.
즉, 타이틀바, 좌우엣지크기를 받아와서 kWindowSize수치에 더해주는 작업이 필요해지게 된다.

윈도우영역 가로폭 = 클라이언트영역 가로폭 + 좌엣지 + 우엣지
윈도우영역 세로폭 = 클라이언트영역 세로폭 + 상엣지 + 하엣지 + 타이틀바

이렇게 교체하면 되고, 프레임 크기를 얻어오는 함수를 써서 위의 식을 적용시키면
코드는 다음과 같이 된다.

개선 코드>
(GetSystemMetrics(SM_CXSCREEN) / 2) - (kWindowSizeX / 2) - GetSystemMetrics(SM_CXFRAME),
(GetSystemMetrics(SM_CYSCREEN) / 2) - (kWindowSizeY / 2) -
                            ((2 * GetSystemMetrics(SM_CYFRAME) + GetSystemMetrics(SM_CYCAPTION)) / 2),
kWindowSizeX + 2 * GetSystemMetrics(SM_CXFRAME),
kWindowSizeY + (2 * GetSystemMetrics(SM_CYFRAME) + GetSystemMetrics(SM_CYCAPTION)),

ShadowMap

x66vx — Wed, 02 Jul 2008 03:18:13 GMT

결국 볼륨섀도우 축퇴사각형(degenerate quad) 작성 알고리즘의 문턱에서 포기를 하고
(스킨메쉬에 적용시킬려니 스키닝 연산을 줄일 방도가 없었다...
메쉬를 별도의 정점버퍼에 복사해서 CPU상에서 프레임마다 한번씩 일괄적으로 스키닝 연산 후
Lock-Unlock 한방에 메쉬정점을 교체했는데, 락-언락보다
정점 갯수 만큼의 행렬 연산이 너무 시간이 많이 걸려서-어떻게 연산을 최적화 해야하는지도 잘 모르고-
CPU상에서의 처리는 결국 포기 ㅠ.ㅠ)
섀도우 맵으로 넘어왔다.

섀도우맵을 읽는 UV좌표 설정부분에서 살짝 막히긴 했지만,

결국 어제 렌더까지는 성공시켰다.

우훗! 좋은 계단!

...

뭐 섀도우맵의 가장 큰 단점이 앨리어싱이란건 익히 알고 있었으나
과연 ㄷㄷㄷ

그에따라 섀도우맵의 앨리어싱을 극복하고자 수많은 알고리즘들이 개발되었으나
아직 현재진행형이라 할만하다.

섀도우맵에 쓰이는 안티앨리어싱 기법은 크게 두 분류로 나누어 볼 수가 있겠다.

첫번째, 라이트 프러스텀을 조작하여 최대한 효율적인 섀도우맵을 획득하는 방법.

두번째. 섀도우맵으로부터 값을읽어서 그림자를 색칠할때 주변값들과 보정시키는 필터링.

전처리, 후처리라 할만하도다.

먼저 내용 이해가 쉬웠던 후처리부터 들어가자면,
ShaderX2 에 소개되어 있는 PCF(Percentage Closer Filtering),
nVIDIA 에 공개된 VSM(Variance Shadow Map : 편차 그림자 지도...)이 있겠다.
(사실 이거밖에 모름 ㅇ.ㅇ;; )
VSM 문서에는 DSM(Deep Shadow Map)이란놈도 소개되어 있는데,
문서 찾아봤다가 이건뭐.. 그냥 잊어버리는게 정신건강에 좋을것 같다.

PCF에 쌍선형(Bilinear)필터를 적용시키면 꽤 좋은 품질의 안티앨리어싱을 걸 수 있는데,
VSM문서에서는... 비싸댄다 -_-;
그래서 일단 후처리는 VSM만 믿고 가볼까 한다.

VSM은

[그림출처 : nVIDIA VSM문서. 좌측이 분포함수, 우측이 누적분포함수]

누적분포함수를 응용하여 주변색에 필터링을 거는 방식으로,
더이상의 자세한 설명은 엔비댜 문서를 참고하시고잉,
요걸 최대한 간결하게 후처리용으로 써볼까 한다.

이제 최대의 문제는 전처리.
아무것도 하지않고 그냥 광원시점의 거리값을 그대로 텍스쳐에 보존한게 SSM(Standard Shadow Map)이고
현재 내가 구현한게 요놈. 결과는 뭐 보시는대로 -_-

이 다음부터는 PSSM문서를 보면 차이가 느껴진다.

[그림출처 : PSSM문서. 요것만 보면 PSSM이 킹왕짱이다(뭐 실제로도 따지고 보면 그렇다 -_-; ) ]

PSM은 광원시점 절두체(라이트 프러스텀...이라고 하자)를 변형하여
섀도우 맵의 효율을 높이는 방식인데, 이후에 등장한 LiSPSM, TSM역시 기본 이념은 동일하다.
단지 라이트 프러스텀을 어떻게 변형해서 최대의 효율을 이끌어내는지의 차이가 존재한다.

이제 막 SSM을 구현했을뿐이기에,
아직 PSM의 기본개념조차 파악 못한 꼬꼬마라,
더이상의 설명은 불가능하리라 싶다.

LiSPSM은 이름처럼, PSM의 개선판이고,(도대체 라이트 공간이 뭐여? -_-;)
TSM은 사다리꼴 형태로 프러스텀을 변형시킨다... 정도만 알고있다.
TSM은 프러스텀과 상관없을수도 있다.(내가 잘 모르는거지뭐.)

그리고 PSSM... 구간별로 나눠서 처리를 하고...
CSM이란것도 있던데. 에휴.

공부해나가면서 알게 되면
기록이나 끄적끄적 남겨야겄다.

-----------------------------2008년 7월 8일 추가분-------------------------------------------------------

PSM(Perspective Shadow Map)

PSM은 일단 카메라 시점을 기준으로 월드-뷰-프로젝션 변환을 일단 한 상태에서 시작한다.
프로젝션 변환을 한 상태이기때문에
카메라에 가까운 부분은 크게, 먼 부분은 작게 쪼그라 든 상태이다.
이걸 포스트-퍼스펙티브(post-perspective)상태라 하는데,
월드 공간자체가 뒤가 좁게 쪼그라 든 상태라,
다시말하면 뷰프러스텀은 정육면체(실은 z축 길이는 0~1까지라 절반밖에 안되지만...)로
변형된 퍼스펙티브 공간이다.

[ 그림출처 : PSM문서. 그냥 월드-뷰-프로젝션(일명WVP)변환을 했을 뿐이다. 뭘 거창한 이름을 붙이고 그래... ]

여기서, 디렉셔널 라이트의 경우엔 프로젝션변환의 영향을 받지 않는다고 나와있어서
(이 부분은 아직 이해가 덜 됐다. 다를수도 있다)
정육면체화 된 뷰프러스텀을 최대한 포함하는 라이트 프러스텀을 적절하게 계산해서
섀도우 맵을 찍는다.

단점은, 프로젝션 변환 후의 공간엔 문제가 많아서
(시점에 딱 맞게 바꿔주는 건데 공간만 바꾸고 다른 지점에서 바라보니까 당연히..)
라이트가 시점과 비슷한 방향일 경우, 시점보다 앞에 위치한 물체가
뒤쪽에 큼지막하게 자리잡는 경우가 생기거나
각도에 따라서 전혀 혜택을 못 보는경우(앨리어싱이 전혀 나아지지 않는),
먼 곳의 오브젝트에는 너무 적은 픽셀을 할당하기에
멀리있는 오브젝트의 앨리어싱은 가히 살인적이라는점
(어차피 멀리있는 물체는 작으니까 상관없지 않겠냐고 생각하겠지만,
큰 건물이라면 어떻하삼? )
등등이 있겠다.

여기까지 들으면 더 자세한 내용은 PSM문서만 봐도 거의 이해가 될 것이다.

LiSPSM(Light Space Perspective Shadow Map)

PSM에 LiS(Light Space)만 붙어서, 난 기본 개념이 똑같은 줄로만 알았다.
근데 전혀 틀리게 시작한다 -_-;

일단 생소한 개념인(물론 얘네들이 새로 만들어서 이름붙인거니 다른곳에선 들어봤을리가..)
라이트 공간이 무엇인지 파악하는게 중요하다.

라이트 공간이란,

[그림출처 : LiSPSM문서. 라이트 공간 설정과 라이트 좌표계를 따르면서 뷰프러스텀을 포함하는 최소크기의 프러스텀 P를 소개하고 있다]

라이트 벡터L(소문자는 굴림체로 알아보기 힘들어서...)을 좌표축 y로 하고,
뷰벡터(ViewPoint - EyePosition 으로 구한다)V와 라이트 벡터L과의 외적을 좌표축 x,
그리고 y와 x의 외적을 좌표축 z로 갖는 좌표계 공간이다.

뷰 프러스텀을 라이트공간으로 투영 시키고,
좌표축에 딱 맞으면서 뷰 프러스텀에 최대한 가까운 크기를 갖는 프러스텀 P를 구하여,
요 프러스텀 P를 y축으로 투영시켜서 섀도우 맵을 뽑는 방식이다.
왜 y축이냐고? y축을 라이트 벡터로 잡았잖여 -_-

결론은, PSM에서 말하는 post-perspective상태랑은 전혀 틀리기 때문에 헷갈리지 말지어다...

TSM(Trapezoidal Shadow Maps)

TSM하면 사다리꼴. 사다리꼴 밖에 생각 안나는 분들이 많으실걸로 안다.
근데 사다리를 어쩌라고???

일단 장면(Scene)을 월드-뷰-프로젝션 변환을 시켜놓는다.
아까 PSM의 설명을 열심히 읽었다면, 현재 이 상태가 post-perspective상태라는 것을
기억할 수 있을 것이다.
(2008년 7월 19일 추가 : 월드-라이트뷰-라이트프로젝션 변환이다.)

프로젝션. 투영. 말 그대로 3차원을 2차원으로 변형한다는 의미이다.
그런데 PSM에서는 그렇게 왜곡된 상태에서 다시 3차원적 접근을 해버려서
알콩달콩한 문제들이 일어났는데,
TSM은 그상태 그대로. 2차원적으로 해결해버린다.

[그림출처 : TSM설명 동영상. 저위의 바둑판 같은 것들은 프로젝션 변환후의 오브젝트들이란걸 의미하기 위함이다.
근데 전혀 티가 안난다;]

공간은 일단 WVP변환을 마친 상태이다.
(2008년 7월 19일 추가 : 월드-라이트뷰-라이트프로젝션 변환이므로 WLP 라고 쓰면 될려나?)
그리고 뷰 프러스텀을 구성하는 8개의 정점도 똑같이 변환해 주면 위의 그림같은 상황이 나온다.
(2008년 7월 19일 추가 : 정점 찾는 방법.
[0] = (-1, -1, 0), [1] = (-1, 1, 0), [2] = (1, 1, 0), [3] = (1, -1, 0),
[4] = (-1, -1, 1), [5] = (-1, 1, 1), [6] = (1, 1, 1), [7] = (1, -1, 1),
을 "뷰-프로젝션 의 역행렬"을 곱해준다.
저 좌표는 뷰 프러스텀의 8개 정점이 WVP변환 종료 후 갖게되는 좌표이므로,
(VP)^-1 을 해주면 정점들이 월드 좌표상으로 되돌아가게 된다.
그리고 이미 월드 변환은 적용 된 상태이니
남은 LP-라이트뷰, 라이트프로젝션- 변환만 해 주면
라이트-포스트 퍼스펙티브 상의 정점 좌표를 얻을 수 있게 된다.)

그 8개의 정점을 이용해(이미 여기서부터 공간은 2D 상황이다) 사다리꼴을 구성하는 4개의 정점을 뽑아내고
(TSM동영상을 보면서 고딩때까지 배웠던 수학적 지식을 총동원하면 못 구할것 없다)
다시 이 4개의 정점으로 이루어진 사다리꼴을 정사각형으로 변환시키는 행렬 Nt를 찾아내면
그걸로 TSM은 구현 끝이다.
행렬 Nt를 구하는 방법은 매우매우 친절하게 설명된 문서가 돌아다니고 있으므로 언급하지는 않겠다.

한가지, TSM은 저걸 개발한 대학인가 사람이 특허를 가지고 있어서 함부로 쓰면 좋치 않다는 소리가 있다.
실제로, 발매된 최신게임들은 다들 CSM(또는 PSSM) + LiSPSM(또는 SSM, PSM)의 조합을 채택하고 있다는 정보를
어렵지 않게 찾아볼 수 있을 것이다.(왜 조합이 필요한지는 CSM, PSSM 부분에서 설명하겠다)

효율은 LiSPSM보다 TSM쪽이 다소 좋다는 말이 있지만,
어차피 CSM(또는 PSSM)을 쓰게되면 그게 그거기 때문에
안전하게 LiSPSM로 가는거야~~

CSM(Cascade Shadow Mapping), PSSM(Parallel-Split Shadow Maps)

커스케이드. 직역하면 단계별 섀도우맵.
은근히 여기저기서 자주 대두되는 단어이다.
Parallel-Split는 네이년 사전에서 검색해 보니 '평행 분할' 정도로 직역할 수 있겠다.

아니 근데, 얘들은 왜 불쌍하게 한데 묶은겨?

사실 그놈이 그놈인기라.
구체적인 구현방법은 공부를 안해서 넘기고;
이 방식들은 한마디로 요걸로 표현할 수가 있다.

'밉맵이삼'

단지, 거리에 따라 텍스쳐 크기가 줄진 않는다;;

Depth Shadow Map알고리즘의 한계인 앨리어싱을
행렬 알고리즘으로 극복하는데에 한계를 느낀(그리고 텍스쳐 크기에도 한계를...) 님하들.

'그럼 많이 만들면 되잖아'

그런 것이다.
뷰프러스텀을 거리별로 일정 영역으로 나누어(3~4단계가량?)
각각 따로 섀도우맵을 뽑아놓는 무식하고도 확실한 방법이다.

[그림출처 : PSSM문서. 닥치고 머릿수만 늘리면 모든게 해결이예요~]

즉, 텍스쳐 갯수를 늘리자는게 CSM, PSSM의 요지이기 때문에,
그 하나하나의 텍스쳐는 결국 SSM, PSM, LiSPSM, TSM중 하나를 택하여 구현하게 된다.
역시나 양에 장사없다고,
CSM, PSSM을 쓰면 딱히 SSM으로도 큰 문제는 없다고 한다 -_-;;

아참, 근데 도대체 CSM이랑 PSSM은 뭐가 다른거야? 라는 궁금증을 이제서야 풀어드리자면,
거리에 따라 섀도우맵을 새로 작성하게 되는데,
그 거리를 구하는 방식(알고리즘)이 다르댄다. -_-;

기분상으론 CSM이 기본 이론으로,
거기서 파생된게 PSSM이지 않을까 싶다.
이 부분도 추후 수정이 예상된다;;

LOGSM(Logarithmic Shadow Map)

요건 무엇에 쓰는 물건인고?

나도 며칠전에서야 처음 들어봐서
자료조차 본 적이 엄따.

들리는 얘기에 의하면
대수를 이용해서 TSM보다도 효율좋게 섀도우맵을 뽑는 방식이라던데,
현재의 GPU로는 실시간으로 계산할 수가 없댄다.
그냥 그런것도 있구나~ 하면 된다 -_-;

우아.... 적고보니 쎄( = 혀 )가 빠지는구나.
섀도우맵을 막 공부하기 시작하는 분들께 도움이 되었으면 좋을텐데말야.
사람이 와야 말이지. 이곳은 -_-;

타춍~ 섀도우맵 PerfHUD 화면

x66vx — Mon, 30 Jun 2008 06:05:59 GMT

요것이 PerfHUD 적용 화면.
D3D 오브젝트 만들때 몇줄짜리 명령만 추가하면
릴리즈모드로 변환한 실행파일로 요놈을 써먹을수 있음.

타춍~ 배경에 해칭 건 상태.

x66vx — Mon, 16 Jun 2008 05:22:31 GMT

계왕권 6배... 아니, UV래핑 6배 상태.

DECL로 넘긴 정점형식을 셰이더에서 읽는 방법

x66vx — Wed, 04 Jun 2008 04:13:58 GMT

...에 대해서는 아랫쪽 포스트에 써 놓았다.

하지만 그 이외의 문제가 발생했다.

    D3DVERTEXELEMENT9 decl[] =
    {
        // offsets in bytes
        {0,                    0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0},
        {0, sizeof(float) * 3, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL,   0},
        {0, sizeof(float) * 6, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL,    1},
        {0, sizeof(float) * 9, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL,    2},
        D3DDECL_END()
    };
-실루엣 엣지을 검출하는 셰이더.-
실루엣 엣지를 판정하기 위해선 면법선 2개와
정점을 이동시킬 오프셋치, 즉 '부드러운 법선(...)' 하나가 필요하다

자, 노말이 3개다.

셰이더에서 읽어볼까?

dcl_position      v0
dcl_normal      v3
dcl_....??

길게 따지고 자시고 할것없이 답변은 이거다.

dcl_position      v0
dcl_normal      v3
dcl_normal1      v★
dcl_normal2      v♣
( 0, 3, ★, ♣부분은 알아서 암거나...물론 픽셀셰이더 1.4의 경우이다)

쓰고보니 지금에서야 셰이더 1.x버전대를 열나 파고있는 사람이
나말고 또 몇이나 더 있겠나 싶은 생각이 불현듯 드네.

-_-...

'부드러운' 법선의 정체

x66vx — Tue, 03 Jun 2008 03:10:49 GMT

ShaderX(참 오래된 책이로다...)를 보면서,
윤곽선 렌더링 부분에 들어왔다.

일단은 이미지 프로세싱에 의한 윤곽선 검출을 먼저 시작했고,
그 후에 '실루엣 엣지' 생성에 의한 윤곽선 드로잉에 들어갔다.

그런데 용어중에 자꾸만 '부드러운 법선' 이라고 해대는데,
이게 뭔가 싶어서 그림을 봐도 'smooth normal' 이라고만 되어 있고,
알듯 모를듯 딱히 감이 잡히지 않는다.

실루엣 엣지는 엣지에 접해있는 면 법선을 토대로 엣지 판정을 수행하여,
해당 엣지를 일정 방향 쭈~욱 뽑아내어 렌더링 하는 방식.

자료출처:비늘님(http://binul.cafe24.com/wikix/index.php?display=Welcome) 용책

그런데 뽑아내는 방향을 모르잖아.
그 방향을 '부드러운 법선' 이라고 하더라 -_-;

대충 여기까지 오면 감이 잡힐듯.
결국 그림에 보이는 면 법선 n0과 n1을 보간한게
엣지를 오프셋시킬 방향, 즉 부드러운 법선이 되는것.
뭐 Normalize(n0 + n1) 이정도면 되겠지.

'부드러운 법선' '매끄러운 법선'
그렇다고 딱히 달리 표현할 단어가 안 떠오르는것도 문제로고.
'보간된 법선' 정도면 괜찮지 않을라나?

용책 : 3D 입문서의 양대산맥

x66vx — Tue, 03 Jun 2008 01:39:57 GMT

국내 삼디 게임 입문서의 양대산맥으로 우뚝 서있는것이 바로

용책, 해골책이 뭐냐 하믄....

간단하게 네이년 검색으로 찾을 수 있겠지만,

악마의9시저주님(http://devils9curse.tistory.com/180)의 소개글을 빌리자면

해골책 : DirectX 9를 이용한 3D 프로그래밍의 기초부터 실전까지를 다루고 있습니다.

표지에 그려진 리얼틱(?)한 해골그림때문에 '해골책'으로 불리고, 꽤 유명해서 중국에도 번역되어 출간되었습니다.

이 책의 저자는 http://3dstudy.net/ 라는 홈페이지를 운영하고 있습니다.

용책 : 우리나라에서 위의 '해골책'과 함께 3D 프로그래밍 도서의 양대산맥을 이루고 있는 이른바 '용책'입니다.

3D 프로그래밍 관련 책이라고 하기에는 표지의 용 그림이 너무나 촌스러운 2D입니다...-_-;;

그래도 내용은 볼만 합니다.

해골책은 지사장님(...)이 갖고 계셔서 자주 빌려봤었고,

용책은 어쩌지. 담에 책 한국에서 주문할때 같이 할까말까 고민을 했었는데...

자료를 찾아 여기저기 해메다가 우연히 발견하게 되었다.

http://binul.cafe24.com/wikix/index.php?display=DirectX%209%B8%A6%20%C0%CC%BF%EB%C7%D1%203D%20GAME%20%C7%C1%B7%CE%B1%D7%B7%A1%B9%D6%20%C0%D4%B9%AE

ㄷㄷㄷ

용책의 '모든 내용'이 전부 타이핑 되어있고, 자료화면이 풀칼라로, 소스코드까지 첨부 되어있는,

어떤의미론 '책보다 더 질 높게' 게재 되어 있는 사이트이다.

이거... 위험하지 않나? 싶기도하지만, 너무나 감사한 자료이기도 하다.

p.s 지사장님, 이거보면서 공부하셈 -_-

D3DDECLUSAGE 열거형

x66vx — Fri, 09 May 2008 08:38:31 GMT

typedef enum _D3DDECLUSAGE {
    D3DDECLUSAGE_POSITION = 0,
    D3DDECLUSAGE_BLENDWEIGHT = 1,
    D3DDECLUSAGE_BLENDINDICES = 2,
    D3DDECLUSAGE_NORMAL = 3,
    D3DDECLUSAGE_PSIZE = 4,
    D3DDECLUSAGE_TEXCOORD = 5,
    D3DDECLUSAGE_TANGENT = 6,
    D3DDECLUSAGE_BINORMAL = 7,
    D3DDECLUSAGE_TESSFACTOR = 8,
    D3DDECLUSAGE_POSITIONT = 9,
    D3DDECLUSAGE_COLOR = 10,
    D3DDECLUSAGE_FOG = 11,
    D3DDECLUSAGE_DEPTH = 12,
    D3DDECLUSAGE_SAMPLE = 13
} D3DDECLUSAGE;

요걸 왜 하느냐...

버텍스 셰이더(류광님이 쉐이더보단 셰이더가 원어민 발음에 가깝댄다 =ㅂ=) 입력 레지스터 선언시에
dcl_position
dcl_texcoord
이런식으로 쓸 때 도대체 그게 어디에 정의되어 있는지 종종 헤맬때가 있다.
닥치고 DECLUSAGE에 있는 그대로 쓰면 된다.

좋은 리플

x66vx — Fri, 25 Apr 2008 10:02:36 GMT

자료를 찾던중 어떤분의 블로그에서 묘한 느낌의 문구를 발견했다.

"너는 차가운 위치를 만들었다!"

그 블로그 운영자와 친한 사람이
you are so cool
뭐 이런걸 일부러 웃기게 번역해서 쓴건가 싶었다.

다른 글을 봤는데 역시나 있었다.

"위치에 중대한 일은 그것을 좋아했다!"
"그런 경이롭 위치를 위해 많게의 감사!"
"좋은 위치! 너를 감사하십시요."
"여보세요, 아주 좋은 위치!"
"중대하고 유용한 위치!"

은근히 재미가 있고,
여러명이 다들 그런 글을 쓰길래
무슨 게임의 번역기 돌린 한글판에서
등장하는 대사구나... 라고 생각했다.

영 이상해서 다시 보니, 리플 작성자가 의미없는 영어 -_-;
중간에 무슨 babe이런것도 있는거 보니

영어 스팸 리플이군하 -_-;

그래도 재밌으니 써먹어야지.