Sign in to follow this  

VBO vs DisplayLists

This topic is 4391 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

Hi there i want to render a high amount of triangles (77 000*2). Now these triangles will be placed over 1 048 576 Points, now these triangles are joined by mixed vertices ie... Although i save my points through one pointer they arent always accessed in succession due to the fact that my terrain engine auto-tesselates. So would VBO's be better or displaylists (i can create display lists for each possibility but this will take alot of ram) So what do you think? You can view the project here http://www.geocities.com/djspy187/Stretch.zip

Share this post


Link to post
Share on other sites
In my experience with my NVidia GeforceFX, Display Lists are often faster than Vertex Buffers. That is true when you will treat with static geometry,
and the display lists must be recorded with glBegin-glEnd commands; Means that you shouldn't use glVertexPointer() command when making a display list, because it won't store vertex data at GPU. So you have to use glVertex3 like commands instead.

But VBO are useful when you are dealing with Vertex Programs, because Display lists aren't accessible on programs.

Share this post


Link to post
Share on other sites
VBO's are better to be used for data that is completely ready to be read. It shouldn't be needing re-orginization, change, etc... You could use a VertexPointer to you're VBO, and then use the VertexArray function to render certain elements before others, but that's about it.

Share this post


Link to post
Share on other sites
Quote:
Original post by dawidjoubert
So would VBO's be better or displaylists (i can create display lists for each possibility but this will take alot of ram)

So what do you think?

For this amount of static vertices, definitely a VBO in static_draw mode. For the indices, it depends on how dynamic they are. What are you doing ? ROAM or geomipmap style ? Ie. completely dynamic per frame, or several precomputed index chunks ?

Quote:

But VBO are useful when you are dealing with Vertex Programs, because Display lists aren't accessible on programs.

What do you mean ? The card doesn't care what the source of the vertex data is, VPs will work just as well on VBOs, VAs, display lists, or immediate mode. If you mean render-to-VBO functions, well that's a different thing. But this is not needed in this scenario.

Share this post


Link to post
Share on other sites
Thanks for the replies to clear things up.

The VERTEICES (of the quads) are completely static its only the linking of the quads that change.

Consider this a grid of vertices

1 2 3 4 5 6 7 8
9 10 11 12 13 14 15 16
..

Now when ur close 2 the terrain it is tesselated 1-9-2-10-3-11-4-12 (using quad strips)

but when ur further it would be 1-9-3-11-5-13
and even further 1-9-4-12-8-16

Does that make sense?

Share this post


Link to post
Share on other sites
Putting the verticies on the GPU memory is faster, and it does have it's benefits, but because you're calls are going to be very "unorganized," it might be a better idea to just keep it in RAM do to the ammount of render calls you're making. VBO's are useful for terrain, skeletal animation, basic LOD... But when you're doing stuff like that, you're asking for some problems in you're code/slowdown.

Share this post


Link to post
Share on other sites
Quote:
Original post by dbzprogrammer
Putting the verticies on the GPU memory is faster, and it does have it's benefits, but because you're calls are going to be very "unorganized," it might be a better idea to just keep it in RAM do to the ammount of render calls you're making.
It is NEVER better to keep it entirely in RAM. Not ever! Correct usage of the various buffer flags is always going to be as fast or faster (assuming no driver bugs etc).

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Quote:
Original post by dbzprogrammer
Putting the verticies on the GPU memory is faster, and it does have it's benefits, but because you're calls are going to be very "unorganized," it might be a better idea to just keep it in RAM do to the ammount of render calls you're making.
It is NEVER better to keep it entirely in RAM. Not ever! Correct usage of the various buffer flags is always going to be as fast or faster (assuming no driver bugs etc).


You're correct on that statement. But unless he's making Unreal 3, or a game like it, and needs to do this, this is most likely going to get him some errors from his code.

Share this post


Link to post
Share on other sites

This topic is 4391 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.

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