Jump to content
  • Advertisement
Sign in to follow this  
fazekaim

VBO with indexed or non-indexed geometry?

This topic is 4456 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest 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....

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
> 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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!