Runs very smooth on my GTX 285 for 700 lights.

I can see that only few lights affects each 3D objects.
And it's simple 3D cubes !
So putting 700 really doesn't mean nothing
Instead you should do a demo displaying how many simultaneous lights are affecting the objects each time and put it on a complex 3D scene instead with houses , trees, terrain to see how it behaves!

Only last 3D cards with pixel shaders 4 if i'm not wrong ???
Allow to do deferred shading : lot of simultaneous dynamic lights affecting the entire scene. Before it was impossible or performance was incredibly bad with standard shaders.

It would be the same if it was 700 lights affecting one single object. That's the beauty of deferred rendering, and this has some tricks to make it even faster.

I don't know about Hummel's particular code, but deferred shading can be done taking advantage of MRTs as early as shader model 2.

In fact, since 3DGS uses DirectX 9, it couldn't possibly require a shader model 4 card.

Deferred shading isn't performance hungry at all -- that's the whole point of it. And that's why you can have hundreds of lights affecting each object.

Jibb

@ratchet: the performance does not depend on how many lights affect a single object. Look into my start post.
The lighting speed is independend from the complexity of your objects.
Shader version 4 isn´t supported by GS at all.
What I do here is not really deferred shading, but I make use of MRTs and a single post processing effect with about 20 pixel shader instructions.

While I haven't read the paper in detail, I got the impression that it is deferred shading, but it just does things in a different order to reduce the amount of texture samples that need to be taken.

Jibb

the original Light pre-pass doesn´t use any MRTs, it replaces the deferred renderer completely but requires to render the scene twice.

Ok, im not specialist about shaders !
So , now you just have to incorporate your great rendering shader in the A8 package

Okay, I see that now.

So, the advantage is that objects can more easily have their own material properties while still having many of the advantages of a deferred renderer (specifically, the ridiculous amount of light-sources)?

Jibb

that seems to be the idea but the lighting is much more efficient than adding a render pass for each light to the whole screen like you do it with DS

27 / 17 / GF7900GT

I wasn't aware that deferred shading normally does each lighting pass to the whole screen -- hence the confusion here I've never actually read much on deferred shading. For the summer contest last year I had a deferred renderer that rendered each light as a sprite so that if the light's range occupies very little screen space, the lighting would be calculated on very few pixels.

Of course, it needed a little work (everything was out by half a pixel, and if the sprite passed just behind the camera it would get clipped away completely, removing the effects of the light), but I guess it's a similar thing.

And of course, it was still just deferred shading -- not a light pre-pass rendering chain.

Jibb