Presentation on theme: "Building a Dynamic Lighting Engine for Velvet Assassin Christian Schüler."— Presentation transcript:
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. 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 Tree S. 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-pass and 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)
Bounce Light axis N L (NL) · f(axisL) 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.... and even back in 2003 (it‘s not rocket science)
So, for each frame … 1. Get all primary lights in view 2. Distribute shadow map pool 3. 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 spatial index data structure.
Fog Zones A.k.a.: There has to be at least one benefit for manual portalization! Here it is: Fog Zones!
Fog Zones contd. portal separates 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 = C 0 ∙ T + S C 0 original color Tfog transmittance Sfog in-scatter = (1−T) ∙ C Fog traditionally
Fog Zones contd. C = ( C 0 ∙ T B + S B ) ∙ T A + S A AB portal C = C 0 ∙ ( T B ∙ T A ) + ( S B ∙ T A + S A )
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.
Again, multiply-add solves the math (in the form of pre-multiplied alpha) Off-screen target: C Target ’ = (1−A Particle ) · C Target + C Particle A Target ’ = (1−A Particle ) · A Target + A Particle Compositing: C Frame ’ = (1−A Target ) · C Frame + C Target
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