The .obj 3d model format is still widely used. Looking at it, it seems the format allows multiple normals and uvs associated with each vertex. (And I'm sure other formats do too)
That is, this is possible.
f 1/1/1 2/2/2 3/3/3
f 2/5/5 3/7/7 4/4/4
Notice vertex 2 is associated with the 2nd and 5th normal/uv.
And vertex 3 is associated with both the 3rd and 7th normal/uv.
When translating data of the format to for example OpenGL vertex/normal/uv streams to be drawn by glDrawElements(), the proper thing to do is duplicating the vertices with multiple normal/uv associations. Is there a tool that does this already?
The few model parsing code snippets I have used before don't seem that careful about this. What are some tools/libraries that are?
And what can be expected from most commercial modeling software? Do they export .obj files with one-to-one mapping of vertices and normal/uvs?
Thanks
Vertices with multiple normals/uvs
When translating data of the format to for example OpenGL vertex/normal/uv streams to be drawn by glDrawElements(), the proper thing to do is duplicating the vertices with multiple normal/uv associations. Is there a tool that does this already?
[/quote]
Assimp will read the file and give you a properly formatted array for VBOs.
And what can be expected from most commercial modeling software? Do they export .obj files with one-to-one mapping of vertices and normal/uvs?
[/quote]
Probably not. Most obj format exporters give you minimum size formats, they don't concern themselves with the data unpacking required.
Author
Thanks. I came across Assimp viewer tool some time ago and couldn't save anything after modification, probably because it's just a viewer?
Now again looking at the viewer and the command line tool options, I don't see an obvious option that accomplishes what I need. Does this mean the function that converts .obj model data to VBO friendly data is in the SDK?
Also, the FAQ states the library doesn't export. I wish it would since I feed the 'fixed' .obj file into other tools.
Now again looking at the viewer and the command line tool options, I don't see an obvious option that accomplishes what I need. Does this mean the function that converts .obj model data to VBO friendly data is in the SDK?
Also, the FAQ states the library doesn't export. I wish it would since I feed the 'fixed' .obj file into other tools.
There's a free and simple to use welder here --> http://jbit.net/~spa...cademic/welder/
It's relatively fast, simple, and works with any specified number of floats per vertex.
Also this welder works with, essentially, 2 cases.
One is unindexed mesh data and the other is mesh data with a single index list but where you suspect there
might be existing vertex duplicates and you want to get rid of them.
In the latter case once the process is done you take the remap table and apply it to the original index list.
In the former case where the data is unindexed you use the remap table directly as the new index table.
In your case where you have multiple index lists you will have to lay out your mesh data in an unindexed layout.
It's relatively fast, simple, and works with any specified number of floats per vertex.
Also this welder works with, essentially, 2 cases.
One is unindexed mesh data and the other is mesh data with a single index list but where you suspect there
might be existing vertex duplicates and you want to get rid of them.
In the latter case once the process is done you take the remap table and apply it to the original index list.
In the former case where the data is unindexed you use the remap table directly as the new index table.
In your case where you have multiple index lists you will have to lay out your mesh data in an unindexed layout.
If you want to use Assimp, the viewer thing is just a little tool you can use. The meat of the project is the library which you can link into your project, it will read obj files and format the data in memory for rendering with VBOs. There's examples on their site.
The way I handled it was to only store unique vertices when reading an OBJ into my engine. I then use an index buffer to specify each face that share the vertices. As far as I know this is the most efficient way of doing it in terms of memory usage and rendering.
Thats one thing I've always thought was bizarre. Texture Coords and Normals are effectively properties of the face, but they are attached the vertices, so if you want to have varying faces you need to have duplicate vertices.
I guess this is the reasoning behind using a single texture and making use of UV unwrapping - which solves the Texture problem, but doesn't address the Normals unless you also use a normal map?
I guess this is the reasoning behind using a single texture and making use of UV unwrapping - which solves the Texture problem, but doesn't address the Normals unless you also use a normal map?
Thats one thing I've always thought was bizarre. Texture Coords and Normals are effectively properties of the face, but they are attached the vertices, so if you want to have varying faces you need to have duplicate vertices.You're using the word "vertices" here as if it means "positions"/"points".
From a D3D/GL perspective, a "vertex" is a unique collection of properties, including position, tex-coords, normals, etc...
If you have two normals but one position, you've got to duplicate the position in order to make two unique vertices.
Likewise, if you have two positions but one normal, you've got to duplicate the normal in order to make two unique vertices -- it works both ways. There's no difference between position and other properties like normal - they're all just vertex properties.
Also, in D3D/GL, if normals belonged to a face (not a vertex), then your faces would be flat shaded instead of smooth-shaded.
You're using the word "vertices" here as if it means "positions"/"points".
From a D3D/GL perspective, a "vertex" is a unique collection of properties, including position, tex-coords, normals, etc...
If you have two normals but one position, you've got to duplicate the position in order to make two unique vertices.
Likewise, if you have two positions but one normal, you've got to duplicate the normal in order to make two unique vertices -- it works both ways. There's no difference between position and other properties like normal - they're all just vertex properties.
Also, in D3D/GL, if normals belonged to a face (not a vertex), then your faces would be flat shaded instead of smooth-shaded.
You're right. I think I'm misusing the terminology. I said vertices, but I what I meant was unique positions.
Re: normals belonging to a face, I meant some (non existent) system where along with defining the 3 vertex no's that make up the face (in the index buffer), you also list the 3 normals (instead of them being attached to the vertex definition). So the vertex list doesn't contain any vertices that have the same position, and you still have a normal for every vertex that makes up the face, but they are defined through the index buffer rather than the vertex buffer. It's just a thought experiment really, I realise vertex and index buffers don't actually work that way.
Also, in D3D/GL, if normals belonged to a face (not a vertex), then your faces would be flat shaded instead of smooth-shaded.
Smoothing faces is just averaging the normals of adjacent faces and applying that vector to their common vertex. If it is just for that, storing the normal in the vertex is just a convenience (not having to calculate it at loading time).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
