I forgot to explain that you need to copy OBJ data into a new set of arrays. Say, the OBJ data is represented by OBJvertex array, OBJtexcoord array, OBJnormal array and OBJindex array where there are 3 separate indices for vertex, texcoord and normal. I imagine you are using only triangular meshes?
Create a new set of arrays: GLvertex, GLnormal, GLtexcoord and GLindex arrays that you will be using with OpenGL. You know the size of the GLindex array in advance, it's the same as the number of faces * 3, but you don't know the size of GLvertex, GLtexcoord and GLnormal arrays, so I suggest using std::vector. Initialy these arrays are empty.
For each 3 indices in OBJindex array you retrieve the values for vertex, normal and texcoord from equivalent OBJ* arrays. Using these values you search your GLvertex, GLnormal and GLtexcoord arrays to find if you have an index where the values are the same (within precision).
If there is such an index, you insert this index into your GLindex array. If there isn't such an index, you insert the values of vertex, normal and texcoord into the respective GL* arrays and insert an appropriate index into GLindex array.
Keep going until you have covered all indices. I can probably post the code, if I can find it.
VBO with indexed or non-indexed geometry?
Quote:Original post by fazekaim
> read my previous post.
What is the forum post title?
> Your vertex indexed '4' has texcoord index '1' and '283'....
The texture coords are the same... i tried to replace the 283 to 1 and the modell rendering has texture problem. Some texture coords slips everywhere, so i think i should make some other changes...
I didn't mean change the Wavefront OBJ file.
Since texcoord # 1 and 283 are the same, you ultimately see that each vertex in your model has but one normal and texcoord. For your vertex # 1 the texcoord is texcoord # 1 and normal is normal # 4, even though you see texcoord # 283 with vertex # 4 later in your file.
The implementation can be like this for noninterleaved data in separate arrays:
1. Arrange the vertices in linear order (ie. #1, #2, #3, ..., #n) in an array (which is your vertex array). Note that vertices are not repeated in the Wavefront obj file, unlike normals or texcoords.
2. Create texcoord array and normal array large enough to hold n normals and texcoords.
3.
loop n times Find which normal and texcoord belong to vertex #i (as stated above) Put these in the ith position in your normal array and texcoord array respectively.end loopAnd your index array should just contain the index of the vertex required for a triangle. I hope you understand what I'm trying to say!
Author
deavik, i started with your description:
the result: http://www.kepfeltoltes.hu/view/060501/objTest_www.kepfeltoltes.hu_.jpg
I have some strange texture index problem.
If i make a for loop for every triangles, and i put everey vertex, texture and normal value into a vbo, the rendering is fine, just the indexes vbo is problematic, i don't know why.
have i make errors?
for (int i=0;i<vertexes.size(); ++i) { boolean b = true; for( Triangle t : triangles ){ if( t.vertexIndex1 == i+1 ){ newtexels.add( texels.elementAt(t.textureIndex1-1) ); newnormals.add( normals.elementAt(t.normalIndex1-1) ); b = false; break; } if( t.vertexIndex2 == i+1 ){ newtexels.add( texels.elementAt(t.textureIndex2-1) ); newnormals.add( normals.elementAt(t.normalIndex2-1) ); b = false; break; } if( t.vertexIndex3 == i+1 ){ newtexels.add( texels.elementAt(t.textureIndex3-1) ); newnormals.add( normals.elementAt(t.normalIndex3-1) ); b = false; break; } } if( b ){ newtexels.add( new Texel() ); newnormals.add( new Normal() ); } }the result: http://www.kepfeltoltes.hu/view/060501/objTest_www.kepfeltoltes.hu_.jpg
I have some strange texture index problem.
If i make a for loop for every triangles, and i put everey vertex, texture and normal value into a vbo, the rendering is fine, just the indexes vbo is problematic, i don't know why.
have i make errors?
Quote:Since texcoord # 1 and 283 are the same, you ultimately see that each vertex in your model has but one normal and texcoord. For your vertex # 1 the texcoord is texcoord # 1 and normal is normal # 4, even though you see texcoord # 283 with vertex # 4 later in your file.
deavik,
Are you sure you can do that with OBJ files? In my experience, at least with Blender generated OBJ files there could be many different normals and texture coordinates for the same vertex. The simplest way to turn an OBJ file into OpenGL compatible vertex array is to:
for all indices in OBJ file
get vertex, texcoord and normal for the current index
insert vertex, texcoord and normal into GL arrays
Of course, this way you will get many duplicate vertices but at least the mesh will be drawn correctly.
deathkrush: Well, technically you shouldn't use the trick I mentioned because the texcoords and normals indexed with the same vertex could be different.
However, with many models, the texture coord and normal is unique for one vertex. Even in those cases, Blender wants to repeat the normal and texcoord. Result: 2 different texcoord / normal exntries for an identical texcord / normal. That was what I was driving at, and trying to eleiminate. It's worked for me - and to prove that it's not just for very specialized models, it worked for a car imported (with textures) from the GTAIII game out of the box. It was even true for the one texcoord fazekaim checked in his model file.
But you can see, as you rightly said, that this will fail miserably for something like a cube, in which case you must repeat the vertices. deathkrush, I think that is what you were saying, but fazekaim says that he has already got the non-indexed linear array to work.
fazekaim, I can't see a problem with your code at the moment. If it doesn't work out, you can use non-indexed arrays as you have been until you find a model format that is more "indexed arrays friendly" (If you do, let me know me so that I can start using it as well!).
However, with many models, the texture coord and normal is unique for one vertex. Even in those cases, Blender wants to repeat the normal and texcoord. Result: 2 different texcoord / normal exntries for an identical texcord / normal. That was what I was driving at, and trying to eleiminate. It's worked for me - and to prove that it's not just for very specialized models, it worked for a car imported (with textures) from the GTAIII game out of the box. It was even true for the one texcoord fazekaim checked in his model file.
But you can see, as you rightly said, that this will fail miserably for something like a cube, in which case you must repeat the vertices. deathkrush, I think that is what you were saying, but fazekaim says that he has already got the non-indexed linear array to work.
fazekaim, I can't see a problem with your code at the moment. If it doesn't work out, you can use non-indexed arrays as you have been until you find a model format that is more "indexed arrays friendly" (If you do, let me know me so that I can start using it as well!).
Author
deathkrush,
> for all indices in OBJ file
> get vertex, texcoord and normal for the current index
> insert vertex, texcoord and normal into GL arrays
i do this now, and it is working using vbos. i just thought to use indexed geometry :)
deavik,
> more "indexed arrays friendly"? like 3ds? i would like to try collada, but the export plugin is in hard development (no textures and animation yet), so the 3ds could be a better choise now.
Thanks...
> for all indices in OBJ file
> get vertex, texcoord and normal for the current index
> insert vertex, texcoord and normal into GL arrays
i do this now, and it is working using vbos. i just thought to use indexed geometry :)
deavik,
> more "indexed arrays friendly"? like 3ds? i would like to try collada, but the export plugin is in hard development (no textures and animation yet), so the 3ds could be a better choise now.
Thanks...
Author
i wrote a collada importer to my engine, and the result is the same.
Using vbo, the modell is rendered well, but using indexed vbos, the modell texture isn't good at some points. So, i think it isn't the obj format problem, it's a generic problem. To tell the truth, i don't understand how can it happens exactly.
Has anyone a good idea, or a good fix algorithm?
Thanks a lot in advance....
Using vbo, the modell is rendered well, but using indexed vbos, the modell texture isn't good at some points. So, i think it isn't the obj format problem, it's a generic problem. To tell the truth, i don't understand how can it happens exactly.
Has anyone a good idea, or a good fix algorithm?
Thanks a lot in advance....
Author
i wrote a mesh data modifier code:
i think, the deathkrush's description was something like that, but my english...
so, the indexed geometry is done, but my code hasn't speed up at all...
the bottleneck could be elsewhere? i should look at ati's opengl performance papaer...
// model.triangleIndex[0] vertexindex, model.triangleIndex[2] textureindex, model.triangleIndex[1] normalindexfor( int i=0; i<model.triangleIndex.length; ++i ){ for( int j=i+1; j<model.triangleIndex.length; ++j ){ if( (model.triangleIndex[0] == model.triangleIndex[j][0]) && ( (model.triangleIndex[1] != model.triangleIndex[j][1]) || (model.triangleIndex[2] != model.triangleIndex[j][2]) ) ){ vertexes.add( testVertexes.elementAt( model.triangleIndex[j][0] ) ); // add new vertex model.triangleIndex[j][0] = vertexes.size()-1; // modify index model.vertexCount++; } } }i think, the deathkrush's description was something like that, but my english...
so, the indexed geometry is done, but my code hasn't speed up at all...
the bottleneck could be elsewhere? i should look at ati's opengl performance papaer...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
