1 / 37

Building a Dynamic Lighting Engine for Velvet Assassin

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.

hao
Télécharger la présentation

Building a Dynamic Lighting Engine for Velvet Assassin

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Christian Schüler Building a Dynamic Lighting Engine for Velvet Assassin

  2. 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

  3. 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.

  4. Engine Goals? So, what about ... • … scene visibility • … light influence • … indirect lighting (like radiosity) … if every object can possibly move, even light sources?

  5. First Engine (2003)

  6. 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

  7. Shipping Engine (2009)

  8. 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

  9. 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!

  10. Loose Octrees contd. Extended volume Base cell

  11. Loose Octrees contd. Object inserted if inside extended volume  O(1) insertion

  12. 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!

  13. 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

  14. OBB Trees contd. Axis aligned … … vs oriented!

  15. OBB Trees contd. • Construction: • Principal axes (gaussian point distribution)* • Minimize Box volume • (possibly iterative) *eigenvectors of covariance matrix

  16. 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

  17. 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

  18. 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)

  19. Hybrid Lighting contd. secondarypoints primary spot

  20. Hybrid Lighting contd. primary directional secondarypoints

  21. Bounce Light 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. N L axis (N•L) ·f(axis•L)

  22. Bounce Light contd. primary spot secondarybounce

  23. Bounce Light contd. 2 secondaryambients primaryspot

  24. Bounce Light contd. ... and even back in 2003 (it‘s not rocket science)

  25. So, for each frame … • Get all primary lights in view • Distribute shadow map pool • 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.

  26. Fog Zones A.k.a.: There has to be at least one benefit for manual portalization! Here it is: Fog Zones!

  27. Fog Zones contd. portal separates fog environments

  28. Fog Zones contd. … from the other side

  29. Fog Zones contd. Multiply-Add is your friend! (instead of lerping against a constant fog color) C = C0 ∙ T + S C0 original color T fog transmittance S fog in-scatter = (1−T) ∙ CFog traditionally

  30. Fog Zones contd. C = ( C0 ∙ TB + SB ) ∙ TA + SA A B portal C = C0 ∙ ( TB ∙ TA)+ ( SB ∙ TA + SA)

  31. 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

  32. 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

  33. Fill Optimization contd.

  34. 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

  35. 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

  36. The End Questions?

More Related