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

问题描述 投票:0回答:1

最近,我重写了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的全局索引列表?

希望有人可以在这个主题上教育我;我将不胜感激。

opengl vbo .obj
1个回答
0
投票

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

OBJ索引通常需要进行一些按摩。它们从1开始的事实有点烦人(尽管您可以通过在之前将顶点指针指定为元素或减少每个索引来解决此问题)。他们可以索引三角形/四边形/多边形的事实,这意味着您可能需要对数据进行三角剖分。索引不在UV / Normal /顶点之间共享的事实,这意味着您最终可能会构建自己的索引集(如果需要,可以使用着色器存储缓冲区使用单独的索引,但这可能不是最快的方法) 。

最终obj文件作为运行时OpenGL文件格式非常糟糕。您最好编写一个简单的工具来破坏obj文件,根据需要对数据进行按摩,然后吐出一个更简单的方法来读取二进制文件。

© www.soinside.com 2019 - 2024. All rights reserved.