-1

I was recently rewriting my Wavefront model loader, and went for using the data as an indexed Vertex Buffer Object. After getting things working, I realized something about the .obj format that I had not previously noticed. Indices, it seems, are incremental in regards to the last highest indice from the previous co-model in the file. Here is an example of a .obj file, which is nothing more than a few cubes.

# 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

Please note how the indices increment within the face declarations. Each co-model is a direct addition to the last face line from the previous model. My first question is, why do they increment the indices? Wouldn't it make more sense for the format to reset to 1(0) for each co-model in the file? Naturally, I could negate this incremental design by keeping track of the last highest indice from the previous co-model and subtracting any new indice from the next model by that. Or in other words, if the first model had a maximum indice value of 20, and the next co-model had a starting indice of 21, I could just do ((20-1)-(21-1))-1) to get an array index of 0. That brings up my second question, is there any reason to NOT negate the incremental indices? Is there something beneficial about the incrementing indices that I'm not seeing? Perhaps a global indice list for GL.DrawElements?

Hopefully someone can educate me on this topic; I would greatly appreciate it.

Krythic
  • 4,184
  • 5
  • 26
  • 67

1 Answers1

3

Indices within obj v.s. indices in OpenGL is a fairly long topic. The main good reason for having a single set of vertex data, and a single list of indices, is that the entire OBJ file can be drawn from a single pair of VBOs.

The OBJ indices usually need to be massaged somewhat. The fact they start at 1 is slightly annoying (although you can work around this by specifying the vertex pointer as an element before, or by decrementing each index). The fact they can index triangles/quads/polys, means you'll probably need to triangulate the data. The fact the indices are NOT shared between UV/normal/vertex, means you'll probably build your own set of indices eventually (you can use shader storage buffers to use separate indices if you need, but that might not be the fastest approach).

Ultimately obj files are pretty terrible as a runtime OpenGL file format. You'd be far better off writing a simple tool to injest the obj files, massage the data as needed, then spit out a far simpler to read binary file.

robthebloke
  • 9,331
  • 9
  • 12
  • Did you mean to say that the reused data is vertices, normals, and texcoords? While the only thing that's different between VAOS is the indices? – Krythic Oct 27 '19 at 23:39