Lighting the cockpit, pt. 2

Changed exporters to read object name, and initialise the file/save dialog with the correct name. This should make it much quicker to export objects and also makesexplicit and easy the rule that you must save the mesh file to the same name as the object. i.e. As long as you name your object, export is as quick as pressing run exporter and OK.

Added 4 lights into the cockpit. This runs slow! It's now doing 5 passes over the entire scene with shadow-mapped lights.

Optimise the lighting - get lights to cull their drawCommands against both the camera and the light. Skipping doing any culling at the Python Scene level, done immediately in c++

Solution - LightingRenderChannel has lightCuller_ and cameraCuller_ these run lightculler then cameraculler.

Bug - You can see black squares around the light frustum. Fix by turning off the AmbientLightingChannel.
Looking into why meshes bound to AmbientLightingChannel are causing the lighting anomaly

ambient_cube_map.vsh : Outputs the projected position and the world normal to o0 and o1

ambient_cube_map.psh : Samples from the dynamically generated ambient cube map

ambient_cube_map.mat : [cubeRenderTarget] ambientCubeMap

Problem - AmbientLightingChannel is now culling to the light frustum. Out of frustum, all there is is SSDO colours.
Hmmm - See following code in LightingRenderChannel:

//BIG HACK
if ( rtName == "AMBIENT" )
{
multiplicative_ = true; rtName_ = "lightMap1";
}

This explains the lighting bug; ambient lighting is hacked into the standard LightingRenderChannel, and is culling against the first light. removing :
- lightCuller_.culled(bb) the bug is fixed, however the performance improvement is still not in place
- fixed with a hack in lightingRenderChannel : don't cull by light when this is 'ambient' channel.. erk

Proper fix :
- python property on LightingRenderChannel - whether to cull to light's volume or not
- or, don't use LightingRenderChannel for ambient lighting - its more just like a post-process

Now need to cull the light projection matrices to their far attenuation radius. Then will need to actually do the attenuation too.

Quick thoughts :
The near/far plane should be passed into most shaders as shader constants from C++
Idea : have shader files/xml sections include 'state blocks'. These files describe, for example, sets of shader constants such as those explicitly hard-coded in c++ right now. Thus instead of 'set lit world mesh shader constants', you wrap those up in a '.stateblock' file, treat them as stateblocks just like .material files, and render channels can optimally sort by these.

Final screenshot shows an intermediate step from last night with just the lighting channels turned on. There's the main front white light, and the red light from the cockpit spilling out onto the land. This was before I added the attenuation in from the lights in Max, and this is why it was running so slow! Looks pretty cool though, and it's nice having an arbitrary number of full shadow-mapped lights to play with :

It's really useful with the way the render channels are setup, that individual channels can be turned off. Debugging lighting is much easier when you can toggle all the other stages of the pipeline off at runtime.