Sign in to follow this  
derodo

VBO policy

Recommended Posts

Hi guys, This time I got a question on VBO, regarding the policy one should use with them ¿Is it better to use one huge VBO for storing all the geometry, or would it be better to use lots os small VBOs for each object in your scene? I guess it makes sense the first option would always be faster, as there will be almost no state changes regarding pointers, but on the other side, it makes all your geometry management more complex...you know, you will be forced to recompute indexes for your primitives (maybe upon load time) and so. Besides, if you want to go with the huge VBO approach, you may find your graphics memory exhausted and not having room enough to store the whole geometry, thus, forcing you to store all the information in the host memory, thus, making the VBO useless. So, maybe the best approach is to define medium sized VBOs, so can be sure at least some of them (the ones you use more often) get stored in the card's memory. Well, maybe I have answered myself :) but has anyone here made some kind of permformance analysis regarding VBO sizes, state changes, etc.? I would like to know also if it is wise to only define a subset of attributes as VBO, and let the others as host pointers...for example, suppose you have a huge landscape with lots of models in it, and there's not enough room in your card memory to store everything...what would you do? a) discard VBO usage, or use it but assume no attribute will be stored locally in the card. b) try to "divide an conquer" and just upload some models to the FGX c) try to "divide an conquer" by just uploading the vertex data, but keeping the normals in the host memory. d) whatever other option available I don't know about :) Thanks again for your comments,

Share this post


Link to post
Share on other sites
Quote:
Original post by derodo
Hi guys,

This time I got a question on VBO, regarding the policy one should use with them ¿Is it better to use one huge VBO for storing all the geometry, or would it be better to use lots os small VBOs for each object in your scene?

I guess it makes sense the first option would always be faster, as there will be almost no state changes regarding pointers, but on the other side, it makes all your geometry management more complex...you know, you will be forced to recompute indexes for your primitives (maybe upon load time) and so.

Besides, if you want to go with the huge VBO approach, you may find your graphics memory exhausted and not having room enough to store the whole geometry, thus, forcing you to store all the information in the host memory, thus, making the VBO useless.

So, maybe the best approach is to define medium sized VBOs, so can be sure at least some of them (the ones you use more often) get stored in the card's memory.

Well, maybe I have answered myself :) but has anyone here made some kind of permformance analysis regarding VBO sizes, state changes, etc.?

I would like to know also if it is wise to only define a subset of attributes as VBO, and let the others as host pointers...for example, suppose you have a huge landscape with lots of models in it, and there's not enough room in your card memory to store everything...what would you do?

a) discard VBO usage, or use it but assume no attribute will be stored locally in the card.
b) try to "divide an conquer" and just upload some models to the FGX
c) try to "divide an conquer" by just uploading the vertex data, but keeping the normals in the host memory.
d) whatever other option available I don't know about :)

Thanks again for your comments,



Can't quote me on this, but I believe if the data is already on the card and you pass it with glDrawElements() then you won't be remaking the data again.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this