Docstoc

Renderer Design for Multiple Lights Renderer

Document Sample
Renderer Design for Multiple Lights Renderer Powered By Docstoc
					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.

•

• •

•

•

•

Render opaque objects
Z pre-pass

Z Pre-Pass Renderer
Switch off depth write

Transparent objects

Depth Buffer

Forward Rendering

Sort Front-To-Back

•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

Forward Rendering

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]

Forward Rendering

Sort Back-To-Front

•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

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 Normals Depth Buffer Transparent objects

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 KBuffer, 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.guerrillagames.com/publications/dr_kz2_rsx_dev07.pdf

•


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:70
posted:11/16/2009
language:English
pages:15