Sign in to follow this  
Hyunkel

Confusion about OBJ file format.

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this