Isnt it still a good idea to use Display Lists for repeating objects, as well as to encapsulate glTranslate/Rotate/Scale/Color calls in them ?

Nitzan

-------------------------
www.geocities.com/nitzanw
www.scorchedearth3d.net
-------------------------

> Isnt it still a good idea to use Display Lists for repeating objects,

Can be better handled using VAR in video mem. It''s faster. But nVidia proprietary.

> as well as to encapsulate glTranslate/Rotate/Scale/Color calls in them ?

Yes. This is a good example where display lists get very useful. You can use them to switch states, esp. if lots of gl* function calls would be necessary, eg. for complex texenv or regcom setups. The speedup can be enormeous, since the state changes get encapsulated into their most efficient format for the 3D card. Memory usage is no question either. I think it''s OK to store anything other than geometry in DLs. For geoemtry, they are outdated, and have been replaced by more efficient methods.

will a display list still speedup gl* calls if you dont include the geometry ?

Nitzan

-------------------------
www.geocities.com/nitzanw
www.scorchedearth3d.net
-------------------------

> will a display list still speedup gl* calls if you dont include the geometry ?

Well, it depends.

By definition, a display list will produce the exact same results than the individual gl* calls you compiled into it (with a few rare exceptions). OGL doesn''t care, if there is geometry in it or not, for the GL it''s just another call (glVertex or glDrawElements, etc).

So, when you replace individual gl* calls by a DL, you will remove all the gl* call overhead, data conversion, error checking, etc. But the display list itself will reintroduce some little overhead again. So, if you only encapsulate one or two gl* calls in it, it will be slower, or the same speed at best. But when encapsulating eg. a complex env setup for a regcom (that''s for what I use them), that can easily contain 30+ glCombiner* and/or glTexEnv calls, you''ll get a great speedup.

Would compiling all the material properties (ambient, diffuse, specular, emissive, shininess ) in a display list improve performace?

I made a simple class for materials that compiles the (static) properties automatically, detecting if the ambient is equal to the diffuse component, and using GL_AMBIENT_AND_DIFFUSE (or whatever it is) instead of making both calls.

When I made it, I was assuming it would be faster..

What do you think of it?

> Would compiling all the material properties (ambient, diffuse, specular, emissive, shininess ) in a display list improve performace?

Following the theoretical principle: yes. You would have to include more than one material change in one DL call, though. Otherwise, the additional overhead isn''t worth it.

> I made a simple class for materials that compiles the (static) properties automatically, detecting if the ambient is equal to the diffuse component, and using GL_AMBIENT_AND_DIFFUSE (or whatever it is) instead of making both calls.
> When I made it, I was assuming it would be faster..

Checking and avoiding redundant state changes is always a good idea. Just make sure, you don''t compile a single gl* call into a DL. You could make an adaptive system: if a static state change requires only one or two gl* calls, then perform them on the fly. Otherwise use a precompiled display list.