Renderer design for multiple lights
1 / 15

Renderer Design for Multiple Lights - PowerPoint PPT Presentation

  • Updated On :

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

Related searches for Renderer Design for Multiple Lights

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Renderer Design for Multiple Lights' - zurina

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Renderer design for multiple lights l.jpg

Renderer Designfor Multiple Lights

by Wolfgang Engel05/27/08

Agenda l.jpg

  • What is a Renderer?

  • What does the Renderer do?

  • Z Pre-Pass Renderer

  • Deferred Renderer

  • Light Pre-Pass Renderer

  • Conclusion

What is a renderer l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Deferred Renderer


Specular /Motion Vec

Albedo /Shadow

Depth Buffer


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 l.jpg
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 l.jpg
Light Pre-Pass Renderer

Render opaque objects

Transparent objects


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 l.jpg
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 * AttLightColor.g * N.L * AttLightColor.b * N.L * AttR.V^n * N.L * Att

  • Spotlight: Att represents spotlight factor

Light pre pass renderer iii l.jpg
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 * AttLightColor.g * N.L * AttLightColor.b * N.L * AttR.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 l.jpg
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 l.jpg

  • 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 l.jpg

[email protected]

References l.jpg

  • [Bavoil] Louis Bavoil, Kevin Myers, Deferred Rendering using a Stencil Routed K-Buffer, ShaderX6

  • [Calver] Dean Calver's article in deferred rendering on beyond3d

  • [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”,

  • [Placeres] Frank PuigPlaceres, “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”,