The second geometry pass is what allows you to do MSAA in deferred lighting, and again, that can be done with deferred shading as well.

On the question of performance, I make an argument that “deferred lighting” has not been more efficient than “deferred shading” in my experience, but people frequently disagree with me using the term “light pre-pass.” I’m not sure if it was originally intended this way, but I now consider the term “light pre-pass” to imply a monochromatic or otherwise limited specular model. If that is true than I can absolutely see the performance advantages of light pre-pass over traditional deferred shading, but I’d also want to make a more fair comparison using a variant of deferred shading which doesn’t implement true Phong shading.

I was in Matt and Rich’s talk, however, and they definitely distinguished between deferred lighting and deferred shading, and described them much as I’ve described them in this article.

Also, with light prepass it is possible to use hardware multisample anti-aliasing on current console hardware (where msaa is not allowed with multiple render targets)

In my experience light prepass was faster on ps3 than on 360, partly because of the “depth bounds test” which only exists on nvidia hardware and can cull many of the light volume pixels before shading. However, we used 32 bpp render targets for the light buffer, (in rgb-exponent format on ps3, where blending can be handled in pixel shaders by reading the framebuffer before writing, and flushing the texture cache occasionally)

Correct me if Im wrong, but doesn’t Calvers article actually describe *Deferred Shading*, with full G-Buffers and only one geometry pass? To further fuel the confusion

Pritchard and Geldreich’s presentation is the first place I’ve seen name used. Might see if I can get hold of either author.

Cheers again

I was just wondering if you would care to provide a reference to the original description of “deferred lighting”. I have found the exact technique described in a paper from 2003:
“Optimized Shadow Mapping Using the Stencil Buffer”, JGT 2003, Jukka Arvo and Timo Aila,
but they dont refer anywhere for the technique in particular, and do not give it a name.

Hope you still get notifications from this thread

> adding a new type of node to Façade is as simple as creating a new shader fragment and
> annotating its public-facing variables.

How did you handle preshaders (pulling out and evaluating uniform expressions on the CPU) then? That’s an important optimization in my experience.

> the plain old HLSL uber-shader approach gives comparable amount of headache when it comes
> to the combinatorial explosion of permutations and their compilation time.

I think the compile time of permutations is a solveable problem with some work. You can parallelize and even distribute shader compilation, speeding up shader compiling by orders of magnitude.

One of the big disadvantages of offline shader compiling is the memory required to store all the permutations that get generated. It helps to compress all the shaders in chunks and only decompress as needed, but it will still be a significant amount of memory (usually 10-15mb on 360).

However, there is another factor that separates offline and runtime compilation. Since CrossStitch shaders are pieced together at runtime, the “data” that defines whole shaders is partially platform-dependent C++ code. To write an offline compiler, parts of our renderer would either have to be duplicated in a PC tool (and then kept in sync) or factored out in such a way that the same code could run on PC and (for example) Playstation 3 without additional cost.