Dissecting the Rendering of The Surge

Dissecting the Rendering of
Philip Hammer
DECK13 Interactive GmbH
Quo Vadis, Berlin, 24.4.2018

Dissecting the Rendering of The Surge
Quo Vadis Berlin 2018
Introduction
● DECK13 Interactive released “The Surge” in 2017
○ New IP, new publisher
○ Overhauled tech (Fledge Engine / 3th Generation)
○ Award Winning: Best German Game, Best Graphics, Best PC-/Console-Game (Deutscher Entwicklerpreis 2017)
○ Our most ambitious game from DECK13

Introduction
● Team of around 70 people in Frankfurt
○ Tech Department: ~11 people (engine + game code)
○ Art- & Sound-Outsourcing
● Myself
○ Since 2006 @ DECK13
○ Working on rendering / engine / graphics / shaders
○ Worked on The Surge, Lords of the Fallen, Venetica, Ankh, Jack Keane, etc.
● The results and techniques presented in this article is
the work of many people in the Deck13 Tech department.

● Fledge Gen 1 (2009: Blood Knights, Tiger & Chicken)
○ PS3, Xbox 360, PC / D3D9, iOS (iPad 2 and up)
○ Deferred Rendering, Direct Lighting only, Minimal Multithreading
● Fledge Gen 2 (2012: Lords of the Fallen)
○ PS4, Xbox One, PC / D3D11
○ Volumetric Lighting, Direct & Indirect Lighting, Task-based multithreaded rendering
● Fledge Gen 3 (2014: The Surge)
○ PS4 (+Pro), Xbox One (+X), PC / D3D11
○ Physically-based rendering, Clustered Deferred Rendering, GPU Particles
● Fledge Gen 4 (2017/2018: The Surge 2)
○ Vulkan, D3D12
○ Currently in the making .. stay tuned
Tech Evolution

● Fledge Gen 1 (2009: Blood Knights, Tiger & Chicken)
○ PS3, Xbox 360, PC / D3D9, iOS (iPad 2 and up)
○ Deferred Rendering, Direct Lighting only, Minimal Multithreading
● Fledge Gen 2 (2012: Lords of the Fallen)
○ PS4, Xbox One, PC / D3D11
○ Volumetric Lighting, Direct & Indirect Lighting, Task-based multithreaded rendering
● Fledge Gen 3 (2014: The Surge)
○ PS4 (+Pro), Xbox One (+X), PC / D3D11
○ Physically-based rendering, Clustered Deferred Rendering, GPU Particles
● Fledge Gen 4 (2017/2018: The Surge 2)
○ Vulkan, D3D12
○ Currently in the making .. stay tuned
Tech Evolution
Today’s topics

Tech Evolution
● The Surge Tech (Gen 3)
○ Stable Framerate across all platforms
PS4: 1080p @ 30 FPS
PS4 Pro: 1620p @ 30 FPS or 1080p @ 60 FPS
Xbox One: 900p @ 30 FPS
Xbox One X: 1800p @ 30 FPS or 1080p @ 60 FPS
○ Physical-Based Rendering
○ Clustered Deferred Rendering
○ Volumetric Lighting
○ GPU Particles
○ Screen-space Reflections
○ etc.
● New things in the making (Gen 4) - short peak into the future towards the end

Physical-based Rendering
● Switched from (non-PBR) Blinn-Phong to
GGX Cook-Torrance BRDF [1]
○ De-facto industry standard.
○ More material data to drive the BRDF
● Artists needed to adapt (Workflow, Tools, Mindset)
○ Lots of pitfalls (no arbitrary texture data)
○ Adoption process was rather unproblematic -
most tools (Substance, Marmoset) already provide PBR workflow
● We use “Metalness-Workflow”
○ Artist provide Albedo, Normal, Roughness and Metalness textures
○ Metalness is a mask to treat the albedo differently in specular lighting

● Direct Lighting: 100% dynamic lights
○ 16 shadowmaps rendered into atlas (4kx4k - 8kx8k, D16_FLOAT)
○ If cap reached, the shadowmap isn’t updated anymore and
virtually becomes static
● Image-based lighting
○ Precomputed, parallax corrected environment probes (Artist placed)
○ Specular probe is 256x256 cubemap (BC6_UFLOAT)
with GGX filtered importance sampled mip chain [2]
○ Diffuse lighting is simply the 6th mip level of probe
(“incorrect”, but visually equivalent with proper irradiance)
○ IBL pass can be modified with simple, multiplicative “ambient lights” [3]

● G-Buffer breakdown

X Y Z W
RT0 (8:8:8:8) Albedo RGB Material-ID
RT1 (10:10:10:2) VS Normal XYZ -
RT2 (8:8:8:8) Roughness Metalness Occlusion [shared]
RT3 (16:16) Motion Vectors XY - -

● Material-ID indexes directly into StructuredBuffer to query per-material data
○ Save G-Buffer space
● [shared] - per-pixel context dependent
○ mutual exclusive material data
○ based on per-material data
○ Emissive Mask
■ Defines whether or not to interpret albedo as emissive
■ Emissive combined in final “combine” pass
■ Effectively saves dedicated emissive channel
○ Translucency

Clustered Deferred Rendering
● Switch from rasterization-based light volume rendering to full (async) compute-based approach
○ Low CPU overhead
■ Light culling runs entirely on GPU
■ Filling a buffer with light infos instead of dispatching thousands of drawcalls
○ Advantages on GPU
■ No need to fetch G-Buffer for every light
○ Async Compute: Lighting runs in parallel to shadow rendering (at least on consoles)
○ But: many more optimizations necessary to get better perf
● Could render environment probes in the same pass
○ Environment probes are still clustered but rendered in a separate (pixelshader) pass together with SSR

Clustered Deferred Rendering
● Divide view frustum into a 3D grid
○ In our case: 16 x 8 x 24
● Culling: Assign lights to grid cells
○ Upload light culling info to GPU (StructuredBuffer with Position, AABB, etc.)
○ Create list of light indices for each cell (single large uint buffer)
● Dispatch lighting compute shader
○ In fact we dispatch twice: unshadowed and shadowed lights
○ Unshadowed can run in parallel with shadowmap generation
● Can use cluster information also for forward rendering
○ We do this for our lit transparent objects
○ Simply compute grid cell index for a position and query light list

Deferred Decals
● Decals play a major role in our environment art
○ Static: Logos/Signs, Material Layers (Sand, Water Puddles, Rust, etc.), Color Variations
○ Dynamic: Blood, Explosion Marks, etc.
● Extremely flexible
● Break uniform look of heavily instanced scenes
● Adds lot of large- and small-scale details

Deferred Decals

Deferred Decals
● Modifies G-Buffer by alpha-blending onto it
○ Therefore, lighting is “free” since it’s done afterwards
● 2 methods for tangentspace reconstruction
○ Surface Normal (use G-Buffer normal)
○ Planar (use decal projection direction)
● Full PBR support + many per-decal features (add. Mask, UV modifiers, etc.)
● Implementation rasterization-based deferred
○ Rasterize geometry (boxes) for each decal
○ CPU bottleneck with large number of decals

Deferred Decals
● Common issue with Deferred Decals: Wrong Mip Selection due to screenspace gradients
○ Problem: Texture leaks around depth discontinuities

Deferred Decals
● Common issue with Deferred Decals: Wrong Mip Selection due to screenspace gradients
○ Problem: Texture leaks around depth discontinuities
○ Common solution: Use highest mip
■ Causes flickering in distance due to oversampling (no mips)
■ Texture cache hit
○ Our solution: Use mip0 only with large depth discontinuities
// Sample 2 quads
const float4 d0 = depthSampler.Gather(sampler_point_clamp, screenUV, int2(-1, -1));
const float4 d1 = depthSampler.Gather(sampler_point_clamp, screenUV, int2(0, 0));
const float4 dCross = float4 (d0.z, d0.y, d1.y, d1.z);
const float dC = d.w;
// Find suitable neighbor screen positions in x and y so we can compute proper gradients
// Select based on the smallest different in depth
const bool useFirstMip = any(abs(dC.xxxx - dCross) > 0.001);
if (useFirstMip)
albedoTex.SampleLevel(..);
else
albedoTex.Sample(..);
d0.x d0.y
d0.z d0.w
d1.x d1.y
d1.z d1.w

“Object Decals”
● Alternative Term: “Blend Meshes”
● Alpha-Blend arbitrary meshes on the G-Buffer
○ Artists can create simple plane-”decals” with custom UV setup
○ Efficiently add small, high-res details like panels, rivets, LED, etc.
○ Works also on skinned objects (e.g. logos on Exo-Gear)
1 Base G-Buffer Pass (solid)
2 Object Decal Pass (alpha-blend)
3 Deferred Decal Pass (alpha-blend)

Next Decals / Fledge Gen 4
● “Bindless” Decals
○ Analogous to clustered deferred lighting
■ Culling & rendering happens entirely on the GPU
■ Collect info about all visible decals in a buffer
■ Render all decals before lighting in the same compute shader
○ Decal info stores texture IDs (UINT32) to index directly into DescriptorSet / DescriptorTable
○ Blending not restricted to alpha-blending anymore (linear interpolation)
■ “Geometric” normal blending possible [4]
■ Replacing layered materials with decals is now feasible
○ Availability of interpolated vertex-normals in G-Buffer improves T-Space reconstruction
○ Currently in active development

Optimizing for Occupancy / GCN
● GCN Hardware wants saturated CU Units
○ Huge lighting shader uses a lot of general purpose registers
if not structured carefully
● Reducing register usage (VGPR/SGPR) can be a huge win
○ Especially for long, ALU heavy shaders such as lighting
○ Minimize register lifetime
○ Look at the data and iterate
■ runtime profilers
■ static shader code analysis statistics
● Goal: Want min. 40% GCN Wave Occupancy on
PS4 and Xbox One (for lighting compute shader)

Optimizing for Occupancy / GCN
● Example: Split light type loops
○ Different light types uses different data
■ Shadowed lights use shadow projection matrices, shadowmaps, etc.
■ Image projectors use image projection matrices, images, etc.
■ Boxlights must check bounds differently
■ etc.
○ Shader can free up register usage if structured well
for each light in lightbuffer
if light.type == POINT
// do pointlight calculations
if light.type == SPOT
// do spotlight calculations
else if light.type == SPOT_SHADOWED
// do shadowed spotlight calculated
end
for each light in lightbuffer_point
// do pointlight calculations
end
for each light in lightbuffer_spot
// do spotlight calculations
end
for each light in lightbuffer_spot_shadowed
// do shadowed spotlight calculations
end

What’s next ?
● Currently working on Fledge Gen 4
○ Always improving tech iteratively
○ Always keep existing systems “alive”
○ Parallel Development of new systems / breaking changes
● Spread knowledge
○ Weekly presentation meeting (tech internal)
● Leap to new APIs
○ Vulkan, DirectX 12

What’s next ?
● New low-level renderer design
○ Better match the new APIs (no more state-driven)
○ More low-level control such as explicit resource syncs, GPU memory management, etc.
○ Async-Compute also on PC
○ More C-style, more data-oriented
○ “Do as little as possible during render-loop” aka “prebake as much as we can”
■ Setting DescriptorSets, Map/Unmap GPU memory, etc.
○ Goal: Rendering must not be a CPU performance bottleneck
● Better ingame-profiling for content creators
● Better tools for artists and game designers

What’s next ?
● Improving specific rendering subsystems
○ Switch to physically based inverse square falloff (lumen units)
○ Improved IBL system (e.g. split irradiance and specular probes)
○ Unified volumetric fog / lighting (“lit fog” vs. “volumetric lighting”)
○ Bindless Decals
○ New material system
■ More flexibility for custom shaders / FX Materials
■ Better fit for the new rendering backend interface
○ Improved postprocessing, Antialiasing, HDR tonemapping / color correction

Thank you for
your attention!
DECK13 is hiring!
● Tools Programmer
● Concept Environment Artist
● VFX Artist
● etc.
@philiphammer0
phammer@deck13.com
linkedin.com/in/philip-hammer-430baa6

References
[1] Walter et al., "Microfacet Models for Refraction through Rough Surfaces"
[2] Karis, “Real Shading in Unreal Engine 4”, Siggraph 2013
[3] Schulz, Mader, “Rendering Techniques in Ryse: Son of Rome”, Siggraph 2014
[4] Barré-Brisebois, Hill, "Blending in Detail"
http://blog.selfshadow.com/publications/blending-in-detail/

Dissecting the Rendering of The Surge

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Dissecting the Rendering of The Surge

Similar to Dissecting the Rendering of The Surge (20)

Recently uploaded

Recently uploaded (20)

Dissecting the Rendering of The Surge