I need a file format! Plz help..
Ok... I am desperate..
The all I want is a format/program that just stores PER VERTEX data in a file! (and the faces )
I tryed to export OBJ file From 3D Studio max... but I get more vertex coords than the actual vertices! I tried Maya and guess.. the same problem there too!
Is there any way to export the right number of Verts and tex coords ( am not talking about normals.. I will compute them myself ) from 3dsmax and maya?
do you hava to suggest some other format? I want something simple.
thanks for your time!
OBJ is the simplest format with a widely-available import/export toolset that I know of. It sounds like it would fit your needs perfectly. Perhaps you don't understand what some of the vertex data is? What sort of problems did you encounter when loading it?
I don't have any problems loading it.. but.. i dont understand why I get more tex coords than the number of the vertices :/
Because it has to. You seem to be under the assumption that there is a 1:1 mapping between vertices and texcoords in the format (e.g., "v" and "vt" elements). This isn't correct, so you're probably loading the files wrong.
The "f" (face) elements describe the vertex data used in a face. For each vertex in the face, this looks like "index of v element / index of vt element / index of vn element," et cetera. The "v" elements describe only position data, and the mesh may have some vertices that share the same position but have different normals or texcoords. A cube, for example:
There should be three vertices at the position marked by "A" in the above crude ASCII diagram. While these vertices will share the same position, they will have a different normal and most likely different texture coordinates. This is because, for normals, proper lighting is achieved for a cube when the normals are perpendicular to the surface -- if only one vertex with one normal existed at "A" there would be no good choice for the normal. The best approximation, an average, would create strange lighting (this is why the cube is often a problem case for normal generation routines that do no split vertices).
For proper texture mapping, the same thing applies. Depending on how you want the texture applied, it may be impossible for there to be only a single vertex at each corner of the cube. Vertices must be split to provide different texcoords.
As a result, you will have more texcoords and normals than positions, normally. This is not a problem with the OBJ format itself. Unless you mash up the mesh in the tool so that it's ugly and broken, all export formats will do this in one way or another (some will simply duplicate the positions; OBJ and others just have a seperate list for each component type and a bunch of indices).
The "f" (face) elements describe the vertex data used in a face. For each vertex in the face, this looks like "index of v element / index of vt element / index of vn element," et cetera. The "v" elements describe only position data, and the mesh may have some vertices that share the same position but have different normals or texcoords. A cube, for example:
+---+ / /|+---A +| |/+---+
There should be three vertices at the position marked by "A" in the above crude ASCII diagram. While these vertices will share the same position, they will have a different normal and most likely different texture coordinates. This is because, for normals, proper lighting is achieved for a cube when the normals are perpendicular to the surface -- if only one vertex with one normal existed at "A" there would be no good choice for the normal. The best approximation, an average, would create strange lighting (this is why the cube is often a problem case for normal generation routines that do no split vertices).
For proper texture mapping, the same thing applies. Depending on how you want the texture applied, it may be impossible for there to be only a single vertex at each corner of the cube. Vertices must be split to provide different texcoords.
As a result, you will have more texcoords and normals than positions, normally. This is not a problem with the OBJ format itself. Unless you mash up the mesh in the tool so that it's ugly and broken, all export formats will do this in one way or another (some will simply duplicate the positions; OBJ and others just have a seperate list for each component type and a bunch of indices).
You are right!
This means that if you have a cube and the vertices that are in the same place(sharing the same possition) have different texture coords, all of them must be in the vertex buffer. So the vertex buffer will have as many elements as the index buffer in the worst case. Am I right? ( I know this is not the right place for the question.. i just place it there so i wont open some other new thread)
Thanks for your time!
This means that if you have a cube and the vertices that are in the same place(sharing the same possition) have different texture coords, all of them must be in the vertex buffer. So the vertex buffer will have as many elements as the index buffer in the worst case. Am I right? ( I know this is not the right place for the question.. i just place it there so i wont open some other new thread)
Thanks for your time!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement