Light Pre-Pass vs Deferred Renderer – Part 1

My questions

I have recently decided I want to spend some time experimenting with various approaches to renderers being used across PC and console games these days. In particular I wanted to look more closely at pros and cons of “traditional” Deferred with respect to Light Pre-Pass renderer which is slowly becoming more and more popular.

(1) What are the differences between the 2 approaches?
(2) What are the main limitations of each approach and what tricks do people do to workaround these?

These were my key questions which I can hopefully answer now, at least to some extent. If you just want to learn more about both techniques you may still find some useful information here.

Quick intro

Before I start I want to do a quick reminder on how each method works in a nutshell:

“Standard” deferred shading is a 2-stage process:
(1) draw (opaque) geometry storing its attributes (i.e. position as depth, normals, albedo color, specular color and other material properties) in a number of full screen buffers (typically 3 or 4)
(2) for each light source, draw its volume and accumulate lit surface color into final render target

I recommend you take a look at these great Killzone 2 slides for more detailed overview of sample deferred renderer implementation.

Light pre-pass is a 3-stage process:
(1) draw (opaque) geometry storing its attributes necessary for lighting (i.e. position as depth, normals and specular power)
(2) for each light source, draw its volume and accumulate just the lighting into an additional render target
(3) draw (opaque) geometry again; evaluate full material shader and apply lighting sampled from a buffer generated in step 2; this step is de facto forward shading

Read more on light pre-pass on Wolfgang Engel’s blog or in his presentation. Also, take a look at this highly informative presentation by Insomniac from GDC’09.

My answers

Now that we know the basics, let’s go over each of my initial questions and try to give answers to each:

(1) What is the key difference between the 2 approaches?

Number and cost of drawing stages
The first obvious difference is that light pre-pass requires 3, not 2 stages. On one hand this sounds like more expensive because you have 2 geometry passes in light pre-pass instead of 1 in deferred shading but on the other hand both of these geometry passes are cheaper. In light pre-pass, the first geometry pass only outputs what’s necessary for lighting phase: depth, normals and optionally specular power. The second geometry pass (3rd stage) doesn’t typically need normals and it may take advantage of early z cull, including hierarchical z cull on some hardware – hence the depth has already been written. Unfortunately the first geometry pass isn’t going to be as fast as just a depth pre-pass, especially on hardware with support for double speed depth pass – this is because we also output normals and specular power. For this reason, with light pre-pass, it might even be worthwhile to use custom CPU/SPU based geometry occlusion system.

On the other hand light pre-pass has considerably lower bandwidth and memory requirements – no heavyweight 4-render-target output and sampling needed any more. In fact, light pre-pass might even be doable without MRT (only if you can read depth straight from depth buffer i.e. X360, PS3 or DX10/11).

There’s an interesting post mortem by one guy who implemented both light pre-pass and deferred renderers in their engine on 3 platforms: X360, PS3 and PC. He says he got better performance with deferred renderer mostly due to having single geometry pass.

Material variety
One of the benefits of light pre-pass is it gives you a bit more freedom in terms of material variety (compared to deferred shading). It means you can run different shader for each geometry and so, you can calculate final lit surface color differently. Instead of having single pass per light as in deferred shading, here we’re having single pass per mesh. Having said that, you’re still quite limited in terms of variety in lighting models because available lighting attributes have already been calculated (during 2nd pass) – these typically only include accumulated Phong shading factors being N dot L and (R dot V) ^ SpecularPower (typically with light color and attenuation factors applied).

MSAA
Another nice feature of light pre-pass is that it works much better (again, compared to deferred shading) with MSAA. It’s still not going to be 100% correct MSAA (unless DX10/11 level features are used) because lighting buffer used in the last drawing pass won’t be sampled at MSAA’ed resolution (talking about light buffer sampler here). However, it’s fairly trivial to get MSAA’ed geometry with non-MSAA lighting which may yield pretty good results.

(2) What are the main limitations of each approach and what tricks do people do to workaround these?

Transparency
With both deferred shading and light pre-pass transparency is still typically done using old school forward shading after opaque geometry. There’s no efficient way around this, at least none that I know of.

MSAA
With deferred shading it’s become standard to use some kind of post-processing to smooth the edges. This can be as simple as finding edges based on depth and normals and blurring these – see GPU Gems 2 chapter on how they did it in STALKER. Another popular, purely color based, approach to antialiasing is called Morphological Antialiasing (or just MLAA) – see Realtime Rendering blog for more info. It’s even been added as an on/off feature to Radeon HD 6000-series cards and it’s also widely used on PS3 via its SPU processors. Other interesting color based antialiasing methods include FXAA or SRAA. Now, as mentioned before, with light pre-pass we may just be able to stick with geometry-only-MSAA. Otherwise any of mentioned post-processing AA techniques still apply.

Specular color in light pre-pass
If you’re aiming at just using single light buffer, that means you have 4 attributes 3 of which are used for RGB components of the dot(N, L) * LightColor * LightAttenuation and so, you only have 1 left for specular lighting. Having 1 instead of 3 attributes we choose to just store single specular lighting luminance value (for example, luminance = 0.3 * R + 0.59 * G + 0.11 * B). But that means we loose specular lighting color which, if there’s non-white lights in the scene, may result in highly undesirable looks. Fortunately there’s this cool “trick” that let’s you reconstruct light color from diffuse lighting components. It’s not perfect as it only works correctly for a single light but it’s definitely better than nothing – see Max’s Programming Blog for a nice explanation of it.

Materials / lighting models variety
Both approaches are very limited in terms of material / lighting models variety. In a traditional forward renderer the shader had access to both light and material properties and so it could implement any kind of fancy material. In deferred renderer material properties are accessed first, then what the lighting pass gets is just fixed set of generic attributes (e.g. albedo color, specular color). Now, with light pre-pass, we have a bit different situation. One could say it’s even less flexible because we’re pretty much locked with Phong diffuse / specular shading model. Unfortunately, implementing something more complex like Oren-Nayar isn’t easily doable with light pre-pass as is the case with any other “non-standard” material / lighting models.

The only way I can think of one could support multiple material / lighting models in their deferred renderer (doesn’t apply to light pre-pass) is by storing material id during the first pass in a G-buffer and then branching in a shader code based on its value. It may not be too bad performance wise due to coherency among samples but this means your shader code gets more complex (messy!) too. Neverthless, I think this could be quite a good approach to multiple material / lighting models.

That’s it for now. I feel like the more you investigate the topic the more difficult it is to choose the best approach for specific needs. I plan to discuss such choice dilemmas too in Part 2, stay tuned!