How Game Engines Render Lighting

A game running at 60 frames per second has about 16.7 milliseconds to decide how every visible surface should be lit, then hand a finished image to the display. Physically accurate light simulation — tracing how photons actually leave a source and bounce around a scene — can take minutes to hours per frame in film production. Game engines close that seven-order-of-magnitude time gap not by simulating light correctly, but by faking it convincingly, using a layered stack of shortcuts refined since the 1990s. This article walks through what those shortcuts actually are, where they came from, how specific shipped games implemented them, and why two visually similar games can demand wildly different hardware.

Rasterization: the trick that makes real-time lighting possible at all

Rasterization — the process of projecting 3D triangles onto a 2D grid of pixels and figuring out which pixels each triangle covers — is the load-bearing shortcut underneath almost every real-time game. It is backward from how light physically behaves. Real light leaves a source and bounces around a scene until some of it happens to reach an eye or a camera sensor; a renderer that simulated this directly would waste almost all its work on light paths nobody ever sees.

Rasterization inverts the problem. Instead of asking "where does this light go," it asks "what does the camera see," projects the scene's geometry onto the screen from the camera's point of view, and only then runs a lighting calculation — a program called a shader — for the pixels that are actually visible. Because visible pixels are a tiny fraction of all possible light paths in a scene, this reordering is what makes 60 or 120 frames per second achievable on consumer hardware at all. Every major real-time engine — Unreal Engine, Unity, id Tech, Frostbite, Source, CryEngine — has used some form of rasterization as its core visibility pipeline since the 3D-accelerator era of the mid-1990s.

The lighting math that runs on each visible pixel usually splits into two categories with very different costs. Direct light is illumination that travels straight from a light source to a surface with no bounces in between, and it is comparatively cheap to compute. Indirect light, sometimes called global illumination, is light that has bounced off at least one other surface before reaching the one the camera sees — the soft red tint under a red wall, the dim glow inside a doorway lit only by a hallway light around the corner. Indirect light is where almost all of a modern lighting budget goes, and it is the part of the pipeline every subsequent technique in this article exists to approximate.

Physically based shading: how direct light gets calculated per pixel

For direct light, most modern engines use a family of shading models grouped under the name physically based rendering (PBR) — a lighting model that ties a surface's appearance to measurable physical properties (roughness, metalness, base color) rather than to hand-tuned artist parameters. Unreal Engine and Unity both adopted PBR as their default shading model during the mid-2010s, and the industry has largely standardized around variants of the Cook-Torrance microfacet model, originally published by Robert Cook and Kenneth Torrance in their 1982 paper "A Reflectance Model for Computer Graphics" in ACM Transactions on Graphics. The model treats a rough surface as an enormous number of microscopic mirror-like facets, each reflecting light in a slightly different direction, which is why the same equations can produce the dull scatter of unfinished concrete and the tight, bright highlight on brushed steel just by changing a roughness value.

This is a useful place for an analogy. Think of a PBR material like a mixing board rather than a photograph: instead of painting a shiny gold texture from scratch, an artist sets a handful of physically meaningful sliders — metalness, roughness, base color — and the same lighting equation produces correct-looking highlights under any light in the level, from a sunset to a flashlight. Older, non-PBR shading models required artists to fake highlights by hand for specific lighting conditions, which broke immediately if a level designer moved a light.

Direct light also has to account for shadows, which rasterizers handle with shadow maps: a depth image rendered from the light's point of view, so the main render pass can check whether a given pixel is visible from the light or blocked by something closer. Shadow maps are themselves an approximation with a well-known failure mode — resolution limits produce jagged or "shadow acne" artifacts at glancing angles, which is why engines spend real effort on filtering techniques like percentage-closer soft shadows to smooth the result.

Baked lighting and light probes: how engines fake indirect light without recalculating it every frame

Because full indirect-light simulation is too expensive to run every frame, engines have historically precomputed it once, during development, and stored the result for reuse at runtime. Lightmaps are the classic version of this: a texture, separate from the surface's color texture, that stores precomputed indirect lighting for static geometry that will never move — walls, floors, terrain. Because the expensive bounce calculation happens once, offline, during a build step rather than 60 times a second during play, lightmapped scenes can look extremely rich in indirect detail while costing almost nothing at runtime.

The tradeoff is rigidity. A lightmap assumes the light that produced it never moves. This is exactly why moving a light source in an older lightmapped game — or in the Unreal Engine editor with static lighting still baked — can leave shadows and color bleed pointing at where the light used to be, on objects that were never told the light changed. It is not a bug; it is the direct, visible cost of the shortcut.

For objects that do move — characters, vehicles, physics props — a static lightmap does not work, because the object needs different indirect lighting depending on where it currently is. Engines solve this with light probes, sample points scattered through a level that capture what the indirect light looks like at that specific point in space, encoded compactly (often as spherical harmonics, a mathematical way of storing how light varies by direction using a small number of coefficients). A moving character samples the nearest probes and interpolates between them as it walks, getting plausible indirect lighting without needing a full recalculation. Enlighten, a real-time global illumination middleware originally developed by Geomerics and later used inside Unity, was one of the widely shipped systems built around this baked-plus-probe approach for titles through the 2010s.

Baking is why static lighting can look nearly indistinguishable from a fully dynamic system in a still screenshot, while costing a small fraction of the GPU time — the expensive bounce math happened once on a developer's workstation, sometimes over hours, rather than 60 times every second on the player's hardware.

Case study: Half-Life 2 and the invention of radiosity normal mapping

Baked lighting's biggest historical weakness was that a flat lightmap could not fake the way a bumpy, normal-mapped surface should catch light from different directions — a lightmap stored one averaged brightness value per texel, with no sense of which direction the light that made it up actually came from. Valve's engineers solved this for Half-Life 2 with a technique called radiosity normal mapping, presented by Gary McTaggart at the March 2004 Game Developers Conference in the paper "Half-Life 2 / Valve Source Shading." Instead of storing one lightmap per static surface, the Source engine stores three, each representing incoming light along a different basis direction, and combines them with the surface's normal map at runtime to fake directional bounce lighting on bumpy geometry using precomputed data.

The result was a static, offline-baked lighting solution that still reacted convincingly to a moving flashlight or muzzle flash sliding across a brick wall, something older single-lightmap engines could not fake at all. The technique became a template: many engines that shipped through the 2000s and 2010s adopted some variant of directional lightmaps for exactly this reason, because it let baked lighting fake a property — apparent surface bumpiness reacting to light direction — that a single flat lightmap physically cannot represent.

How does Half-Life 2's Source engine make flat lightmaps look bumpy?

Source stores three lightmaps per static surface, each capturing incoming light along a different basis direction, and blends them with the surface's normal map at runtime. This lets a baked, static lighting solution fake the appearance of a bumpy surface catching light directionally, a trick Valve documented at GDC in 2004 that influenced lightmap encoding across the industry for years afterward.

Case study: Doom (2016) and clustered probe-based indirect lighting

id Software's Doom (2016), built on id Tech 6, is a useful example of how a AAA studio balanced baked and real-time lighting at a moment when hardware ray tracing did not yet exist for consumer GPUs. According to graphics researcher Adrian Courrèges' detailed frame-by-frame breakdown of the game's rendering pipeline, id Tech 6 precomputes 128-by-128 pixel cubemaps at dozens of sample points scattered through each level, capturing what the surrounding environment looks like from that location. At runtime, a clustered lookup structure determines which of those cubemaps influence a given on-screen pixel, and a shader blends the nearest ones based on distance to approximate that pixel's reflected environment lighting.

For diffuse indirect light on static geometry, id Tech 6 used a conventional baked lightmap, the same fundamental approach Valve used over a decade earlier. But for dynamic objects — the player's weapon, moving enemies — the engine used a derivative of irradiance volumes, a probe-grid technique conceptually similar to the light-probe approach described earlier in this article, layered with real-time screen-space reflections computed from the depth buffer, surface normals, and the previous frame to catch reflective detail the baked cubemaps missed. The combination let a game built for seventh- and eighth-generation console hardware hit a stable 60 frames per second while still delivering convincing wet-metal and chrome reflections throughout its levels, all without a single traced ray.

Ray tracing: closer to physical accuracy, still an approximation under a time limit

Ray tracing calculates lighting by explicitly simulating rays traveling from the camera (or from light sources) and bouncing off surfaces, which is structurally closer to how light actually propagates than rasterization's screen-projection approach. It has existed in offline film rendering for decades, but real-time hardware acceleration for it is comparatively recent: NVIDIA introduced dedicated RT cores with its GeForce RTX 20-series GPUs in 2018, and AMD followed with Ray Accelerators in its RDNA 2 architecture in 2020.

Even with dedicated hardware, real-time ray tracing is nowhere near the millions of rays per pixel that a film renderer might trace. Games typically cast only one or a handful of rays per pixel, producing a noisy, incomplete image, and then rely on denoising algorithms — filters that use spatial and temporal information from neighboring pixels and previous frames to reconstruct a clean-looking result from a sparse sample.

This is analogous to how an election pollster estimates a result from a sample of a few thousand voters rather than counting every ballot in the country before making a projection. A full count would be exact but far too slow to be useful before the outcome matters; a well-chosen sample, processed correctly, gets a usable answer fast, at the cost of some noise and occasional error. Real-time ray tracing makes the same bet: a small, cheap sample plus a smart reconstruction filter, rather than an expensive-but-complete calculation.

How does Unreal Engine 5's Lumen actually compute global illumination?

Lumen, Epic Games' real-time global illumination and reflection system shipped with Unreal Engine 5 in 2022, does not rely on precomputed lightmaps at all. According to Epic's own technical documentation, Lumen traces against a hybrid scene representation: screen-space traces resolve fine detail, mesh-level signed distance fields (compact volumetric approximations of each static mesh's surface) handle medium-range light transfer, and a coarser global distance field handles large-scale bounce lighting across the whole level. A surface cache stamps each mesh's material data onto a small set of texture atlases so lighting on that cache can be updated incrementally rather than fully recomputed every frame, which is how Lumen affords fully dynamic indirect lighting — moving the sun, swinging a flashlight, knocking down a wall — without a bake step, at a real and variable GPU cost that scales with scene complexity.

Why do baked lightmaps look wrong when a light moves during gameplay?

Lightmaps store indirect lighting calculated once, under the assumption that the lights that produced it stay in their original position. If a light source moves or is toggled during gameplay, static geometry using that lightmap keeps displaying the old, now-incorrect bounce lighting, because nothing recalculated the bake. This is a direct tradeoff for the near-zero runtime cost of precomputed lighting, not an engine bug.

Case study: voxel cone tracing, an alternate route to dynamic global illumination

Lumen is not the only architecture engines have used to get dynamic global illumination without a bake step. CryEngine, Crytek's engine, ships a technique called SVOGI, short for sparse voxel octree global illumination, which converts the scene into a hierarchical grid of voxels — small cube-shaped volume samples, conceptually like 3D pixels — and traces cone-shaped rays through that voxel structure to gather indirect lighting and soft shadows every frame, according to CryEngine's own published documentation. Epic's Unreal Engine 4 also shipped an experimental voxel-cone-traced GI system before Lumen replaced it in Unreal Engine 5.

Voxel cone tracing and Lumen's signed-distance-field approach are solving the identical problem — dynamic, bake-free indirect light — with different scene representations, and both predate the current wave of hardware-ray-traced GI that Metro Exodus Enhanced Edition and similar titles rely on. The existence of multiple competing architectures for the same problem is itself informative: there is no single correct way to approximate dynamic global illumination in real time, only different tradeoffs between voxel resolution, tracing cost, and how gracefully each technique degrades in large, open outdoor scenes versus tight interior ones.

Case study: Metro Exodus Enhanced Edition and fully ray-traced global illumination

Most "ray-traced" games only replace one piece of their lighting pipeline with traced rays — usually reflections or shadows — while leaving baked or screen-space techniques to handle the rest. Metro Exodus Enhanced Edition, released by 4A Games in 2021, went further: according to NVIDIA's own release coverage, the Enhanced Edition rebuilt the game's global illumination system so that every light source, from the sun down to a lit cigarette in a character's pocket, casts real, ray-traced bounce lighting rather than relying on any baked or screen-space substitute, and the update requires an RTX-capable GPU to run at all, with no legacy rasterized lighting path retained.

That total commitment illustrates the hardware tradeoff from the earlier section in its most extreme form. Because the entire indirect-lighting pipeline runs through hardware-accelerated ray tracing every frame instead of falling back to any cheaper baked shortcut, Enhanced Edition dropped support for GPUs without dedicated ray-tracing cores entirely, a design decision very few AAA titles have made even years after RTX hardware became mainstream.

How real-time ray tracing gets from noisy rays to a clean frame: ReSTIR

Casting only a handful of rays per pixel and denoising the result was the first generation of real-time ray tracing's core strategy, but it left a hard limit on how many individual light sources a scene could realistically evaluate per pixel before quality collapsed into unusable noise. A 2020 SIGGRAPH paper by Benedikt Bitterli and coauthors at NVIDIA and Dartmouth, titled "Spatiotemporal reservoir resampling for real-time ray tracing with dynamic direct lighting," introduced an algorithm called ReSTIR (reservoir-based spatiotemporal importance resampling) that changed this math substantially.

Rather than picking a light sample independently at every pixel every frame, ReSTIR reuses good samples found at neighboring pixels and in previous frames, weighting them so that a scene's worth of resampled information effectively accumulates over space and time instead of being recomputed from scratch each frame. The published results reported rendering scenes with up to 3.4 million dynamic, emissive light-casting triangles in under 50 milliseconds per frame while tracing at most eight rays per pixel, and the paper's authors measured equal-error performance six to sixty times faster than prior state-of-the-art direct-lighting methods. ReSTIR and its later extensions have since been adopted across the ray-tracing research and engine ecosystem as a standard building block for scenes with large numbers of dynamic lights, precisely the scenario where older per-pixel sampling approaches broke down fastest.

Technique	When it's calculated	Handles moving objects?	Adapts to moving lights?	Relative runtime cost
Lightmaps	Baked before shipping	No	No	Very low
Radiosity normal maps	Baked before shipping	No	Partially (direction only)	Very low
Light probes	Baked before shipping	Yes (interpolated)	No	Very low
Screen-space GI / SSR	Every frame	Yes	Yes	Low–moderate
Voxel/SDF GI (e.g., Lumen, SVOGI)	Every frame, incrementally updated	Yes	Yes	Moderate–high
Hardware ray-traced GI (ReSTIR-assisted)	Every frame, sampled + denoised	Yes	Yes	High

Cost generally rises with how dynamically the technique can respond to a moving light or a moving object; static baked techniques are cheapest precisely because they give up that flexibility.

Deferred rendering and why light count is not the real cost driver

A persistent misconception is that adding more lights to a scene straightforwardly costs more performance. In a naive forward renderer, which calculates lighting for an object against every light that might affect it during the same pass that draws the object, that used to be roughly true — cost scaled with objects times lights. Modern engines mostly use deferred rendering instead: the geometry pass first writes surface properties (position, normal, material data) into a set of screen-sized buffers called a G-buffer, and lighting is calculated afterward, per pixel, using only the lights that actually overlap that pixel on screen.

Because lighting is decoupled from geometry complexity in a deferred pipeline, engines can handle hundreds of small, localized lights — sconces, torches, muzzle flashes — cheaply, since each one only touches the screen pixels it actually illuminates. A single large dynamic light that casts high-resolution shadows across a big portion of the screen can cost far more than fifty small unshadowed point lights combined. The real cost driver is shadow-casting range and resolution, not raw light count, which is precisely the kind of detail that separates an engineer's mental model of a scene's budget from a casual player's.

What the lighting model an engine chooses does to hardware requirements

The approximation a studio picks is not a stylistic footnote — it directly sets the minimum GPU a game needs. A game built primarily around baked lightmaps and probes, in the tradition of Half-Life 2's radiosity normal mapping or Doom 2016's probe grids, can produce convincing static environments on hardware from a decade earlier than its release, because the expensive part of the calculation happened once, on a developer's workstation, long before the disc or download reached a player. A game built around fully dynamic global illumination, whether voxel/distance-field-based like Lumen or SVOGI, or fully hardware ray-traced like Metro Exodus Enhanced Edition, recalculates significant lighting work every single frame, which is why such titles carry meaningfully higher minimum and recommended GPU specifications, particularly around dedicated ray-tracing or compute hardware. Metro Exodus Enhanced Edition is the clearest possible illustration: it simply does not run without an RTX-class card, because it kept no cheaper fallback path.

This is also why time-of-day systems are a genuine engineering tell. A day-night cycle where the sun visibly moves and shadows lengthen in real time requires dynamic indirect lighting, because a lightmap baked for noon light cannot correctly represent bounce lighting at dusk. Games that advertise a fully dynamic sun with correct indirect lighting throughout the day, like recent Unreal Engine 5 titles built on Lumen, are making a specific, costly technical commitment that a purely lightmapped game with a static or scripted lighting change is not.

Denoising in real-time ray tracing is doing more visible work than most players realize: it is the reason fast camera motion or fast-moving reflective objects can produce faint ghosting or blur in ray-traced scenes, a direct artifact of reconstructing a clean image from only a handful of samples per pixel — even with algorithmic improvements like ReSTIR reducing how many samples are needed to get a clean result.

A brief history: why this whole approach exists

The baked-plus-real-time-shading split did not appear all at once; it grew out of hardware constraints in the 1990s that no longer exist but whose solutions the industry never fully abandoned. John Carmack, id Software's lead programmer on Doom and Quake, documented his own work on this exact problem in his publicly archived 1996 and 1997 .plan files, where he described building a radiosity-based lighting process for Quake's maps and later extending it to full-color lightmaps for GLQuake. Radiosity is an offline global-illumination algorithm that models how diffuse surfaces exchange light with each other; it was far too slow to run per frame on 1996-era hardware, so Carmack's engine baked its output into lightmaps that the id Tech engine could sample cheaply at runtime — the same fundamental technique modern engines still use for static geometry three decades later, even as hardware ray tracing now handles the dynamic half of the problem those engines could not touch at the time.

That lineage runs in a fairly direct line to today: Quake's baked lightmaps in 1996, Half-Life 2's directional radiosity normal maps in 2004, Doom 2016's probe grids and screen-space reflections a decade later, and finally fully ray-traced pipelines like Metro Exodus Enhanced Edition and Lumen-based Unreal Engine 5 titles in the 2020s. Each step kept the parts of the previous generation's shortcuts that still worked and replaced only the parts that new hardware finally made unnecessary.

That history matters for understanding a common misconception: baked lighting is not an obsolete technique waiting to be fully replaced. Many current AAA titles, including ones that also use dynamic techniques for moving objects, still bake static geometry, because baking remains dramatically cheaper computationally and, for anything that genuinely never moves, indistinguishable in quality from a fully dynamic recalculation. The engineering question was never "baked or dynamic" as a binary; it has always been which parts of a given scene actually need to respond to change, and which don't.

What people get wrong about "ray tracing on" as a single setting

A common misunderstanding is treating a game's "ray tracing" toggle as one uniform feature that is either fully on or fully off. In practice, most games that offer a ray tracing option only replace specific pieces of the pipeline — commonly reflections, contact shadows, or ambient occlusion — while everything else, including the bulk of diffuse indirect lighting, may still run through baked lightmaps, probes, or screen-space approximations. Metro Exodus Enhanced Edition and a small number of other titles are unusual specifically because they replaced the entire indirect-lighting pipeline with ray tracing rather than one component of it.

A second common misconception is assuming that more dynamic lighting is always better lighting. Baked lighting can look objectively superior to a real-time equivalent in a still scene, because the offline bake had unlimited time to converge to a near-noiseless result, while a real-time system is bound by the same millisecond budget as everything else on screen. The real tradeoff engines are making is not quality versus performance in the abstract, but flexibility versus performance: dynamic systems buy the ability to react to change at a real, and sometimes visible, cost in noise, ghosting, or lower sample counts compared to what an unlimited offline bake could achieve for the exact same scene held perfectly still.

What this means

Every image a real-time game shows you is the product of a running argument between physical accuracy and a 16-millisecond clock, and that argument is settled differently for direct light, static indirect light, and dynamic indirect light in almost every modern title. Rasterization decides what's visible; PBR shading models handle direct light cheaply; lightmaps, radiosity normal maps, and probes fake static indirect light for nearly free; voxel cone tracing and signed-distance-field systems like Lumen bring dynamic bounce lighting without a bake step; and ray tracing, still sampled and denoised (if increasingly efficiently, thanks to techniques like ReSTIR) rather than fully simulated, narrows but does not close the gap with offline film rendering. The next time two games with similar art direction ask for very different GPUs, the answer is almost never "one has better graphics" — it's that they made different bets, from Half-Life 2's radiosity normal maps to Metro Exodus Enhanced Edition's fully traced pipeline, about which of these shortcuts to spend their frame budget on. Readers curious about how engines handle motion and interaction rather than light can see the same design-under-a-deadline logic at work in how collision and pathfinding get approximated too.

---

Read next:

• How hitboxes work in video games
• Why frame rate changes game feel
• How pathfinding AI moves NPCs

FAQ

Q: What is the difference between rasterization and ray tracing?

Rasterization projects 3D triangles onto the screen and calculates lighting separately for the pixels each triangle covers, which is fast because it only computes lighting for what the camera can see. Ray tracing simulates individual light rays bouncing off surfaces, which is structurally closer to real physics but far more computationally expensive, so real-time implementations use only a small number of rays per pixel plus denoising rather than a full simulation.

Q: Why do baked lightmaps look wrong when a light moves in-game?

Lightmaps store indirect lighting calculated once, offline, on the assumption that the lights that produced it stay in their original position. If a light source moves or is toggled during gameplay, static objects using that baked lightmap keep showing the old bounce lighting, since nothing triggered a recalculation.

Q: Does turning on ray tracing guarantee perfectly accurate lighting?

No. Real-time ray tracing typically samples only one or a few rays per pixel, far fewer than the millions used in offline film rendering, and relies on denoising algorithms to reconstruct a clean image from that sparse sample. This can introduce visible artifacts like ghosting or blur during fast camera or object movement, even with sampling improvements like ReSTIR reducing how much noise needs to be filtered out.

Q: Why do some games with similar-looking graphics have very different hardware requirements?

Different engines make different tradeoffs between precomputed (baked) lighting, which is cheap to run at the cost of flexibility, and fully dynamic global illumination systems like Unreal Engine 5's Lumen, CryEngine's voxel-based SVOGI, or hardware ray tracing, which recalculate significant lighting work every frame and require dedicated GPU hardware to run acceptably.

Q: What is global illumination in a game engine?

Global illumination, or indirect light, is light that has bounced off at least one surface before reaching the one the camera sees, such as color bleeding from a red wall onto a nearby floor. It's the most expensive part of real-time lighting to calculate accurately, which is why engines rely on lightmaps, light probes, voxel-based systems, or sampled ray tracing to approximate it rather than simulating every bounce.

Q: What is radiosity normal mapping and why did Valve invent it for Half-Life 2?

Radiosity normal mapping, presented by Valve at GDC 2004, stores three directional lightmaps per static surface instead of one and blends them with a normal map at runtime, letting baked, offline lighting fake the way a bumpy surface should react to light coming from different directions. Without it, a single flat lightmap has no sense of light direction and cannot make normal-mapped surfaces look convincingly bumpy under a moving light like a flashlight.

Q: How did Doom (2016) get realistic reflections without ray tracing?

According to a detailed graphics-pipeline breakdown of id Tech 6, Doom (2016) precomputed dozens of 128-by-128 pixel environment cubemaps at fixed points throughout each level and blended the nearest ones per pixel at runtime, supplemented by real-time screen-space reflections built from the depth buffer and the previous frame. This combination approximated reflective surfaces convincingly on hardware that predated consumer ray-tracing GPUs.

Q: What makes Metro Exodus Enhanced Edition's ray tracing different from most "ray tracing on" games?

Most games with a ray tracing toggle only replace one component of their lighting pipeline, commonly reflections or shadows, while leaving the rest on baked or screen-space techniques. Metro Exodus Enhanced Edition rebuilt its entire global illumination system around ray tracing for every light source, according to NVIDIA's release coverage, and dropped support for non-RTX GPUs entirely rather than keeping a cheaper fallback path.

Q: What is ReSTIR and why does it matter for real-time ray tracing?

ReSTIR, short for reservoir-based spatiotemporal importance resampling, is an algorithm introduced in a 2020 SIGGRAPH paper by Benedikt Bitterli and coauthors that reuses good light samples across neighboring pixels and previous frames instead of resampling every light independently each frame. The published results showed scenes with millions of dynamic light-casting triangles rendering in under 50 milliseconds per frame, which made real-time ray tracing practical for scenes with far more dynamic lights than earlier sampling approaches could handle cleanly.

Q: Is dynamic lighting always better than baked lighting?

Not necessarily in raw image quality. An offline bake has effectively unlimited time to converge to a near-noiseless result for a scene held perfectly still, while a real-time dynamic system is bound by the same millisecond frame budget as everything else being rendered. Dynamic lighting buys the ability to react to a changing scene, not automatically superior visual quality compared to a well-executed static bake of the same moment.