VBO with indexed or non-indexed geometry?
Author
Hello,
What could be the fastest? The indexed or non-indexed geometry using VBO?
I'm using non-indexed geometry now, sould i change-it?
Thanks.
Indexed should definitely be faster for two reasons:
1. you have less vertices to send to the video card
2. OpenGL "knows" where your vertex is when you are repeating it, and probably there are some calculations in the vertex plotting process that don't need to be repeated
nVidia's performance documents also stress - always use indexed arrays, ie glDrawElements; and you have to say they know better than most people what's faster.
About whether you should overhaul your engine, I can't say but it could be very little work to a lot of work depending on how your model data is stored / accessed.
1. you have less vertices to send to the video card
2. OpenGL "knows" where your vertex is when you are repeating it, and probably there are some calculations in the vertex plotting process that don't need to be repeated
nVidia's performance documents also stress - always use indexed arrays, ie glDrawElements; and you have to say they know better than most people what's faster.
About whether you should overhaul your engine, I can't say but it could be very little work to a lot of work depending on how your model data is stored / accessed.
As far as I know, indexed geometry will only be faster if your mesh data is optimized for it. With indexed geometry you can avoid having duplicate vertices. I was able to go from 50fps to 75fps in my renderer by switching to indexed geometry, but I had to write a special function that goes through the mesh and gets rid of duplicate vertices. You might want to write a "crunch" app that you can use offline because the optimization algorithm could take a really long time.
deathkrush is right. That's what I had to do, I have a program that takes the raw model data (which unintelligably duplicates normals and texcoords), finds the duplicates and virtually creates a dump of an indexed vertex array.
Another thing I forgot to point out, is that indexed arrays are not always advantageous. eg, for a cube, the normal at 1 vertex is in 4 different directions for the 4 faces which share it. Clearly you have to duplicate the data, and you'd much rather use glDrawArrays.
Another thing I forgot to point out, is that indexed arrays are not always advantageous. eg, for a cube, the normal at 1 vertex is in 4 different directions for the 4 faces which share it. Clearly you have to duplicate the data, and you'd much rather use glDrawArrays.
the indexed geometry is little bit faster, i tested. Thanks, guys.
i have a new problem. i don't know how to sort the vbo's data.
i load wavefront obj files, and i read triangle data as indexes like these:
4/1/4 2/2/2 3/3/3
so:
4,2,3 -vertex indexes
1,2,3 -texture indexes
4,2,3 -normal indexes
4/283/4 5/284/5 2/285/2
so:
4,5,2 -vertex indexes
283,284,285 -texture indexes
4,5,2 -normal indexes
So the texture indexes are different. For the 4. vertex i should use texture no 1 and in other triangle no 283.
How can i sort the texture indexes to able to use indexes geometry?
the file was saved using blender....
i have a new problem. i don't know how to sort the vbo's data.
i load wavefront obj files, and i read triangle data as indexes like these:
4/1/4 2/2/2 3/3/3
so:
4,2,3 -vertex indexes
1,2,3 -texture indexes
4,2,3 -normal indexes
4/283/4 5/284/5 2/285/2
so:
4,5,2 -vertex indexes
283,284,285 -texture indexes
4,5,2 -normal indexes
So the texture indexes are different. For the 4. vertex i should use texture no 1 and in other triangle no 283.
How can i sort the texture indexes to able to use indexes geometry?
the file was saved using blender....
Quote:Original post by Anonymous Poster
the indexed geometry is little bit faster, i tested. Thanks, guys.
i have a new problem. i don't know how to sort the vbo's data.
i load wavefront obj files, and i read triangle data as indexes like these:
4/1/4 2/2/2 3/3/3
so:
4,2,3 -vertex indexes
1,2,3 -texture indexes
4,2,3 -normal indexes
4/283/4 5/284/5 2/285/2
so:
4,5,2 -vertex indexes
283,284,285 -texture indexes
4,5,2 -normal indexes
So the texture indexes are different. For the 4. vertex i should use texture no 1 and in other triangle no 283.
How can i sort the texture indexes to able to use indexes geometry?
the file was saved using blender....
Exactly the problem I had a week or two ago - read my previous post. If your model generally has shared normals for vertices, then there is a little trick that you can apply (offline, don't do this while loading the model).
Your vertex indexed '4' has texcoord index '1' and '283'. Open the obj file in an editor and check, I'm prepared to bet that the texcoords in the texcoord list with index '1' and '283' are identical (remember that the index of the first texcoord is '1' not '0' as in C). So you just have to find which texcoords and normals belong to a vertex and store it along with the vertex. Going this way, vertex '4' will be stored just once in your vertex array, and the accompanying texcoord will be texcoord # 1 or 283.
Author
> 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...
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 ran into this problem when using Wavefront OBJ files. The way I solved is with this algorithm:
1. Using OBJ's indexes get the values for vertex, texcoord and normal.
2. Search your app's vertex, texcoord and normal arrays until you find an index that points to similar values (within precision range)
4. If you find a matching index, you can avoid inserting data and just insert an index to that data.
5. If you don't find a matching index, insert both data and index into your arrays.
I hope thats clear. This algorithm doesn't take too long if your mesh is around 10,000 polygons, but at 100,000 it could take a couple of minutes, in which case you would need to use hashing or sorting / binary search techniques to improve performance.
1. Using OBJ's indexes get the values for vertex, texcoord and normal.
2. Search your app's vertex, texcoord and normal arrays until you find an index that points to similar values (within precision range)
4. If you find a matching index, you can avoid inserting data and just insert an index to that data.
5. If you don't find a matching index, insert both data and index into your arrays.
I hope thats clear. This algorithm doesn't take too long if your mesh is around 10,000 polygons, but at 100,000 it could take a couple of minutes, in which case you would need to use hashing or sorting / binary search techniques to improve performance.
Author
1. Using OBJ's indexes get the values for vertex, texcoord and normal.
--- OK, i read the indexes....
2. Search your app's vertex, texcoord and normal arrays until you find an index that points to similar values (within precision range)
--- so, i should check each triangle, and search a triangle with equals normal, vertex and texture index?
4. If you find a matching index, you can avoid inserting data and just insert an index to that data.
5. If you don't find a matching index, insert both data and index into your arrays.
i don't know how do you mean it... can you describe it with more details? thanks...
--- OK, i read the indexes....
2. Search your app's vertex, texcoord and normal arrays until you find an index that points to similar values (within precision range)
--- so, i should check each triangle, and search a triangle with equals normal, vertex and texture index?
4. If you find a matching index, you can avoid inserting data and just insert an index to that data.
5. If you don't find a matching index, insert both data and index into your arrays.
i don't know how do you mean it... can you describe it with more details? thanks...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
