Lighting as a budget

The decision nobody makes twice

Every light in a scene costs something. The question is whether it pays that cost once, at bake time, or once per frame, at runtime — and that decision, made early, is almost impossible to revisit cleanly.

Baked lighting pre-computes the interaction between light and geometry and stores the result in lightmaps: texture atlases that carry shadow, bounce and occlusion already solved. At runtime, the GPU reads a texture rather than simulating physics, which is extremely cheap. The downside is rigidity. Move a piece of geometry, change a material, open a door that was closed during the bake, and the illusion breaks. Baked lighting assumes the world is static, because it was only ever correct for the world as it existed when the bake ran.

Dynamic lighting solves nothing in advance. Every light re-evaluates every frame: shadow maps are re-rendered, irradiance is recalculated, the cost is paid on the clock. The world can change freely — a light can move, a character can carry a torch, a day-night cycle can run — but the per-frame bill is real and it accumulates. Each dynamic shadow-casting light typically requires additional render passes, which is one reason draw calls and what they cost matter so much when the lighting count climbs.

Hybrid systems and where the compromises land

Most shipped games operate somewhere between the poles. A common pattern: bake the static environment's indirect light (bounce and ambient occlusion), run a small number of dynamic direct lights for key characters and effects, and use light probes to project some of that baked environment data back onto moving objects so they do not read as floating in a different scene. The hybrid approach is a genuine optimisation, but it also multiplies the surface area for failure. A moving character can step between probe regions and visibly pop. A baked shadow can persist through a dynamic object. The seams between the static and dynamic layers are where the bugs live.

Real-time global illumination systems — Lumen in Unreal Engine 5, for instance — attempt to narrow the gap by computing indirect light dynamically at manageable cost. They do this through a combination of screen-space techniques, distance fields and hardware ray-tracing on supported hardware. The budget is lower than full ray tracing, higher than baked GI, and the minimum spec floor that can run it acceptably has to be set and held. These systems do not make lighting free; they trade the bake step for a continuous runtime cost and change which hardware can carry the game.

Baked lighting assumes the world is static, because it was only ever correct for the world as it existed when the bake ran.

Where the real cost hides

Baked lighting's runtime cost is low, but its production cost is significant. A full bake on a large level can take hours on a lighting farm, and changing a wall, a ceiling height or a material after the bake means running it again. The iteration tax is paid by artists and level designers, not by the GPU. The practical effect is that teams stop experimenting with geometry once baking is in the loop, because the feedback cycle becomes too slow. That feedback loop — how long it takes to see a change — shapes the work in ways that compound over months.

Shadow distance and shadow quality are among the first settings cut during an optimisation pass. The per-frame cost of dynamic shadows scales with the number of shadow-casting lights multiplied by the complexity of what they illuminate; aggressive culling of shadow-casting geometry and tight control over light radii are standard practice. A light whose radius is clipped to the minimum needed costs a fraction of one set wide. Most artists set them wide.

The lighting budget is set at the start of production, implicitly, by the choice of rendering path — forward or deferred — and explicitly, by the count of dynamic lights, the resolution of lightmaps and the frequency of bakes that the pipeline can actually sustain. Revisiting those limits late in production, when levels are full of content built around whatever the artists assumed was allowed, is one of the more reliable ways to lose a month. The decision is not primarily aesthetic. It is a frame budget problem that happens to have visual consequences.

Every figure in this entry is one worked example on one platform, shown because a partition makes the trade-off legible. It is not a measurement of any particular production.