http://blog.naver.com/bluefallsky/140117440732

OpenGL 오류 ,OpenGL 라이브러리, 64비트 사용자의 glut32.dll 에러  OpenGL  2010/11/01 23:47 http://blog.naver.com/bluefallsky/140117440732 첨부파일 (1)

http://the2384.blog.me/10133610049

OpenGL을 설치해보자.  ♬ OpenGL / ＃ 컴퓨터  2012/03/05 20:17 http://the2384.blog.me/10133610049 첨부파일 (2) ＃ 참고 : 이 방법은 VS 2010 Version에 적용되는 것입니다. VS 2009나 하위 버전에 대한 것은 참고 사이트 2번째 링크에 들어가셔서 확인하시길 바랍니다. ○ SDK 설치 (아래의 링크 참조) 아래의 링크에서도 받을 수 있고 이 게시물의 첨부파일에서 받으셔도 무방합니다. (2012.3.5) http://www.opengl.org/resources/libraries/glut/glut_downloads.php 주의 : 64bit, 32bit 즉, 운영체제에 따라 다른 파일 경로에 설치될 수 있습니다. 압축을 풀게되면 .dll, .h, .lib파일이 나오는데 해당 경로로 이동하셔서 파일을 옮겨 주시면 됩니다. .dll = C:\Windows\system32 .h = C:\Program Files(x86)\Microsoft SDKs\Windows\v7.0A\Include\gl .h = C:\Program Files(x86)\Microsoft SDKs\Windows\v7.0A\Include (위의 두 경로 모두) (OpenGL 관련한 확장 라이브러리가 많기 때문에 별도로 폴더 만들어서 관리할 것.) .lib = C:\Program Files\Microsoft SDKs\Windows\v7.0A\Lib 참고 사이트 http://gcland.tistory.com/123 http://whiteday910.blog.me/40126539277   SDK를 모두 설치했다면 샘플 코드를 돌려보시면 됩니다. - 64비트 OS 사용자는 시스템에 glut32.dll이 없다고 뜰 수 있는데 그 경우엔 sysWOW64(C경로)에 dll파일을 복사하셔서 넣어 주시면 되겠습니다. 샘플 코드는 첨부파일을 참고 하시길 바랍니다. [출처] OpenGL을 설치해보자.|작성자 히단

http://towanouta.tistory.com/128

 opengl.zip

헤더 파일	LIB 파일	DLL 파일
glut.h	glut.lib	glut.dll
GL.h	glut32.lib	glut32.dll
GLU.h	GLU32.lib	GLU32.dll
GLAUX.h	GLAUX.lib	OPENGL32.dll
	OPENGL32.lib

※ 설치법
    간단히 위의 파일들을 적절한 위치에 붙여넣기만 하면 됩니다.

● 헤더파일 : 
       C:\Program Files\Microsoft Visual Studio\VC\include\gl 또는
       C:\Program Files\Microsoft Visual Studio\VC\include      에 붙여 넣어 주시면 됩니다.

● LIB 파일 : 
       C:\Program Files\Microsoft Visual Studio\VC\lib  에 붙여넣기

● DLL 파일 :
      32bit 운영체제 일 경우엔 
           C:\Windows\System32 에만 붙여넣기
      64bit 운영체제( 윈도7 기준 )
           C:\Windows\SysWOW64 에도 붙여넣기를 해주시면 됩니다.

64bit운영체제에서 SysWOW64폴더에 DLL파일을 붙여넣어 주지 않으면 제대로 작동이 되지 않을 수도 있습니다. 


그리고 비주얼 스튜디오에서 다음의 추가 종속성을 설정해 주시면 됩니다.

● 프로젝트 - 속성 - 구성속성 - 링커 - 입력 - 추가 종속성    에서 다음을 추가해주시면 됩니다.

opengl32.lib  glut32.lib  glu32.lib

http://www.gpgstudy.com/forum/viewtopic.php?t=731&sid=19239f4e54b2a269bb4656f30ef178b4

깊이에는 - 가 없으니 opengl 의 z값 또한 양의 값방향으로 나아간다가 맞는거 같네... 음

이전 주제 보기 :: 다음 주제 보기
글쓴이	메시지
[Q=kyu] 가입: 2002년 7월 11일 올린 글: 3	openGL에서의 NDC의 z축 양의 방향이 어느쪽인지.. 올려짐: 2002-07-29 15:32   3D game Engine Design에서 사용한 방법으로,  openGL 파이프라인 상의 프로젝션 행렬을 구하고 있습니다.  그러다가 하나의 의문점이 생겼습니다.  뷰 절두체를 투영행렬을 곱하여 [-1,1]^3 이 되는  NDC를 얻게 되는데,  이 NDC 역시 오른손 좌표계로 나타내어지는 지,  즉,  x축 양방향(오른쪽),  y축 양방향(위쪽),  z축 양방향(스크린에서 나오는 방향)  인지가 궁금합니다.  이것이 궁금한 이유는  NDC에서 [-1,1]범위 내의 Z값을 비교해서 스크린에 투영 시 먼저 뿌려야 할  것들을 판별한다고 생각하는데,  glDepthFunc함수의 디폴트 옵션에서는 z값이 작을수록 화면 가까이에 있는 픽셀로  판단하기 때문입니다. 이걸 보니 NDC의 z축 양의 방향은 화면 깊이 방향인지  헥갈리네요.  glDepthFunc의 옵션으로 사용되는 인자를 보면,  GL_NEVER : 항상 거짓  GL_LESS : 만일 source Z < drpth Z 라면 참  GL_EQUAL : 만일 source Z = drpth Z 라면 참  GL_LEQUAL : 만일 source Z <= drpth Z 라면 참  GL_GREATER : 만일 source Z > drpth Z 라면 참  GL_NOTEQUAL : 만일 source Z != drpth Z 라면 참  GL_GEQUAL : 만일 source Z >= drpth Z 라면 참  GL_ALWAYS : 항상 참  GL_LESS가 default로 쓰이는 인자이고, 새로 체크되는 픽셀의 z값이 더 작으면,  색상버퍼에 새로은 픽셀을 찍습니다.
위로
류광 가입: 2001년 7월 25일 올린 글: 3569 소속: GPGstudy 타 사이트 ID(?): docbook.kr::류광, indidev.net::류광	올려짐: 2002-07-29 16:27   NDC가 normalized device coordinates 의 약자인가요?? 어쨌든 뷰포트 변환 단계까지 도달했다면 3D는 잊어버리고(즉 Z는 버리고) '2D + 깊이'로 생각하는 것이 혼란을 피할 수 있을 것 같습니다...  OpenGL에서 깊이는 화면으로부터 화면 안쪽으로의 거리이고 범위는 [0,1]입니다. 음의 깊이에 있는 점은 그려지지 않으니까요.. 사실 깊이는 3차원 좌표계의 개념이라기보다는 은면 제거를 위한 일종의 참조 테이블이라고 보는 게 좋을 것 같아요...
위로
toki 가입: 2002년 4월 13일 올린 글: 151 소속: 대한민국	올려짐: 2002-07-29 16:34   저도 항상 헷갈려 왔는데 오른손 좌표계이면 Z축이 화면 밖으로 나오는  방향인데...   그런데 projection행렬은 무조건 왼손좌표계만 사용한다고 하네요. 당연한  이야기이지만 처음에는 이 생각을 못해서, openGL이 화면 좌표계를 오른손  좌표계를 사용하더라도 projection변환이 되기전에 왼손좌표계로 변환됩니  다. 그러므로 projection에서 뽑아낸 절두체는 당연히 왼손좌표계이겠죠.
위로
류광 가입: 2001년 7월 25일 올린 글: 3569 소속: GPGstudy 타 사이트 ID(?): docbook.kr::류광, indidev.net::류광	제가 이해하는 방식은... 올려짐: 2002-07-29 16:40   깊이 값이 결정되는 단계가 오면 '손잡이(handness)'성은 문제가 되지 않는다고 봅니다... (간단히 말하면 깊이값의 결정은 3D 좌표계에서 벗어나는 단계라고 보는거죠)  이 부분은 손잡이성의 문제라기보다는 그냥 화면 바깥이 양이냐 안쪽이 양이냐를 선택하는 것일 뿐이고 깊이라는 개념을 생각해 보면 당연히 화면 안쪽이 양이 되어야겠죠(수심 -10m라는 말은 없잖아요..) 화면 바깥이 양이라면 깊이 버퍼가 아니라 높이 버퍼라고 하지 않았을까 하는^^
위로
toki 가입: 2002년 4월 13일 올린 글: 151 소속: 대한민국	음 똑같은 이야기 같은데요! 올려짐: 2002-07-29 16:57   projection에서는 왼손좌표계밖에 존재하지 않는다는 이야기가 깊이값이  류광님 말대로 음이 될 수 없기때문에 당연한 것이라고 생각하기 때문에  저는 별로 다를 것이 없다고 생각되어지는 데요.  그리고 질문에서 좌표계에 대한 이야기가 나왔기때문에 좌표계에 대한  것에 초점을 맞춘 대답일뿐 답하고자 한 내용자체가 다르다고는 생각하지  않습니다.  좀 오해의 소지가 있었나요
위로
류광 가입: 2001년 7월 25일 올린 글: 3569 소속: GPGstudy 타 사이트 ID(?): docbook.kr::류광, indidev.net::류광	올려짐: 2002-07-29 17:26   예 있다고 봅니다. 결과적으로는 같지만 강조하는 바가 좀 틀리지 않나 싶어서요...  toki님은 변환 과정 중 한 부분에서 좌표계가 오른손에서 왼손으로 바뀐다는 관점에서 이야기하셨구요...  제가 강조하고 싶었던 것은.... 최종 3D 변환 후 Z 좌표를 깊이로 바꾸는 과정은 좌표계 변환 차원의 문제라기보다는 참조테이블의 범위 조정 차원의 문제로 보는 게 더 이해하기 쉽지 않냐는 것이었구요... 다른 말로 하면 3D 좌표계의 손잡이성을 '2D + 깊이' 공간에 적용할 필요는 없지 않는가 하는 것이었습니다.
위로
toki 가입: 2002년 4월 13일 올린 글: 151 소속: 대한민국	올려짐: 2002-07-29 21:00   제가 왼손좌표계를 말했던 것은 어차피 절두체도 기하적인 모형이기때문에 z축의 방향이 있어야 하고 그것이 왼손좌표계를 사용해야만 된다는 이야기고 좌표계가 변환되어야 한다 는 것은 openGL이 오른손 좌표계를 modelview행렬에서 사용하기때문에 변환이야기를 한 것이죠. 좌표계를 바꾼다는 이야기가 제가 하고 싶은 말의 핵심은 아니였습니다. 질문이 NDC에서 z축의 방향은? 이였기에  방향성을 정확하게 답변하고자 좌표계를 이야기했던 것이죠. 그냥 류광님 답변처럼 쉽게 깊이값이 음이 될 수 없다고 이야기를 했으면 좋았을 것 그랬네요.  다시 한번 제 관점이 좌표계가 변환된다는 이야기가 아니였다는 것을 말씀드리고 싶네요. 그래서 똑같은 이야기같은데요 라고 주장을 했던 것입니다. 의도 전달이 정확하지 않았나 보네요. 죄송
위로
류광 가입: 2001년 7월 25일 올린 글: 3569 소속: GPGstudy 타 사이트 ID(?): docbook.kr::류광, indidev.net::류광	올려짐: 2002-07-29 21:22   예.. 아무래도 제가 원래의 질문을 너무 확대해석한 게 아닌가 싶네요.. 저는 원래의 질문에 "(엔진 개발에서 OpenGL을 참고하고 있는데) OpenGL 같은 널리 쓰이는 API에서 NDC의 Z 좌표값과 깊이 테스트에 쓰이는 깊이값의 방향이 서로 다른 것은 좀 이상한 것이 아닌가?" 라는 점이 내포되어 있다고 봤거든요... 그 부분에 너무 집중하다보니 toki님의 뜻을 오해한 것 같습니다... 저야말로 죄송
위로
Gamza 가입: 2001년 10월 11일 올린 글: 610	결국은... 올려짐: 2002-07-29 21:42   결국 NDC의 Z는 화면안쪽으로 들어가는 방향이 양(+)이라는....말씀. _________________ HOME: http://www.Gamza.net
위로
류광 가입: 2001년 7월 25일 올린 글: 3569 소속: GPGstudy 타 사이트 ID(?): docbook.kr::류광, indidev.net::류광	올려짐: 2002-07-29 21:53   예 어쨌든 제 뜻은 깊이값의 부호와 좌표계의 손잡이성 사이의 일치 여부가 중요하지 않다는 뜻으로 해석해 주시길... ^^;;;
위로
[Q=kyu] 가입: 2002년 7월 11일 올린 글: 3	올려짐: 2002-07-29 23:53   이렇게 많은 답글을 달아주셔서 감사합니다. ^^ 재밌네요. 글 올리는거.  구글 검색하다가 첫방에 걸린 자료입니다.  http://www.cs.unc.edu/~vogel/Equations/projection.doc  이 문서에 openGL에서 사용하는 투영행렬에 관해 자세히 나와있군요.  이 글을 살펴본 결과 NDC의 z좌표는 [-1,1] 구간으로 매핑되며,  오른손 좌표계와는 반대로, 깊이방향이 z축 양의 방향이 되도록 뒤집힌다고 나옵니다.  1. The view frustum defined by the parameters  (left, right, bottom, top, near, far) is mapped to the canonical view volume in (-1, 1, -1, 1, -1, 1).  2. The signs of the z-values are reversed. This is because in eyespace, the view is down the –z-axis, whereas in NDC, the view is down the +z-axis.  깊이 값이 마이너스 값에도 대응하기 때문에 투영행렬식을 이끌어 내는데  부호가 헥갈리는군요. DirectX처럼 [0,1]구간으로 대응시켰더라면,  한결 생각하기 편했을텐데 말이죠.
위로
manilee 가입: 2001년 12월 28일 올린 글: 67 타 사이트 ID(?): 156937058	저두 한마디 올려짐: 2002-07-30 09:43   일단 NDC에서의 z방향에 대해선 위에서 많이 언급되어 있는 거 같구.  다 알고 계시겠지만, 앞에서 질문하신분은 depth buffer에서의 비교 또한 궁금해 하신것 같아서, 제가 아는데까지 말씀드리겠습니다.  NDC에서 변환된 좌표는 x, y, z 모두 [-1,1] 범위를 가집니다.  이것이 바로 그냥 frame buffer에 저장되는 것이 아니고, viewport transformation에 의해 window coordinate로 전화되어서 저장됩니다.  x, y는 glViewport에 의해서 frame buffer의 좌표가 정해지고(물론 full screen이 아닌 window의 경우 윈도우 기준좌표이겠지요.), z 값의 경우 glDepthRange(default는 n=0, f=1입니다.)에 의해 NDC의 z좌표를 linear mapping이 되어서 변환됩니다. glDepthRange에서는 꼭 znear<zfar일 필요는 없습니다.(뒤집어지도록 mapping할 수도 있습니다.)  식은  zw=(f-n)/2*zd+(n+f)/2  일단 변환되어진 z좌표는 [0,1]인 값으로 z-buffer에 저장됩니다.(이게 좀 애매하긴 합니다. 해서 제가 컴으로 test한 결과 f값이 1보다 크니까 변화가 없었습니다. 이런건 OpenGL spec 문서에도 언급되어 있지 않았는데, 말입니다. f가 1이하여야 한다든지 말입니다. 아니면, color값처럼 내부적으로 처리가 되든지 말입니다.)  그러니까, 8bit의 경우 unsigned integer로 [0,255]이 [0,1],  32bit의 경우 [0,65535]가 [0,1]..이런식으로 말입니다.  한가지 주의할 점은 depth range 조절로 clipping이 달라지진 않습니다. 왜냐면 앞단계에서 clipping이 일어나기 때문입니다. 단지 z-buffer에 저장할 때, depth test에 의해서 보이는 것이 달라질 수는 있어도 말입니다.  참고하시기를..
위로
[Q=kyu] 가입: 2002년 7월 11일 올린 글: 3	그렇군요. 올려짐: 2002-07-30 11:54   NDC상에서 클리핑을 처리하고,  깊이 값을 glDepthRange(default는 n=0, f=1)에서 정한 범위로 선형적으로 매핑 시키고,  openGL에서 깊이버퍼의 해상도에 맞게 알아서 저장해 주고,  (내부적으로 노멀라이즈를 한뒤에 깊이버퍼의 해상도를 곱해줄것 같군요.)  화면에 뿌려줄 때에는 glDepthFunc(default는 GL_LESS)에서 깊이 값이 작은 것을 위에 뿌리는 것이군요.  자세한 답변에 감사드립니다. glDepthRange라는 함수가 있었군요.
위로
류광 가입: 2001년 7월 25일 올린 글: 3569 소속: GPGstudy 타 사이트 ID(?): docbook.kr::류광, indidev.net::류광	올려짐: 2002-07-30 12:08   [Q=kyu] 씀: 깊이 값이 마이너스 값에도 대응하기 때문에 투영행렬식을 이끌어 내는데  부호가 헥갈리는군요. DirectX처럼 [0,1]구간으로 대응시켰더라면,  한결 생각하기 편했을텐데 말이죠. NDC의 Z 좌표와 깊이 버퍼의 깊이 값을 혼동하신 게 아닐지? manilee 님 지적에서도 알 수 있듯이 깊이 값 자체는 [0, 1]로 매핑됩니다... 구체적으로는 k / (2^m -1)로 매핑됩니다. m은 깊이 버퍼의 비트 수, k는 0 ~ (2^m-1) 이구요.  앞에서도 말했듯이 모든 혼란의 원인은 깊이를 Z와 동일시 하는데 있다고 봅니다... 예를 들어 아직도 흔히 쓰이고 있는 Z 버퍼, Z 테스트라는 말은 뷰포트 변환 전과 후에 다행히 Z와 깊이의 방향이 같은 경우에만 안전하게 사용할 수 있을 뿐 그렇지 않을 경우 또는 좌표계를 의도적으로 뒤집을 수 있도록 허용하는 API의 경우에는 안전하지 못한 용어라고 봅니다.  manilee 씀: 일단 변환되어진 z좌표는 [0,1]인 값으로 z-buffer에 저장됩니다.(이게 좀 애매하긴 합니다. 해서 제가 컴으로 test한 결과 f값이 1보다 크니까 변화가 없었습니다. 이런건 OpenGL spec 문서에도 언급되어 있지 않았는데, 말입니다. f가 1이하여야 한다든지 말입니다. 아니면, color값처럼 내부적으로 처리가 되든지 말입니다.)  그러니까, 8bit의 경우 unsigned integer로 [0,255]이 [0,1],  32bit의 경우 [0,65535]가 [0,1]..이런식으로 말입니다.  n과 f가 0과 1이 아닐 때에 대해서는 OpenGL 명세서의 DepthRange 항목에 나와 있는 것 같네요((1.3, 1.4 모두 섹션 2.10.1)  void DepthRange( clampd n, clampd f );  Each of n and f are clamped to lie within [0; 1], as are all arguments of type clampd or clampf.  -------  p.s 앗 Q=kyu 님 글을 남기셨네요.. 뒷북이 되었군요.. ^^
위로
manilee 가입: 2001년 12월 28일 올린 글: 67 타 사이트 ID(?): 156937058	앗 그렇군요. 올려짐: 2002-07-30 12:14   제가 꼼꼼히 OpenGL spec을. 문서를 읽지 않았네요.  한번 처음부터 끝까지 읽어 볼만한데... 시간이..  류광님 감사
위로
손님	^^ 올려짐: 2002-07-30 16:51   와우!!! ^^ 멋지당..  1년전에 devpia에서 이 문제 나왔었는데 이제야..^^ 공론화 됐네여..  멋진 설명과 자세한 해설 ..  그때두 이상했었는데..결국은..^^  대단하십니다..좋은설명 감사드립니다.  꾸벅.^^
위로

copyrightⓒ 김성완(kaswan) [2000년 1월 12일]

OpenGL과 Direct3D의 파이프라인은 기본적인 원리에서는 같지만... 
소프트웨어 엔진과 더불어 두 API도 동시에 지원할 경우 두 API의 렌더링 파이프라인의 차이점을 잘 알고 있어야 합니다.

3차원 엔진은 기본적으로 크게 세가지 모듈로 구성이 됩니다.
Transformation, Lighting, Rasterizer

이 중에서도 특히 Transformation 모듈의 Pipeline을 잘 이해해야 합니다.

OpenGL과 D3D의 파이프라인을 비교해 보죠.

OpenGL : ModelView ==> Projection ==> Viewport -> Perspective Division Direct3D : World -> View ==> Projection ==> Perspective Division -> Viewport

==> View coordinats 
==> Clipping coordinats

두 파이프라인을 비교해 보면 당장에 차이가 눈에 띠는데, 실질적으로 본다면 같은 겁니다.

* 먼저 Projection Transformation 이후 단계를 살펴보면 서로 순서가 다른데..

Homogeneous 좌표 w로 나누는 Perspective Division은 먼저 하던지 나중에 하던지 순서에 상관없이 최종 결과는 동일합니다.
그래서 실질적으로는 같은 겁니다.

D3DIM 의 예제중에 DrawPrim 이라는 예제가 있는데.. 
D3D의 세가지 버텍스 포맷을 모두 사용해서 Primitive를 렌더링하는 예입니다. 
그 중에 D3DTLVERTEX를 사용하는 Cube 모델의 경우 Transformation 을 직접하게 되는데, 소스를 살펴보면 D3D의 순서대로 하질 않고 OpenGL처럼 Perspevtive Division을 먼저하고 Viewport Transformation 을 합니다.
결국 순서에 상관이 없는 것이죠. 
(참고로 그 예제 소스에는 약간의 실수가 있더군요... 어차피 간단한 예제라 텍스츄어매핑없이 단순히 쉐이딩만 하는 거라서 실행중에 드러나지 않았지만, RHW 에다 1/w 를 대입해야하는데.. w를 바로 대입했더군요. 그리고 또 Projection Transformation후에 해야하는 3D Clipping이 생략되어 있습니다. 제대로 하려면 이것도 직접 해주어야죠.)

* 두번째 차이가 나는 곳은 Projection 변환하기 전인데...

살펴보면 OpenGL은 ModelView Transformation Matrix 하나만 설정하면 되는데...
D3D는 World 와 View 두가지로 나누어서 하게 되어 있죠.
D3D에서 두개로 나누어서 하더라도 내부적으로는 어차피 하나로 합쳐지게 되므로 결국 OpenGL처럼 한번에 설정하나 D3D처럼 따로 설정하나 같은 것이죠.
(D3D 매뉴얼에도 권고하기를 World TM과 View TM을 개별적으로 설정하기 보다는 하나는 항등행렬로 설정하고 하나에다 둘을 미리 곱해서 넣어주는게 속도상 유리하다고 되어있어요. 대개 3차원 엔진들은 행렬이 항등행렬인지 체크해서 아예 곱하는 계산에서 제외시키는 식으로 최적화 되어있기 때문이죠.)

결론적으로 OpenGL과 D3D의 Transformation 파이프라인은 동일하다고 보아도 별 문제가 없다는 것이죠.

물론 두API가 사용하는 좌표계가 서로 틀리고

OpenGL : 오른손 좌표계 
Direct3D : 왼손 좌표계

좌표값을 나타내는 행렬의 경우 OpenGL의 경우 열벡터를 사용하고 D3D의 경우 행백터를 사용하기 때문에 구체적인 행렬의 곱셈순서가 서로 반대이고, 행렬이 서로 행과 열이 바뀐(Transpose) 형태로 되어 있어 구체적인 행렬값은 틀리지요.

하지만 projection 변환까지 거치고 나면 두 API모두 좌표값이 사실상 같아집니다.
무슨 얘기인고 하니 둘다 결국은 3D 클리핑을 수행하기 위한 일종의 표준적인 정규 좌표계로 변환 되어서 같은 좌표가 된다는 것이죠. 
그래서 소프트웨어로 Transformation 을 처리할 경우 두 API 좌표계와 행렬 표시의 차이점을 개의치 않고. 적당한 하나의 공통 좌표계와 공통 행렬로 Projection 변환까지 수행한 후 두 API에 좌표값을 정규화된 좌표값으로 공급해주면 나머지는 동일하게 처리되는 것이죠.

OpenGL의 경우 ModelView 행렬과 Projection 행렬을 둘다 항등행렬로 설정하고 행렬연산을 직접하면 임의로 마음에 드는 좌표계를 사용하면서도 까다로운 3D 클리핑과 최종적인 ransterization을 API에게 맡길 수가 있습니다.

문제는 OpenGL의 경우 유연하게 이런식으로 하는게 먹히는데..
D3D의 경우 파이프라인의 어느 부분을 사용할 지를 Vertex 포멧으로 선택할 수 있는데.. 이 선택이 아래 세가지 밖에 없다는 것이죠.

D3DVERTEX : Transformation, Lighting, Rasterization 을 모두 D3D에게 맡김 D3DLVERTEX : Lighting, Rasterization 을 D3D에게 맡김 
D3DTLVERTEX : Rasterization 만 D3D에게 맡김

위에서 보다시피 OpenGL처럼 Transformation 파이프라인의 중간에 끼어 들거나 할 수 없다는 것이죠.

즉, D3D의 경우는 Transformation을 모두 직접하거나 아니면 모두 API에 맡기거나 하는 양단의 선택밖에 없다는 것이죠. 
(이런 걸 보아도 OpenGL이 얼마나 잘 만들어진 API인지 알 수 있죠.)

결국 이렇게되면 D3D의 경우 Transforamation을 직접 하려고 한다면, 까다로운 3D 클리핑까지 직접 해야 합니다.

물론 이미 소프트웨어 엔진이 제대로 구축되어 있다면 3D클리핑 도 직접 수행하므로 별문제가 없지만서도...

만약 소프트웨어 엔진없이 3D가속 카드 전용으로 만들면서 OpenGL과 D3D API를 동시에 지원하려고 한다면, 3D클리핑 처럼 힘든일은 3D API에게 맡기면서 가능한 공통의 코드를 공유할 수 있도록 하는 게 좋겠지요.

이런 경우 적당한 전략은 좌표계를 D3D에 맞추고 행렬도 D3D용을 공용으로 사용하고, 조명계산도 직접 공동으로 처리하고... 
OpenGL의 경우 Projection 변환까지는 직접 처리하고, 나머지는 OpenGL에 맡기고.. 
D3D의 경우 D3DLVERTEX를 사용해서 좌표변환 계산은 통째로 D3D에 맡기는 겁니다.
그럼 3D 클리핑도 알아서 해주겠지요...