Wavefront .obj 텍스처 좌표를 분석하는 데 문제가 발생했습니다.

Question

objc에서 OpenGL ES 2.0 용으로 .obj 파서를 작성하여이 OpenGLES의 작동 방식을 더 잘 이해할 수 있습니다. 버텍스를로드하고 버텍스 컬러가있는 모델을 보여주는 것은 매력과 같습니다. 작은 메모 : 색인 버퍼를 사용하고 있습니다.

실제 문제는 atm 텍스처의 매핑입니다. 아래에서 좀 더 자세히 살펴 보 겠지만, 내 텍스처는 꼭 그래야하는 방식으로 매핑되지 않습니다.

다음은 .obj 형식이 어떻게 작동하는지 생각해 봅니다. 틀린 경우 수정하십시오. "f"라인은 슬래시 앞의 숫자가 정점의 인덱스와 슬래시 뒤의 숫자를 정의하는 얼굴을 나타냅니다 텍스처 좌표를 정의합니다.

v -75 75 -50 
v 75 75 -50 
v -75 -75 -50 
v 75 -75 -50 

vt 0 0 
vt 0 1 
vt 1 1 
vt 1 0 

f 4/3 3/2 1/1 
f 2/4 4/3 1/1 

그리고 다음과 같은 질감 :

은 (시네마 4D 내 보낸) 다음 .OBJ 파일을 고려

내가 OpenGL을 ES 3D 공간에서 정점의 위치를 ​​지금

, 텍스처 좌표를 각 정점에 매핑하려고하면 매핑이 잘못됩니다. 텍스처 좌표 값 중 일부를 이동하여이 문제를 해결할 수 있지만이를 수행하는 방법이 아니라는 것을 알고 있습니다. 또한 Axes 및/또는 uv 매핑을 뒤집기 위해 .obj 내보내기 설정 중 일부를 편집하려고했지만 올바른 매핑이 아닌 결과를 가져 왔습니다. .obj 파일 형식에 관한 이론에 실종 된 것이 있습니까? 제가 이미 말할 수있는 한가지 : 어제는 .obj 형식의 좌표계가 topleft를 텍스처의 기준점으로 정의한다는 것을 읽었습니다. 그래서 나는 그것을 내 파싱에 이미 고정시켰다.

다음은 현재 상황을 요약 한 것입니다. 업데이트 : 텍스처의 좌표계는 실제 .obj 텍스처 좌표계이며 OpenGL의 좌표계는 아닙니다. 필자는 이것을 분석하기위한 파싱 알고리즘의 좌표를 변환합니다.

Answer 1

필자는 내 자신의 질문에 답을 할 것입니다. 문제는 인덱스 버퍼를 사용하여 성능을 높이는 것으로 보였지만 텍스처 좌표는 여전히 원래 정점에 매핑되었습니다.

Answer 2

는 지금까지 내가 아는 한, 당신이보고하는 좌표 시스템은 올바른 일이 아니다.

실제로이 같은 것입니다 :

나는 이것이 아마 당신의 질문에 대한 실제 응답하지 알고 있지만 나는 그것을에 많은 도움이 되길 바랍니다.

Answer 3

Maurizio는 OpenGL 텍스처 매핑 좌표를 올바르게 표현했습니다.

귀하의 사진을보고 나는 당신이 당신의 objC 코드를 더 잘 봐야한다고 말하고 싶습니다. .obj가 C4D에 의해 올바르게 익스포트되었다고 가정하면 텍스쳐 인덱스가 섞여있는 것처럼 보입니다.

그럴듯한 증거 : 게시 한 그림 ("결과 Opengl")의 오른쪽 하단 정점으로 왼쪽 하단 정점을 전환하면 텍스처가 오른쪽으로 나옵니다.

편집 : 실제로 오류는 텍스처로드 코드에있을 수 있지만 결과는 설명하지 않습니다. 텍스처 로딩에 오류가 있어도 텍스처가 단순히 거꾸로 표시됩니다 (왼쪽 하단의 OpenGL 좌표 시스템으로 인해). 제안 : 코드에서 vt0 및 vt3 전환 ...

Answer 4

.obj 파일을 구문 분석하는 비슷한 문제를 발견했습니다. 제 경우에는 내 .obj 파일이 거꾸로 된 V (두 번째 텍스처 좌표) 축을 사용하는 것으로 보입니다. 이 코드 줄로 문제를 해결했습니다. v = 1.0f - v;