As I worked through the dot3bump demo, it occurred to me that it currently wasn’t that easy to write a programmable material pass which dealt with an arbitrary number of lights. We do automatically ‘black out’ light information which is beyond the range of the number of lights currently close to the object being rendered (so that if your programs assumed 2 lights and there was only one in range, the second one would be black), but this isn’t ideal as a general case.
So, I';ve deceided to add another new feature to the ‘pass’ section of the new material scripts, an ‘iteration’; attribute. This defaults to ‘iteration once which is the standard behaviour where a pass is run once per object, and all the lights in range are set at once (up to the limit you set, or as limited by the rendering API). However, if you set ‘iteration once_per_light’, then the pass is run once per light which is in range of the object, and on each pass, the current light details are presented in light index 0 so your vertex and fragment programs only have to worry about one light. Of course, you have to ensure that the effect you’re applying composites well (such as additive lighting), and you should also make sure you have an ambient-only pass before the iteration pass to ensure that if no lights are nearby, the object still gets rendered.
I’m working on this feature now, and plan to use it in the revised Dot3Bump demo so you can pick the number of lights you want to render (people with high-end cards can run more lights clearly).
By the way, I apologise to IE users about the SQL debug pop-up windows that were previously appearing on this site; I use Firebird all the time so I didn’t know (since Firebird squashes pop-ups for me). They have been removed.