Public Group

# Confusion about OBJ file format.

This topic is 3059 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm trying to write a basic obj loader for slimdx (dx10), since I thought obj would be quite a common format, and easy to parse. It's pretty straightforward, but I'm confused about the faces part:
#Each face is given by a set of three indices each to the vertex/texture/normal
#coordinate array that precedes this.
#Hence f 1/1/1 2/2/2 3/3/3 is a triangle having texture coordinates and
#normals for those 3 vertices,
#and having for the vertex 1 (1/1/1) the vertex 1 from the "v" list, texture coordinate 1 from
#the "vt" list, and the normal 1 from the "vn" list; then for the 2nd vertex:
#the vertex 2 from the "v" list, texture coordinate 2 from
#the "vt" list, and the normal 2 from the "vn" list; for the 3rd vertex:
#vertex 3 from the "v" list, texture coordinate 3 from
#the "vt" list, and the normal 3 from the "vn" list
#NOTE: The list of vertices, etc. is one-based-indexing (meaning the first vertex in the file is v1).

f v1/vt1/vn1 v2/vt2/vn2 v3/vt3/vn3


if I look at my current mesh (simple sphere), it looks a bit like this:
f 1/1/1 2/2/2 21/22/3
f 21/22/3 2/2/2 22/23/4
f 2/2/2 3/3/5 22/23/4
f 22/23/4 3/3/5 23/24/6
f 3/3/5 4/4/7 23/24/6
f 23/24/6 4/4/7 24/25/8
...

I don't really understand how the v, vn and vt values can be different from eachother, unless it would shuffle the v/vn/vt lists for some reason. Turns out there's actually more vn (normals) and vt (texture coordinates) then there are vertexes though. How can this be? Shouldn't each vertex only have 1 normal vector and 1 texture coordinate associated to it? I don't see how this could work if I want to turn this data into vertex&index buffers. Is it by any chance the case that 3d modelling tools store multiple normal & uv informations for a single vertex, and in directx you use multiple vertexes that share the same position, but only contain 1 normal & uv each, to achieve the same thing? If so, what would be the proper way to rebuild the vertex data? Hyu

##### Share on other sites
OBJ will reuse vertices to save space, even when texcoords or normals are different. If you have a cube with a different texture on each side then OBJ will have 8 vertices, and 24 texcoords.

You are correct that you can't use this directly for building vertex buffers, so you will have to duplicate the vertices yourself. Typically you might create a new set of indices, maybe by using a map of 3-tuples, such that every unique set of three indexes (position, normal, texcoord) maps to one vertex, and duplicate the parts as necessary.

##### Share on other sites
I see what you're suggesting, but won't that throw the whole index buffering concept out of the window?
I thought the whole point with index buffering was to avoid having multiple vertexes in the same spot (unless necessary, for example if you need to jump from one uv coordinate to another)

##### Share on other sites
Yes it does, but I think OBJ has been around since the 1980's, so its been around a lot longer than GPU accelerated vertex buffers.

If you want to use it you have to do the extra legwork to make it compatible.

EDIT: I'm not sure how this "throws index buffering out the window". You still should be able to index your vertices. OBJ just gives each element their own index which is not legal for vertex buffers.

##### Share on other sites
Oh, alright, now I get it.
For some reason I now thought that every vertex would have an amount of normal vectors equal to the amount of triangles is it part of, but that wouldn't make any sense :)

As long as it's just the uv's I can duplicate the vertexes needed, and I'll be able to use index buffering just fine.

1. 1
2. 2
3. 3
Rutin
20
4. 4
frob
18
5. 5

• 32
• 13
• 10
• 11
• 9
• ### Forum Statistics

• Total Topics
632561
• Total Posts
3007088

×