Renderer Design for Multiple Lights by Wolfgang Engel 05/27/08

Agenda What is a Renderer? What does the Renderer do? Z Pre-Pass Renderer Deferred Renderer Light Pre-Pass Renderer Conclusion

What is a Renderer It is the fundament of your game engine The software layer that feeds the graphics card with data

What does the Renderer do? First render phase - Shadow pass: Cascaded Shadows for day light, night-time shadows, cloud shadows, character shadows - Z pre-pass / G-Buffer update / Light Pre-pass Second render phase - Screen-space ambient occlusion / local irradiance Third render phase - In case of a Light Pre-Pass renderer: fill up the light buffer with all light properties - Global Illumination: collects light data - Reflections / refractions / environment reflections Fourth render phase (Opaque objects) - Lighting and rendering the opaque objects with shadow data sorted by shaders and / or front-to-back (also water + refraction map) Fifth render phase - Dynamic sky-dome Sixth render phase (Transparent objects) - Lighting and rendering the transparent objects with shadow data sorted back-to-front + alpha-to-coverage objects - Foliage rendering Seventh render phase (Particles) - Render high-res particles into back-buffer - Render low-res particles into smaller render target - Composite smaller particle render target with main render target Eight render phase - MSAA resolve to a potentially lower-res render target (for certain target platforms) - PostFX (HDR, Depth of Field, Depth Fog, Height-Based fog, motion blur, heat haze, tear gas, drunk-effect Ninth render phase -- Up-scaling of lower res render target (for certain target platforms) -- UI etc.

Z Pre-Pass Renderer Render opaque objects Transparent objects Depth Buffer Z pre-pass Switch off depth write Forward Rendering Sort Front-To-Back Forward Rendering First mentioned by John Carmack [Carmack] Shows phase four and six from the overview above Separate render path for opaque and transparent objects Z Pre-Pass Layout depth data and hardware culling data Utilizes fast double-speed depth writes Forward rendering is the common way to render objects Sort Back-To-Front

Z Pre-Pass Renderer II Multi-Light solutions One render pass per light <-> lots of draw calls Render 4 – 8 lights per drawcall Pixel shader can render e.g. up to eight lights Requires to split up geometry following the amount of lights <-> hardware likes low number of draw calls 2 ½ D light solution with light properties in textures Store light properties in 2D textures Use index texture to index into those light property textures <-> hardware does not like dependent texture reads

Deferred Renderer Normals Specular / Motion Vec Albedo / Shadow Depth Buffer Deferred Lighting Switch off depth write First mentioned in [Deering] Shows phase four and six from the overview above Separate render path for opaque and transparent objects G-Buffer == Multiple-Render Target (Killzone 2) [Valient] Holds material properties: mainly specular and albedo Lighting phase: reads DS, RT1 – RT3 and renders the image per light into RT0 -> renders as often as there are lights Forward Rendering Sort Back-To-Front

Deferred Renderer II Reading the G-Buffer for each light -> lots of memory bandwidth -> solutions: Scissoring out the 3D bounding box volume of the light projected into a 2D rectangle [Placeres] Render for each light convex geometry Point light == sphere; spotlight == cone If camera is inside light volume only render back facing pixels when depth test fails (D3DCMP_GREATER instead of D3DCMP_LESSEQUAL ) [Thibieroz04] Like stencil shadow volumes Like above but increment stencil test When drawing front-facing light volumes set the depth test to D3DCMP_LESSEQUAL and decrement the stencil test when the depth test fails Only light pixels are rendered where the stencil value is greater than or equal to 1 [Hargreaves][Valient]. G-Buffer holds all material properties -> the restricted number of storage space restricts the game to a low variety of materials Hardware MSAA is not available on DX9 PC graphics hardware and quite expensive on XBOX 360 / PS3

Light Pre-Pass Renderer Render opaque objects Transparent objects Normals Depth Buffer Switch off depth write Light Buffer Forward Rendering Sort Front-To-Back Stores normals in a normal buffer and the depth values in a depth buffer Stores light properties in a light buffer -> use same memory bandwidth optimizations as Deferred Renderer Renderes forward while re-constructing the lighting equation Forward Rendering Sort Back-To-Front

Light Pre-Pass Renderer II What are the light properties? Color = Ambient + Shadow * Att * (N.L * DiffColor * DiffIntensity * LightColor + R.V^n * SpecColor * SpecIntensity * LightColor) Properties that depend on the light vector N.L LightColor R.V^n Attenuation Simple Light Pre-Pass LightColor.r * N.L * Att LightColor.g * N.L * Att LightColor.b * N.L * Att R.V^n * N.L * Att Spotlight: Att represents spotlight factor

Light Pre-Pass Renderer III Simple Pre-Pass Renderer does not allow to re-construct the specular term of the lighting equation -> therefore a separate diffuse term need to be stored like this LightColor.r * N.L * Att LightColor.g * N.L * Att LightColor.b * N.L * Att R.V^n * N.L * Att N.L * Att Now we can do (R.V^n * N.L * Att) / (N.L * Att) Each pixel of the light buffer represents the specular term of all light sources Adding a material specular power value can be done like this (R.V^n)^mn Adding a material specular color is done like this (R.V^n)^nm * Spec Thinking of this specular term as an intensity term, we can construct all kind of specular terms and multiply it with it. Fresnel is just N.V in the forward rendering path

Light Pre-Pass Renderer IV Compared to the Z Pre-Pass Renderer Design Less material variety than a Z Pre-Pass renderer Probably consumes more memory bandwidth Needs higher spec graphics hardware It is easier to implement more lights Compared to the Deferred Renderer Design Light Pre-Pass offers more material variety Hardware MSAA is easy to implement Memory bandwidth lower -> reading normal and depth buffer for each light is less than reading the G-Buffer in the Deferred Renderer Cost per light is lower than with a Deferred Renderer -> more lights Easy to implement on low spec graphics hardware with pixel shader model 1.4 and higher

Conclusion If a game requires lots of dynamic lights, a Light Pre-Pass renderer is a good choice to achieve this goal If minimum hardware capabilities are quite low (no programmable pixel shader), the Z Pre-Pass Renderer is better

Thanks wengel@rockstarsandiego.com

References [Bavoil] Louis Bavoil, Kevin Myers, Deferred Rendering using a Stencil Routed K-Buffer, ShaderX6 [Calver] Dean Calver's article in deferred rendering on beyond3d http://www.beyond3d.com/content/articles/19/ [Carmack] John Carmack ?? [Deering] Michael Deering "The triangle processor and normal vector shader: a VLSI system for high performance graphics" SIGGRAPH 1988 [Hargreaves] Shawn Hargreaves, “Deferred Shading”, http://www.talula.demon.co.uk/DeferredShading.pdf [Placeres] Frank Puig Placeres, “Overcoming Deferred Shading Drawbacks”, pp. 115 – 130, ShaderX5 [Thibieroz04] Nick, Thibieroz, “Deferred Shading with Multiple-Render Targets”, pp. 251- 269, ShaderX2 – Shader Programming Tips & Tricks with DirectX9 [Thibieroz07] Nick, Thibieroz, “Robust Order-Independent Transparency via Reverse Depth Peeling in DirectX® 10”, ShaderX6 [Valient] Michal Valient, “Deferred Rendering in Killzone 2”, http://www.guerrilla-games.com/publications/dr_kz2_rsx_dev07.pdf