Deferred Shading

The central trick of deferred shading is so simple it barely sounds like an innovation: don't calculate lighting when you draw geometry. Instead, draw all your opaque meshes first, storing their surface properties — normal, base color, roughness, metallic — into a set of textures called the G-Buffer. Then, in a second pass, light the scene by reading those textures and doing the shading math per-pixel, per-light.

Why bother? Because in forward rendering, every mesh gets lit by every relevant light during its draw call. If you have 100 lights and 1000 objects, you're potentially doing lighting 100,000 times, most of which gets overdrawn by closer geometry anyway. Deferred shading decouples geometry complexity from lighting complexity. You shade each pixel exactly once for geometry, and once per light. Overdraw during the geometry pass is essentially free — the pixel shader writes a few textures and moves on.¹

The G-Buffer

The G-Buffer (geometry buffer) is where surface properties live between passes. A typical setup — as seen in both Unreal Engine 4 and GTA V — uses five render targets output simultaneously via MRT (multiple render targets).^{1 2}

GTA V's layout is instructive. Four 8-bit-per-channel RGBA textures store the diffuse map (intrinsic surface color), normal map, specular properties (intensity, glossiness, fresnel), and an irradiance map. A fifth target is a depth-stencil buffer, where depth uses a reversed-Z logarithmic encoding to fight Z-fighting across the game's enormous draw distances, and the stencil identifies object categories (player character, vehicles, NPCs, vegetation).²

Unreal's layout is similar but more flexible. The number of channels and their assignments shift depending on project settings and which shading model each pixel uses. The ShadingModelID is stored per-pixel in the G-Buffer so the lighting pass can dispatch to the correct BRDF for each material — subsurface scattering for skin, clear coat for car paint, standard PBR for everything else. This per-pixel material dispatch is what gives deferred engines their material flexibility without sacrificing performance.¹

The Lighting Pass

Once the G-Buffer is filled, deferred engines iterate over each light and calculate its contribution to every affected pixel. The clever optimization here: lights are rendered as geometry. A point light draws a sphere, a spot light draws a cone. The GPU's rasterizer automatically determines which pixels fall within the light's influence, so the expensive pixel shader — which samples the G-Buffer, calculates shadow terms, and evaluates the BRDF — only runs where it matters. Lights that fill fewer pixels are cheaper. A small candle costs almost nothing compared to the sun.¹

For shadowed lights, Unreal first computes a screen-space shadow mask texture. It renders approximations of scene geometry against the depth buffer to figure out which pixels are in shadow, storing this per-channel: directional light shadows in one channel, per-object shadows in another, subsurface shadows in a third. The lighting pass then multiplies the shading result by this attenuation value.¹

GTA V uses cascaded shadow maps with four cascades packed into a 1024x4096 texture, with the cascades getting progressively larger to cover more distant geometry. The shadow maps are sampled with a dithering pattern to soften edges, then depth-aware blurred. An "early out" optimization creates a downscaled version first — if the current pixel appears fully lit, the expensive blur is skipped entirely.²

What Deferred Can't Do

Transparency is the classic problem. A G-Buffer stores one set of surface properties per pixel. If you have a glass window in front of a wall, you need both surfaces' properties to composite correctly, but the G-Buffer only has room for one. This is why every deferred engine falls back to forward rendering for transparent objects — they're rendered after the deferred pipeline resolves, reading the deferred depth buffer for occlusion but doing their own lighting math.

Techniques like order-independent transparency (weighted, blended OIT) can help by accumulating transparent surfaces without requiring them to be sorted, but they introduce their own approximations — reduced distinction between layers close in depth, and the need to tune depth weighting functions for your scene's specific depth range.³

MSAA is also awkward. In forward rendering, multi-sample anti-aliasing evaluates the pixel shader once and distributes the result to covered samples. In deferred shading, those samples would need to be stored in the G-Buffer, multiplying its already considerable memory footprint. Most deferred engines use screen-space anti-aliasing (FXAA, TAA) instead, which operates on the final image rather than on geometry edges.

Forward Gets a Second Wind

The weaknesses of deferred shading have motivated a resurgence of forward rendering — or more precisely, clustered forward rendering. Google's Filament engine uses frustum voxelization (froxels) to divide the view volume into small 3D cells, each with a list of affecting lights. A forward pass then evaluates only the lights relevant to each cell, getting the decoupling benefit of deferred without the G-Buffer overhead. This approach supports MSAA natively and handles transparency without fallbacks.⁴

The industry hasn't converged on one approach. The best choice depends on your lighting complexity, material diversity, and target hardware. Mobile GPUs with tile-based architectures actually prefer forward rendering because it avoids the bandwidth cost of reading back large G-Buffers. Desktop games with many dynamic lights still lean deferred. And the newest engines are increasingly GPU-driven pipelines where the distinction between forward and deferred matters less than how aggressively you can cull and batch.²