I dont think you either want nor need to do it this way.

Even on a decent SM3 part its unlikely you'll do more than 4-8 lights per pass. Thus keep the effect file simple and offload the calculations to the CPU.

If you write up shaders to do 4 lights per-pass but have 10 lights then just do:

Pass 1: lights 0,1,2,3
Pass 2: lights 4,5,6,7
Pass 3: lights 8,9,-,-

hth
Jack

I dont mean offloading the actual lighting calculations to the CPU - just the management of them.

Unless you're doing dirt-cheap N•L lighting you'll probably want less than 10 active lights per scene/frame - otherwise performance will start to drop off.

So, if your game world is defined with 1000 lights... In the same stage where you examine what geometry to render (with whatever culling system you have) you determine which lights also affect that particular view. You can just select all lights (even if it is very high) or you can then re-order this subset and pick the N most influential lights.

When you've got your list of lights you can break it up into a number of passes according to the current hardware and available effects.

SM1 hardware will probably be limited to 1-per-pass, maybe 2-per-pass with SM2 and then upto 4-6 with SM3 (you get the advantages of flow-control). Thus you'll end up with a number of passes and a number of lights for each... so between each pass you update the lights (like I listed in my first post), CommitChanges() and then re-render the scene.

There are many other possibilities for this sort of work - it all depends how much effort you want to put into it [smile]

Bottom line though - the actual shaders (and FX framework) dont need to know about all the lights in the game-world - just the currently relevant/active ones.

hth
Jack