为什么顶点/法线在OBJ文件中重复? [英] Why vertices/normals are duplicated in OBJ file?

查看:137
本文介绍了为什么顶点/法线在OBJ文件中重复?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

OBJ文件使用索引到顶点的f条线非常有效地表示数据. 但是我注意到那里很多OBJ模型都有重复的v行.例如,下面是示例多维数据集OBJ内容:

OBJ files uses f lines that are index into vertices to represent data very efficiently. But I notice many OBJ models out there have duplicated v lines. For example here is a sample cube OBJ content:

# Max2Obj Version 4.0 Mar 10th, 2001
#
mtllib ./Cube 2.mtl
g
# object Cube_1 to come ...
#
v  -5.500000 0.000000 -1.000000
v  -5.500000 0.000000 1.000000
v  -7.500000 0.000000 1.000000
v  -7.500000 0.000000 -1.000000
v  -5.500000 2.000000 -1.000000
v  -5.500000 2.000000 1.000001
v  -7.500000 2.000000 1.000000
v  -7.500000 2.000000 -1.000000
v  -5.500000 0.000000 -1.000000
v  -5.500000 2.000000 -1.000000
v  -5.500000 2.000000 1.000001
v  -5.500000 0.000000 -1.000000
v  -5.500000 2.000000 1.000001
v  -5.500000 0.000000 1.000000
v  -5.500000 0.000000 1.000000
v  -5.500000 2.000000 1.000001
v  -7.500000 2.000000 1.000000
v  -5.500000 0.000000 1.000000
v  -7.500000 2.000000 1.000000
v  -7.500000 0.000000 1.000000
v  -7.500000 0.000000 1.000000
v  -7.500000 2.000000 1.000000
v  -7.500000 2.000000 -1.000000
v  -7.500000 0.000000 1.000000
v  -7.500000 2.000000 -1.000000
v  -7.500000 0.000000 -1.000000
v  -5.500000 2.000000 -1.000000
v  -5.500000 0.000000 -1.000000
v  -7.500000 0.000000 -1.000000
v  -5.500000 2.000000 -1.000000
v  -7.500000 0.000000 -1.000000
v  -7.500000 2.000000 -1.000000
# 32 vertices

vt  0.000500 0.999500 0.000500
vt  0.000500 0.000500 0.000500
vt  0.999501 0.000500 0.000500
vt  0.999501 0.999500 0.000500
vt  0.999500 0.999500 0.999501
vt  0.999500 0.000500 0.999501
vt  0.000499 0.000500 0.999501
vt  0.000499 0.999500 0.999501
vt  0.999500 0.000500 0.999500
vt  0.999500 0.999501 0.999500
vt  0.000500 0.999501 0.999500
vt  0.999500 0.000500 0.999500
vt  0.000500 0.999501 0.999500
vt  0.000500 0.000500 0.999500
vt  0.999500 0.000500 0.000500
vt  0.999500 0.999501 0.000500
vt  0.000499 0.999501 0.000500
vt  0.999500 0.000500 0.000500
vt  0.000499 0.999501 0.000500
vt  0.000499 0.000500 0.000500
vt  0.999500 0.000500 0.000499
vt  0.999500 0.999501 0.000499
vt  0.000500 0.999501 0.000499
vt  0.999500 0.000500 0.000499
vt  0.000500 0.999501 0.000499
vt  0.000500 0.000500 0.000499
vt  0.000500 0.999501 0.999500
vt  0.000500 0.000500 0.999500
vt  0.999501 0.000500 0.999500
vt  0.000500 0.999501 0.999500
vt  0.999501 0.000500 0.999500
vt  0.999501 0.999501 0.999500
vt  0.000500 0.999500 0.000500
vt  0.999501 0.000500 0.000500
vt  0.999500 0.999500 0.999501
vt  0.000499 0.000500 0.999501
# 36 texture vertices

vn  0.000000 -1.000000 -0.000000
vn  0.000000 -1.000000 -0.000000
vn  0.000000 -1.000000 -0.000000
vn  0.000000 -1.000000 -0.000000
vn  0.000000 1.000000 -0.000000
vn  0.000000 1.000000 -0.000000
vn  0.000000 1.000000 -0.000000
vn  0.000000 1.000000 -0.000000
vn  1.000000 0.000000 -0.000000
vn  1.000000 0.000000 -0.000000
vn  1.000000 0.000000 -0.000000
vn  1.000000 0.000000 -0.000000
vn  1.000000 0.000000 -0.000000
vn  1.000000 0.000000 -0.000000
vn  -0.000000 -0.000000 1.000000
vn  -0.000000 -0.000000 1.000000
vn  -0.000000 -0.000000 1.000000
vn  0.000000 0.000000 1.000000
vn  0.000000 0.000000 1.000000
vn  0.000000 0.000000 1.000000
vn  -1.000000 0.000000 -0.000000
vn  -1.000000 0.000000 -0.000000
vn  -1.000000 0.000000 -0.000000
vn  -1.000000 0.000000 -0.000000
vn  -1.000000 0.000000 -0.000000
vn  -1.000000 0.000000 -0.000000
vn  0.000000 0.000000 -1.000000
vn  0.000000 0.000000 -1.000000
vn  0.000000 0.000000 -1.000000
vn  0.000000 0.000000 -1.000000
vn  0.000000 0.000000 -1.000000
vn  0.000000 0.000000 -1.000000
# 32 vertex normals

g Cube_1
usemtl 01_-_Default_1
s 0
f 1/33/1 2/2/2 3/34/3
f 1/1/1 3/3/3 4/4/4
f 5/35/5 8/8/8 7/36/7
f 5/5/5 7/7/7 6/6/6
f 9/9/9 10/10/10 11/11/11
f 12/12/12 13/13/13 14/14/14
f 15/15/15 16/16/16 17/17/17
f 18/18/18 19/19/19 20/20/20
f 21/21/21 22/22/22 23/23/23
f 24/24/24 25/25/25 26/26/26
f 27/27/27 28/28/28 29/29/29
f 30/30/30 31/31/31 32/32/32
# 12 faces

g

当我使用gl.glDrawElements(GL10.GL_TRIANGLES,mNumOfIndices,GL10.GL_UNSIGNED_SHORT,mIndicesBuffer)将此类模型导入opengl es应用程序时,这会引起很多问题 由于阴影错误而导致的绘制方法,这与法线有关.似乎opnegl-es期望如果我们使用drawElement方法而不是DrawArrays,我们给出的顶点不会重复.

This causes a lot problem when I import such a model into opengl es application using gl.glDrawElements(GL10.GL_TRIANGLES, mNumOfIndices, GL10.GL_UNSIGNED_SHORT, mIndicesBuffer) method of drawing due to wrong shading which has something to do with normals. It seems opnegl-es expect that the vertices we give to it are not duplicated if we are using drawElement method and not DrawArrays.

f行使得可以消除任何重复,从而生成非常有效的数据以在OpenGL-ES中进行处理.但是OBJ文件具有重复项,从而破坏了f行的目的.

The f lines makes it possible to eliminate any duplicate to produce very efficient data for processing in OpenGL-ES. But the OBJ files have duplicates which defeat the purpose of f lines.

推荐答案

很可能是因为以与OpenGL的固定管道内部相同的方式保留数据是很普遍的,而OBJ可以消除冗余但不能消除冗余.不需要它.因此,只要软件输出的东西是有效的OBJ文件并描述正确的形状,它的作者就满意了.您正确地说,不需要在OBJ中重复任何位置,法线或纹理坐标-"f"声明提供了一定程度的间接以避免这种情况.

It'll likely just be because it's quite common to keep data the same way that OpenGL's fixed pipeline does internally, and OBJ allows redundancy to be eliminated but doesn't require it. So as long as the software outputs something that is a valid OBJ file and describes the correct shape, its author was satisfied. You're correct to say that there's no need to duplicate any locations, normals or texture coordinates in an OBJ — the 'f' declarations provide a level of indirection so as to avoid that.

要显示包含v个顶点,n个法线和t个纹理坐标的普通情况下的OBJ,因此您需要准备在最坏的情况下将v * n * t个顶点提交给OpenGL. OpenGL不知道或不在乎您是否复制顶点.

To display a general case OBJ that contains v vertices, n normals and t texture coordinates you therefore need to be ready to submit v*n*t vertices to OpenGL in the worst case. OpenGL doesn't know or care whether you duplicate vertices.

这篇关于为什么顶点/法线在OBJ文件中重复?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆