I have programmed all drawing data into one display list. This is what I have done always. I am wondering if you can use multiple display lists and is there any advantage in doing this?
Thanks,
Billy.
The biggest penalty for using multiple display lists would be the time it takes to call the glCallList() function. If possible, try to have them all “lined up” for a glCallList[b]s/b.
I believe it’s common practice to use multiple lists, especially for TRS animations of static objects. If you have a very talented artist, it’s also possible to use them for character animation and IK systems. OpenGL optimizes the drawing commands as best as possible, and display lists will always outperform immediate mode operations ( unless you’re submitting only 3 or so vertices through the list - then the overhead of the call outweighs the performance gain ).
I’m no expert, though, so if anyone else has an opposing or differing view, let me know.
Dave
[This message has been edited by lpVoid (edited 03-27-2001).]
For most applications, a small number (one in the optimal case) of display lists is the way to go, as it minimizes the number of calls to the driver, which are costly. (I believe all GL calls go to the driver.) But with a single display list, there is no way to modify anything rendered in that display list across frames without recompiling the list every frame, which defeats its purpose. Q3A deals with this by passing just about everything to the driver in a single call to glDrawElements per frame. It requires a bit of tight-rope-walking to accomplish this, but id has proven that it can pay off handsomely. Brian Hook, one of the graphics programmers at id, has a video at http://www.gamasutra.com/features/ (see GDC 1999 Video: The Quake 3 Arena Rendering Architecture ), which talks about this and other optimizations in the Q3A engine.
I’ve heard (perhaps I am thinking of vertex arrays…) that DLs have some “sweet spot;” they become more efficient up to a particular point after which they start doing poorly. In any case, this would be a totally driver independent thing. What the hell is inside a display list, anyway?
One thing to try is hierarchical display lists. Basically, you have one “root” display list that calls several “child” display lists. This can go on recursively (but not indefintely so), so it can provide a very clean way to organize the crap you need to draw. An added benefit is that you can modify a sub-DL without having to recompiling the whole shebang. There is overhead in compiling DLs; you should try to execute a DL at least 5 or 10 times for every time you need to recompile it, otherwise you might as well just use immediate mode.
Oh, and apparently GL_COMPILE_AND_EXECUTE sucks for some reason. Only GL_COMPILE gets you good performance.
It’s possible to get DL-like performance with dynamic geometry but at a considerable cost of complexity. This is what max was getting it…you need to use compiled vertex arrays (and possibly NV_fences) and take care of which vertices get modified, which vertex formats you use, etc. Obviously, it was worth it for Q3, but for a simple demo, probably not. It’s probably a good exercise that everyone should do at one point (me especially).
Oh, another good use for DLs is to encapsulate various state changes that you use frequently.
-Won
[This message has been edited by Won (edited 03-27-2001).]