问题
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
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.
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.
回答1:
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.
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.
来源：https://stackoverflow.com/questions/5408600/why-vertices-normals-are-duplicated-in-obj-file