How can i make my lighting even faster...?

My application contains a large number (100’s) of 3d models (max 1000 triangles), the models have material properties but no textures so in order to see the model detail correctly I’ll need to light them. Problem is with so many models plus the lighting the FPS drops through the floor.

The 3d models are static in my world, as are the lights there just global directional lights really. The camera position is dynamic; the user can fly around the 3D world and look at the objects from any position.

So to speed things up I thought I’d calculate the static lighting effects for each vertex of the model (work out the combined effect of ambient, emissive, diffuse lights/materials following the math in the red book) and uses these per vertex colours rather then the lighting in opengl when I render the model. This way I can put all the model drawing inside a display list and the end result should be significantly faster than using the dynamic lighting in opengl as the calculations only need to be done once and then everything is stored in the list.

However, this approach falls down when I need to consider the specular part of the light/material because this component relies on camera position, which is dynamic. I think I have two options.

  1. recalculate all the vertex colours whenever the camera moves, but this will probably be slower than the original opengl lighting!
  2. Find a way to mix and match i.e. use the per vertex colour I pre-calculate for the static light effects and then use the open gl lighting for the dynamic specular component.

Questions is how would I achieve the later?

Has anyone done this?

Is it even possible?

Alternatively are there any other techniques I could try ?

Thanks in advance

Separately calculation the specular with the OpenGL lighting engine will do the same calculations as with the complete lighting setup. If there aren’t optimizations in the hardware which reduce the calculations for black ambient and diffuse you get no gain.

Put the world into display lists anyway, even if you use OpenGL’s lighting.

There is a secondary color which can be used as, uhm, second color on top of your base colors. But you need to calc that per frame anyway.

You can try non-local viewer positions to speed up that calculation. But this gets wrong visually.

Or better you can use the prelit geometry and modulate it with a refelcted cube map texture which contains the highlight at the correct spot, this will give nice phong highlights even on coarse geometry.

Relic, the last option sounds interesting, any more info/details?

does enabling standard opengl lighting really slow down a program? never heard of or experienced that…

well you can of course do the whole lighting per-pixel, but for diffuse AND specular lighting in one pass, you do at least need gf4 ti and nvidia register combiners (or the corresponding thing from ati). but if you do so, you can implement bump mapping as well and this will loke great (and still only needs one pass).

If you’re going to do the calculations by hand, you have the option of recalcing the specular component every other frame. You’ll essentially double your framerate, but it might look awkward depending on your actual framerate.

Furthermore, you could enable a multi-threaded system. While one thread is drawing a frame, the other thread is calculating the lighting based on camera coordinates for the current frame. This could be an ugly solution though.

Read the PDF on