Originally posted by vlada:
[b]what do you think about nested display lists?
one layer could contain body of object (containing only glBegin/glEnd pairs with Vertex/Normal/Material definition, and other layer could be made of small display lists containing function calls for defining motion (glRotate, glTranslate, glMultMatrix, etc…) and calls for drawing the body of object
so in order to move part of object, you would have to redefine only portion of display lists (one that is in second layer).
I have done this recently, and I’ve tried to describe it in one of my posts here. However, I am not certain that this is optimum solution, allthrough it sounds good.
There is possibilty that frequent changing of small display lists will result with video card memory fragmentation.
With this technique I’ve been able to get over 120k triangles per scene at 20fps, with blending, texturing, fog and full lighting.
I’ve been using low-end ATI card that is over two years old.
Since I’m a only beginer in OpenGL waters, I can’t say if this is success or not… I’m hoping to get some comment from you.
i guess you are asking me. i’m no expert on display lists… but i was intending to do something similar to that actually, but not really.
if you want what i think of display lists ( i could very likely be wrong ) … they aren’t good for very much when it comes to serious applications as it stands. they are useful maybe when you want to draw something very small and quirky with gl type transforms and flat shading or something. but not for much else right now.
if you are wanting to draw a big object, you need to read up on glDrawElements et all, and probably eventually look into the VBO extension when you are ready to work with extensions if you are not already.
i was personally intending to use two lists per object. the first list would be a MultMatrix with a floating point matrix embedded in it, and a VBO binding sequence. the second list i was planning would be a glDrawElements call. for my app it would be useful to be able to change glDrawElements indapendantly. but you are right, that if nesting is implimented effeciently i could just maybe tack the second onto the first inorder to cut the size of the glDrawLists string in half.
but unfortunately display lists aren’t good for DrawElements right now… well it may work by transforming the call to a sequence of glVertex commands, but apparently it won’t encode glVertexPointer etc. they would be a lot more useful if they could, by allowing command sequences to be stored in video memory, so that the commands did not have to be sent across agp and touched by the driver.
as far as memory fragmentation, i would recommend always regenerating display lists with the same sequence of commands only with different arguments. if you mix it up, it would enevitably cause some kind of fragmentation… then you would have to count on the driver to manage your memory more than necesarry, and personally i always do my memory management my self when possible… but that is just me.
hope that was helpful.
the problem these days… or at least the impression i get from different sources, is a single gl API call can require as much downtime as managing 1000 plus triangles asynchronously. this effectively punishes you for wanting to draw an object with fewer than 1000 triangles, like say a simple rock. so rather than doing a 1000 triangle rock, you may as do a 1000 triangle boulder. it kind of warps the way people aproach building scenes. the only real way to rectify this is to speed up the bus (agp etc)… but an expanded display list repetoir could also help in this vein a bit in many cases.
still though, judging by the general complexity of geometry i see in video game adverts… i don’t think this is a big deal right now were moderatly complex shaders are at work. but there appears to be a trend forming in this direction.