VBO vs DisplayLists
Author
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
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.
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.
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.
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.
Author
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?
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?
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.
Quote:Original post by dbzprogrammerIt 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).
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.
Quote:Original post by PromitQuote:Original post by dbzprogrammerIt 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).
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.
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.
Quote:Original post by dbzprogrammer
this is most likely going to get him some errors from his code.
yes, this is a process we call 'learning'...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
