Render Engine Case Studypages.cpsc.ucalgary.ca/~bdstephe/585_W11/killzone.pdf · Deferred Rendering • The way to do this is to separate surface property calculation and lighting

Render Engine

Case Study

Overview

• Why is Killzone 2 interesting?

– Uses a different rendering architecture than what we’ve

discussed

– Takes advantage of PS3 hardware

– Rendering supports Art Style

• Stuff to cover

– Graphics in service of gameplay goals, a bit of history

– Major Rendering Engine Styles

Graphics in service of Gameplay

• Want to choose graphics techniques that supports game

design decisions

– This used to be a much harder problem

– In early days of 3D, technology limited game design decisions

• Quake – Couldn’t render real 3D , levels need to be

2D+heighmap

• Doom3 – Leap to real 3D makes characters too expensive

Quake Doom3

Graphics in service of Gameplay

• As graphics hardware becomes more flexible & higher-

performance:• More techniques to consider

• Fast Z-writes

• Programmable shaders

• Multiple Passes, Multi-Render Target support

• Now we can start to focus a lot more on meeting artistic

goals

– You hear the term “cinematic” applied to a lot of features

– You only have so much GPU time & Memory

Simplified view of the Xbox 360 Hardware architectureFrom Game Engine Architecture – Jason Gregory

Simplified view of the PS3 Cell broadband architectureFrom Game Engine Architecture – Jason Gregory

Lighting

Gamer: Oh, Crap! Look at all those bad guys!

Rendering Programmer: Oh, crap! Look at all those dynamic lights!

Lighting

• Real world has lots of lights in it

– Light maps let you have as many Static lights as you want

– But what we really want is lots of Dynamic lights

• Hard to get lots of dynamic lighting with conventional

techniques

– You tend to end up paying for it even when not benefiting

• But, when there are lots of lights they tend to be small

• If we only render pixels touched by given light, cost is

manageable

Deferred Rendering

• The way to do this is to separate surface property

calculation and lighting

• Components needed in the lighting calculation are

stored in intermediate buffers (per pixel) e.g.

– Diffuse color

– Specular power, intensity

– Normals

– Depth

• Lighting computation is done in Screen-space – once per

pixel

G-buffer generation

• Geometry Pass:

– Render scene geometry, write lighting components to G-Buffers

Lighting Pass

• Light Accumulation Pass:– Initialize light accumulation buffer with “baked” lighting components

– Determine lit pixels

– Render pixels affected by each light, and accumulate

Static Lighting in Killzone2

Forward Rendering – Single vs Multi-Pass

• Forward Rendering – Single Pass:– For each Object:

• Find lights affecting object

• Render lighting & material in a single shader

– Shader combinations explosion:

• Shader for each material vs light combination

– Used in Prototype1

• Forward Rendering – Multi-Pass:– For each Light:

• For each object

– Add lighting from this light to framebuffer

– Shader for each material and light type

– Used in Doom3

Forward Rendering – Trade offs

• Pros

– Handles translucent surfaces

– Can have shading model per object

– Supports Multi-sample Anti-aliasing (MSAA)

• Cons

– Shader Authoring & Maintenance – shader explosion

– Lots of overdraw – expensive lighting computation on surfaces

that are not visible

Deferred Rendering – Trade offs

• Strengths

– Do lighting computation for each pixel exactly once

– Can have more lights in scene

– Simplifies shader management

• Weaknesses

– Must render translucent surfaces using Forward Rendering

– Requires significantly more memory (for intermediate buffers) –

at least 4x

– Cannot use MSAA

– Needs separate pass for Translucent objects

– Cannot have specialized shading for special objects e.g. hair

• Aggressive use of SPUs for rendering-related tasks

• Need to Lock the PPU for a short window

• Game can process next frame AI/Physics

• SPUs handle GPU drawcalls

Particle Systems

• Can easily kill Performance

• Solutions:

– KillZone 2 - Particle update on SPU

– Prototype1 used many approaches to manage particle fill rate:

• Adaptive emission rate

• Artist specified level of detail (shorter lifespan, smaller particles etc)

• Smart heuristics for picking level of detail based on who triggered

the FX (player character vs enemy)

• Fade particle systems in near plane

• Use explosion tokens