Building a Dynamic Lighting Engine for Velvet Assassin

Post on 25-Feb-2016

25 views 0 download

Tags:

description

Christian Schüler. Building a Dynamic Lighting Engine for Velvet Assassin. Velvet Assassin. 3rd person stealth game Formerly known as “ Sabotage 1943” First concepts: late 2000 Release: April 2009 Platforms PC, X360 My role: tech. dir. plus lead engine programmer. Engine Goals. - PowerPoint PPT Presentation

Transcript of Building a Dynamic Lighting Engine for Velvet Assassin

Building a Dynamic Lighting Engine for

Velvet Assassin

Christian Schüler

Velvet Assassin 3rd person stealth game Formerly known as “Sabotage

1943” First concepts: late 2000 Release: April 2009 Platforms PC, X360

My role: tech. dir. plus lead engine programmer

Engine Goals Must look great!

(of course)

Everything is dynamically lit Cannot use Lightmaps

Lighting is part of gameplay If it looks dark, the player should be

hidden! Light sources become game entites.

Engine Goals?

So, what about ... … scene visibility … light influence … indirect lighting (like radiosity)

… if every object can possibly move,even light sources?

First Engine (2003)

Axioms (2003) World is a loose octree of objects Objects are OBB trees of triangles Multi-pass lighting with stencil

shadows Occlusion culling for visibility Indirect illumination via bounce

lights

Shipping Engine (2009)

Axioms (2009) World is a loose octree of objects Objects are OBB trees of triangles Hybrid single/multi-pass lighting

with shadow maps Portals for visibility Indirect illumination via bounce

lights

+ XBox 360 specific optimizations

Loose Octrees

Thatcher Ulrich (2001): Cells are overlapping (loose) Insertion is efficient

No need to rebuild the whole octree if an element moves!

Perfect as spatial index of a dynamic scene!

Loose Octrees contd.

Base cell

Extended volume

Loose Octrees contd.

Object inserted if inside extended volume

O(1) insertion

Loose Octrees contd.

Used in finding out

Objects in a view frustum Objects influenced by a light Lights influencing an object Broad phase for ray tests Gameplay objects in range

And everything can be dynamic!

OBB Trees

Oriented Bounding Box TreeS. Gottschalk et al (1995)

Used on the polygon level Build as a pre-process over mesh

data Allows efficient ray-mesh and

mesh-mesh interference tests

OBB Trees contd.Axis aligned …

… vs oriented!

OBB Trees contd.Construction:

• Principal axes (gaussian point distribution)*

• Minimize Box volume(possibly iterative)

*eigenvectors of covariance matrix

Hybrid Lighting

A hybrid between multi-passand single-pass forward renderer:

One pass for each primary light

One pass for all secondary lights combined

Hybrid Lighting contd.

Primary lights

Classic multi-pass (Doom 3 style) One pass per primary light Can cast shadows The light queries for surrounding

geometry

Hybrid Lighting contd.

Secondary lights

Classic single-pass (HL2 style) Lights collected into one pass

(shader variation based on count) Can not cast shadows The geometry queries for

surrounding lights (up to a maximum amount)

Hybrid Lighting contd.

primary spotsecondarypoints

Hybrid Lighting contd.

primary directional

secondarypoints

Bounce Light

axis

N

L

(N•L) · f(axis•L)

Gives appearance of first bounce indirect light from a surface.

Must not illuminate the surface it is placed on.

Has a half-sphere influence radius determined by axis.

Bounce Light contd.

primary spot

secondarybounce

Bounce Light contd.

primaryspot

2 secondaryambients

Bounce Light contd.

... and even back in 2003

(it‘s not rocket science)

So, for each frame …1. Get all primary lights in view2. Distribute shadow map pool3. Render shadow maps, for each:

Render all objects contained in light frustum Get all objects in view Render base pass

For each object, collect nearest N secondary lights (sorted by importance) for the shader

Render additive passes for each … … primary light: for each object that is in the

view and also in the light frustum.

That is why you need an efficient spatialindex data structure.

Fog Zones

A.k.a.: There has to be at leastone benefit for manualportalization!

Here it is: Fog Zones!

Fog Zones contd.

portalseparates fog environments

Fog Zones contd.

… from the other side

Fog Zones contd.

Multiply-Add is your friend!(instead of lerping against a constant fog color)

C = C0 ∙ T + S

C0 original colorT fog transmittanceS fog in-scatter

= (1−T) ∙ CFog traditionally

Fog Zones contd.

C = ( C0 ∙ TB + SB ) ∙ TA + SA

A B

portal

C = C0 ∙ ( TB ∙ TA ) + ( SB ∙ TA + SA )

Fog Zones contd. Modify T and S of the new

environment with T and S from the portal polygon

Calculate fog from the distance of the portal

Repeat recusively

Fill Optimization Only done for XBox 360

Selected particle effects rendered into off-screen render target at half resolution to save fill rate (against half resolution depth buffer)

Composited over the final image

Fill Optimization contd.

Fill Optimization contd.Again, multiply-add solves the math

(in the form of pre-multiplied alpha)

Off-screen target:CTarget’ = (1−AParticle) · CTarget + CParticle

ATarget’ = (1−AParticle) · ATarget + AParticle

Compositing:CFrame’ = (1−ATarget) · CFrame + CTarget

Multi-threading XBox 360 needed it; a dual-core PC

at least benefits First thread performs all spatial

queries and compiles a “drawlist” Second thread sets shader

registers, render states and submits batches

Most scenes from 300 to 1200 batches/frame

The End

Questions?