关于Wavefront .obj 格式设计的问题

Question About The Wavefront .obj Format Design

我最近正在重写我的 Wavefront 模型加载器,并打算将数据用作索引顶点缓冲区对象。一切正常后,我意识到了一些我以前没有注意到的关于 .obj 格式的东西。指数似乎是相对于文件中先前联合模型的最后一个最高指数递增的。下面是一个.obj文件的例子,无非就是几个立方体。

# Blender v2.80 (sub 75) OBJ File: ''
# www.blender.org
mtllib Cubes.mtl
o Cube
v 1.000000 1.000000 -1.000000
v 1.000000 -1.000000 -1.000000
v 1.000000 1.000000 1.000000
v 1.000000 -1.000000 1.000000
v -1.000000 1.000000 -1.000000
v -1.000000 -1.000000 -1.000000
v -1.000000 1.000000 1.000000
v -1.000000 -1.000000 1.000000
vt 0.625000 0.000000
vt 0.375000 0.250000
vt 0.375000 0.000000
vt 0.625000 0.250000
vt 0.375000 0.500000
vt 0.375000 0.250000
vt 0.625000 0.500000
vt 0.375000 0.750000
vt 0.625000 0.750000
vt 0.375000 1.000000
vt 0.375000 0.500000
vt 0.125000 0.750000
vt 0.125000 0.500000
vt 0.875000 0.500000
vt 0.625000 0.500000
vt 0.625000 0.250000
vt 0.625000 0.750000
vt 0.625000 1.000000
vt 0.375000 0.750000
vt 0.875000 0.750000
vn 0.0000 1.0000 0.0000
vn 0.0000 0.0000 1.0000
vn -1.0000 0.0000 0.0000
vn 0.0000 -1.0000 0.0000
vn 1.0000 0.0000 0.0000
vn 0.0000 0.0000 -1.0000
usemtl Material
s off
f 5/1/1 3/2/1 1/3/1
f 3/4/2 8/5/2 4/6/2
f 7/7/3 6/8/3 8/5/3
f 2/9/4 8/10/4 6/8/4
f 1/11/5 4/12/5 2/13/5
f 5/14/6 2/9/6 6/15/6
f 5/1/1 7/16/1 3/2/1
f 3/4/2 7/7/2 8/5/2
f 7/7/3 5/17/3 6/8/3
f 2/9/4 4/18/4 8/10/4
f 1/11/5 3/19/5 4/12/5
f 5/14/6 1/20/6 2/9/6
o Cube.001
v 1.023054 3.453142 -4.075902
v 1.023054 1.453142 -4.075902
v 1.023054 3.453142 -2.075902
v 1.023054 1.453142 -2.075902
v -0.976946 3.453142 -4.075902
v -0.976946 1.453142 -4.075902
v -0.976946 3.453142 -2.075902
v -0.976946 1.453142 -2.075902
vt 0.625000 0.000000
vt 0.375000 0.250000
vt 0.375000 0.000000
vt 0.625000 0.250000
vt 0.375000 0.500000
vt 0.375000 0.250000
vt 0.625000 0.500000
vt 0.375000 0.750000
vt 0.625000 0.750000
vt 0.375000 1.000000
vt 0.375000 0.500000
vt 0.125000 0.750000
vt 0.125000 0.500000
vt 0.875000 0.500000
vt 0.625000 0.500000
vt 0.625000 0.250000
vt 0.625000 0.750000
vt 0.625000 1.000000
vt 0.375000 0.750000
vt 0.875000 0.750000
vn 0.0000 1.0000 0.0000
vn 0.0000 0.0000 1.0000
vn -1.0000 0.0000 0.0000
vn 0.0000 -1.0000 0.0000
vn 1.0000 0.0000 0.0000
vn 0.0000 0.0000 -1.0000
usemtl Material
s off
f 13/21/7 11/22/7 9/23/7
f 11/24/8 16/25/8 12/26/8
f 15/27/9 14/28/9 16/25/9
f 10/29/10 16/30/10 14/28/10
f 9/31/11 12/32/11 10/33/11
f 13/34/12 10/29/12 14/35/12
f 13/21/7 15/36/7 11/22/7
f 11/24/8 15/27/8 16/25/8
f 15/27/9 13/37/9 14/28/9
f 10/29/10 12/38/10 16/30/10
f 9/31/11 11/39/11 12/32/11
f 13/34/12 9/40/12 10/29/12
o Cube.002
v -1.453796 3.256773 1.773842
v -1.453796 1.256773 1.773842
v -1.453796 3.256773 3.773842
v -1.453796 1.256773 3.773842
v -3.453796 3.256773 1.773842
v -3.453796 1.256773 1.773842
v -3.453796 3.256773 3.773842
v -3.453796 1.256773 3.773842
vt 0.625000 0.000000
vt 0.375000 0.250000
vt 0.375000 0.000000
vt 0.625000 0.250000
vt 0.375000 0.500000
vt 0.375000 0.250000
vt 0.625000 0.500000
vt 0.375000 0.750000
vt 0.625000 0.750000
vt 0.375000 1.000000
vt 0.375000 0.500000
vt 0.125000 0.750000
vt 0.125000 0.500000
vt 0.875000 0.500000
vt 0.625000 0.500000
vt 0.625000 0.250000
vt 0.625000 0.750000
vt 0.625000 1.000000
vt 0.375000 0.750000
vt 0.875000 0.750000
vn 0.0000 1.0000 0.0000
vn 0.0000 0.0000 1.0000
vn -1.0000 0.0000 0.0000
vn 0.0000 -1.0000 0.0000
vn 1.0000 0.0000 0.0000
vn 0.0000 0.0000 -1.0000
usemtl Material
s off
f 21/41/13 19/42/13 17/43/13
f 19/44/14 24/45/14 20/46/14
f 23/47/15 22/48/15 24/45/15
f 18/49/16 24/50/16 22/48/16
f 17/51/17 20/52/17 18/53/17
f 21/54/18 18/49/18 22/55/18
f 21/41/13 23/56/13 19/42/13
f 19/44/14 23/47/14 24/45/14
f 23/47/15 21/57/15 22/48/15
f 18/49/16 20/58/16 24/50/16
f 17/51/17 19/59/17 20/52/17
f 21/54/18 17/60/18 18/49/18
o Cube.003
v 3.506466 0.072150 -5.531102
v 3.506466 -1.927850 -5.531102
v 3.506466 0.072150 -3.531102
v 3.506466 -1.927850 -3.531102
v 1.506466 0.072150 -5.531102
v 1.506466 -1.927850 -5.531102
v 1.506466 0.072150 -3.531102
v 1.506466 -1.927850 -3.531102
vt 0.625000 0.000000
vt 0.375000 0.250000
vt 0.375000 0.000000
vt 0.625000 0.250000
vt 0.375000 0.500000
vt 0.375000 0.250000
vt 0.625000 0.500000
vt 0.375000 0.750000
vt 0.625000 0.750000
vt 0.375000 1.000000
vt 0.375000 0.500000
vt 0.125000 0.750000
vt 0.125000 0.500000
vt 0.875000 0.500000
vt 0.625000 0.500000
vt 0.625000 0.250000
vt 0.625000 0.750000
vt 0.625000 1.000000
vt 0.375000 0.750000
vt 0.875000 0.750000
vn 0.0000 1.0000 0.0000
vn 0.0000 0.0000 1.0000
vn -1.0000 0.0000 0.0000
vn 0.0000 -1.0000 0.0000
vn 1.0000 0.0000 0.0000
vn 0.0000 0.0000 -1.0000
usemtl Material
s off
f 29/61/19 27/62/19 25/63/19
f 27/64/20 32/65/20 28/66/20
f 31/67/21 30/68/21 32/65/21
f 26/69/22 32/70/22 30/68/22
f 25/71/23 28/72/23 26/73/23
f 29/74/24 26/69/24 30/75/24
f 29/61/19 31/76/19 27/62/19
f 27/64/20 31/67/20 32/65/20
f 31/67/21 29/77/21 30/68/21
f 26/69/22 28/78/22 32/70/22
f 25/71/23 27/79/23 28/72/23
f 29/74/24 25/80/24 26/69/24

请注意索引在面声明中是如何递增的。每个联合模型都是对前一个模型最后一条面部线条的直接补充。 我的第一个问题是,他们为什么要递增索引?将文件中的每个协同模型的格式重置为 1(0) 不是更有意义吗?自然地,我可以通过跟踪前一个联合模型的最后一个最高索引并以此从下一个模型中减去任何新索引来否定这种增量设计。或者换句话说,如果第一个模型的最大索引值为 20,而下一个联合模型的起始索引为 21,我可以只做 ((20-1)-(21-1))-1)得到 0 的数组索引。这引出了我的第二个问题,是否有任何理由不否定增量索引?我没有看到递增索引有什么好处吗? 也许是 GL.DrawElements 的全局索引列表?

希望有人能就这个话题教育我;我将不胜感激。

obj 中的索引 v.s。 OpenGL 中的索引是一个相当长的话题。拥有一组顶点数据和一个索引列表的主要原因是整个 OBJ 文件可以从一对 VBO 中提取。

OBJ 指数通常需要稍微调整一下。它们从 1 开始的事实有点烦人(尽管您可以通过将顶点指针指定为之前的元素或通过递减每个索引来解决这个问题)。他们可以索引 triangles/quads/polys,这意味着您可能需要对数据进行三角测量。 UV/normal/vertex 之间不共享索引的事实意味着您最终可能会构建自己的一组索引(如果需要,您可以使用着色器存储缓冲区来使用单独的索引,但这可能不是最快的方法) .

最终 obj 文件作为运行时 OpenGL 文件格式非常糟糕。你最好编写一个简单的工具来注入 obj 文件,根据需要处理数据,然后吐出一个更容易读取的二进制文件。