I've been on a massive Lighting bender this last week. Not a huge amount of this is immediately obvious in a screenshot, but it's been a serious hack for a long long time now.

The Light objects themselves used to be created as renderer specific subclasses (GLLight, DXLight). The problem with this is that those subclasses were implicitly really GL*FixedFunction*Light and DX*FixedFunction*Light. So there were these Enable/Disable methods on the light which simply turned the light on in the underlying fixed function pipeline. This was obviously useless for hardware shaders (which essentially ignore fixed function lights - unless of course you want to roll the performance dice with GLSL). To address this, the Light class has now become just a logical description of the light, and each class of material (GL fixed function, Cg, HLSL, GLSL) has it's own internal LightManager. Whenever a shader of that type is asked to render anything, the first thing it does is pass the current render context (which includes the active lights, view matrix, base scene transform, etc) to the manager to setup the lighting that type of shader needs. This gets cached across different shaders, so we only setup any one configuration of lights/view once per frame. This also means that all the fixed function state (lights, view matrix, world matrix) isn't being set at all when using Cg, which makes me happy.

The Cg shader lighting is implemented using Cg interfaces with unsized arrays. It's super cool ... though I still need to add a Cgprogram cache so I can support multiple light configurations in a given scene without suffering shader compiles in the draw loop. So now, by simply including "Lights.cg" at the top of your shader and dropping a simple light loop into your pixel shader, you can get nice per-pixel lighting driven straight off the lights in the scene.

Next I added Cg shader and GL fixed function support for ranged point lights and spot lights, and refactored the stencil buffer shadow code so it could support point/spot lights. Seeing nice long shadows dancing around is pretty hypnotic - even if it may not be the best gameplay setup (Doom3, I'm looking at you).





Finally, I fixed a lot of hitherto mysterious crosstalk bugs in the rendering code (e.g. if you tumbled the camera in the editor, the lighting on all the objects in the pallete would tumble around, and when you walked through a door, all the lights on the UI would flip around based on the coordinate change through the portal). It turned out a lot of rendering code went straight to "The Camera" to find out how the scene was being viewed, while other code just assumed the current GL view matrix is the one it should be using (lights were an example of this). All of this madness was fixed by making sure every object (light, shader) goes through the render context object that it has been told to render with to ensure it's always using the correct matrices. The UI (which used to inherit render state from the scene render) now has a formal "identity" render context that makes sure it renders the same way irrespective of what's happening in the scene.

Cheers!