default vertex lighting performance

Hi,

I’m doing ‘environment lighting’ by placing 6 directional lights around each object when it is drawn. The diffuse light values are precomputed and stored in a 2d lookup map (kinda like 1x1 pixel cubemaps). This serves as a fallback path for older hardware that do not support vertex/pixel shaders.

I expected vertex lighting to be fast these days, but it turns out to be pretty slow.

I noticed a slight performance increase when GL_LIGHT_MODEL_LOCAL_VIEWER is set to GL_FALSE. Does anyone know of other (similar) tricks?

Thanks.

For GL_LIGHT_MODEL_LOCAL_VIEWER, default is GL_FALSE

There is also GL_LIGHT_MODEL_TWO_SIDE, default is GL_FALSE and keep it like that.

There is much more that can effect performance. Vertex lighting is not a big deal for TnL hw.
What hw are you testing on?

I’m rendering a bunch of textured low polygon objects (currently a teapot, and around 10 boxes, good for 3000 triangles). Just triangle soup rendered with vertex arrays (no VBO yet), haven’t gotten around to rewrite my export scripts to triangle strip them etc. I know that probably tripples the amount of lighting calculations but with only about ~3000 polygons I expected it to be faster than this.

The framerate more than doubles when I disable all lights but one.

Testing this on a GeForce4 4200 Ti. Perhaps (the drivers) are optimized for < 6 lights?

Originally posted by remdul:
[b]Hi,

I expected vertex lighting to be fast these days, but it turns out to be pretty slow.

I noticed a slight performance increase when GL_LIGHT_MODEL_LOCAL_VIEWER is set to GL_FALSE. Does anyone know of other (similar) tricks?
[/b]
A GF4-4200 is not exactly state of the art, these days. :wink:

6 lights are quite a bit of math to do, so unless your polygons are very large, your system will be vertex-limited. If you can replace the 6 light sources with a simple texture lookup that will probably be more efficient. Or do the calculations in a shader, and take advantage of the fact that the 6 light sources are orthogonal, which the driver won’t do.

I had thought of that too, and you’re right. I was aiming for a non-shader approach but it can be done faster (and more accurately) with a vertex program.

Thanks for your comment dirk, for making me re-consider the idea. :slight_smile: