Rendering method of choice?

Member
Posts: 40
Joined: 2004.12
Post: #1
For you OpenGL pros, what is your preferred way of rendering and storing vertex and normal and face data? So far immediate mode is just too slow once you have over 1000 vertices (obviously), and I am seeing huge performance gains using display lists. But what would you all say are the advantages and disadvantages of vertex arrays and display lists?

Thanks for the help!

Jericho
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
display lists are fast
vertex buffer objects are flexible and not too slow
immediate mode is easy
Quote this message in a reply
Moderator
Posts: 608
Joined: 2002.04
Post: #3
Display lists for static geometry, vertex arrays for dynamic.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #4
I made a test, a while back, switching my terrain engine from drawing ( scene graph managed ) chunks as VBOs to display lists.

The terrain has only about 30k triangles, and at any given moment the scenegraph culls all but about 5 to 10k, but using display lists my performance was something like 10 times worse than with VBO.

Perhaps it's just something peculiar about my card? (NVIDIA 5200 FX Go)
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #5
How are you using display lists?

If they're applicable, and you've got enough geometry in each list, they should always beat the other methods of drawing.
Quote this message in a reply
Member
Posts: 144
Joined: 2004.07
Post: #6
TomorrowPlusX Wrote:I made a test, a while back, switching my terrain engine from drawing ( scene graph managed ) chunks as VBOs to display lists.

The terrain has only about 30k triangles, and at any given moment the scenegraph culls all but about 5 to 10k, but using display lists my performance was something like 10 times worse than with VBO.

Perhaps it's just something peculiar about my card? (NVIDIA 5200 FX Go)

How many different display lists did you have? (as in how many vertices per DL then)

glCallList() isn't cheap to call... (glCallLists() is much better)
Quote this message in a reply
Puzzler183
Unregistered
 
Post: #7
Vertex buffer objects are the fastest way to push huge amounts of vertices. They basically stack right on top of vertex arrays - and should be easy to do on Mac since you don't need the extensions stuff. They are definitely the way to go.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #8
Puzzler183 Wrote:Vertex buffer objects are the fastest way to push huge amounts of vertices. They basically stack right on top of vertex arrays - and should be easy to do on Mac since you don't need the extensions stuff. They are definitely the way to go.

Wrong. Display lists are faster, just not always applicable.
Quote this message in a reply
Puzzler183
Unregistered
 
Post: #9
Uhm... It could be different on Macs I suppose - however, vertex buffer objects load the vertex and other data into the high performance memory of the card on PC and provide the most raw vertex pushing power; you can't have state changes or that like you can with display lists but they are the fastest (on PC).
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #10
Displays lists are faster on Mac. They also try to reside in VRAM, and they optimize the state changes (with some caveats.)

Of course you should use VBO/VAR for dynamic data.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #11
lightbringer Wrote:How many different display lists did you have? (as in how many vertices per DL then)

glCallList() isn't cheap to call... (glCallLists() is much better)

The terrain is subdivided and simplified ( from maybe a quarter million triangles to about 25 to 30k ) via a quadtree. Once it's simplified it's divided up into some number of square regions -- say the whole terrain is divided up into a 16x16 grid -- and each in my current implementation then creates and uploads a VBO representing it's particular vertices and triangle indices.

The scenegraph decides which regions need to be drawn, and at any given moment you rarely can see more than 4 or 5 regions. Each region has -- depending on geometric complexity -- anywhere from at a minimum a few dozen to a few thousand vertices.

The VBO implementation and the display list implementation are 99% the same. The only difference being that in the display list version I just drew the geometry and saved it in a dlist, whereas with the vbo I upload it all and then play it back.

Running it with VBO shark tells me my graphics thread is only spending ~4% of cpu time drawing terrain. I didn't bother sharking the display list version -- the performance was so awful I went from 30fps to about 2.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #12
One more thing -- I'd very very much like to get a display list version working well, provided it can be done. My terrain won't display on a GF4MX! Even though the card *reports* VBO support, all I get is noise when it runs.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #13
If this is the same project as before, you've already exceeded the capabilities of the GF4MX by using too many texture units.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #14
arekkusu Wrote:If this is the same project as before, you've already exceeded the capabilities of the GF4MX by using too many texture units.

It is the same project -- but I check for the number of texture units and use a different texturing path accordingly.

That said, I was disturbed by the poor performance of display lists and last night I re-implemented it.

Turns out -- and this is where I should be eating my hat -- I must have done something completely bone-headed last time. Now, using display lists I get exactly the same performance as I get with VBO. Which is awesome, since VBOs precluded the use of normal vertex-buffers before. Now I can use vertex buffer for stencil shadow casting, which I was able to verify a few months ago is about two or three times as fast as drawing my shadow volumes in immediate mode.
Quote this message in a reply
Vertizor
Unregistered
 
Post: #15
Puzzler183 Wrote:Uhm... It could be different on Macs I suppose - however, vertex buffer objects load the vertex and other data into the high performance memory of the card on PC and provide the most raw vertex pushing power; you can't have state changes or that like you can with display lists but they are the fastest (on PC).
Whoa there, "vertex buffer" ??? That's DirectX talk now isn't it? Caught ya!

Vertex buffer vs. Display Lists is a moot argument because, well they're basically the same thing. DirectX creates vertex buffers and you arrange your data inside the buffer then stream it out to the video card. They can be kept in the video card's resident rememory for performance's sake.

Display lists is the OpenGL word for the same technique. I wouldn't go as far as to say one is better than the other, nor try to benchmark them because all it is, is just preloading and caching data. Afterwards it's still up to the rendering pipeline to consume that data.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  A More Accurate Volumetric Particle Rendering Method Using the Pixel Shader SethWillits 4 4,560 Jun 11, 2008 01:50 PM
Last Post: AnotherJake