Real-Time Global Illumination & Lumen

When light enters a room it hits a surface and only some of it is absorbed - the rest scatters back out and travels on to hit other surfaces, and again, and again. Direct light is the portion that reaches a surface straight from the source (the sun, a lamp). Indirect light - global illumination - is everything that arrives after one or more bounces. It is why the underside of a shelf is not pure black, why a red rug throws a warm blush onto a nearby white wall (color bleeding), why a north-lit room feels soft and even. Strip GI out and you get the tell-tale look of a bad render: harsh pools of light, ink-black shadows, surfaces that look lit by a single hard bulb in a void.

Interiors depend on GI far more than exteriors do, because indoors most of the light you see is indirect. Daylight rarely reaches the back of a room directly; it pours through a window, lands on a floor, and bounces up onto ceilings and walls to fill the space. Get that bounce right and a room feels inhabited and true; get it wrong and no amount of nice materials will save it. This is why lighting is its own module in this course, and why we start with the physics before the buttons: if you understand that a room is mostly bounced light, you will light it - and judge it - correctly.

Simulating every ray of bounced light is what offline path tracers do, and it is why they take minutes to hours per frame. Lumen cannot afford that - it has ~16 milliseconds - so it is a clever approximation engine, not a full simulation. It maintains a simplified, always-updating representation of the scene (surface caches and a coarse distance field of the geometry) and uses it to gather indirect light quickly, tracing a limited number of rays and reusing results across frames and screen regions. The result is global illumination and glossy reflections that update continuously, with no bake step and nothing frozen in place.

Lumen runs in two modes. Software ray tracing traces against those simplified proxies (signed distance fields and a merged mesh representation) and runs on a wide range of GPUs - it is the robust default for most archviz. Hardware ray tracing traces against the actual triangle geometry using the ray-tracing cores on modern GPUs (RTX and equivalents): it is more accurate - sharper reflections, better contact detail, fewer artefacts - but it costs more performance and needs capable hardware, which matters enormously in VR where the frame budget is already tight. A practical rule: prototype and review in software Lumen; switch to hardware Lumen for hero stills and cinematics where you can spend the frame time. Reflections have their own quality tiers too, from cheap screen-space approximations up to full Lumen reflections that can see objects off-screen.

It helps to know the moving parts by name, because they are the settings you will actually touch. Lumen keeps a Lumen Scene - a lower-resolution, cached representation of your world - and a surface cache that stores lighting on the sides of meshes it can see; each frame it does a final gather, sending out a modest budget of rays to sample that cached lighting and build the indirect result, then denoises and reuses it across frames to stay cheap. In software mode it can trace short screen traces against what is already on screen and fall back to world-space distance-field traces for anything off screen. On a mid-range GPU, expect Lumen GI and reflections together to cost on the order of a few milliseconds per frame at 1080p - a real slice of your ~16ms budget, which is exactly why you profile it (Module 9). Type stat GPU in the viewport and you can watch the Lumen cost line move as you change quality.

Before Lumen, believable GI in real-time meant baking: a lightmapper (Unreal's older Lightmass) precomputed all the indirect light and stored it into lightmap textures unwrapped across every surface. The payoff was gorgeous, cheap-to-display light and it ran on almost anything. The price was steep: every static object needed a second, non-overlapping UV set for its lightmap; bakes took minutes to many hours; and the moment anything moved - the sun, a wall, a lamp - the lighting was wrong and you re-baked. Iteration, the whole reason we came to real-time, ground to a halt.

Lumen flips that. Because GI is dynamic, you design in the light: drag the Directional Light and watch a room change from morning to dusk, delete a partition and see the space brighten, all with no bake. That is transformative for design review and for interiors, where light is half the design. The honest trade-offs: Lumen costs GPU time every single frame (a baked lightmap costs almost nothing to display), it can show subtle noise, ghosting or light-leak in tight or thin geometry, and very small emissive details or mirror-perfect reflections are weak spots. So the mature answer is not 'always Lumen'. For a fixed, static hero image or a performance-critical VR build on modest headsets, a careful bake can still win. For everything you want to explore and change - which is most of what this course is about - Lumen is the reason real-time interiors finally look right while staying live.

Turning Lumen on is one checkbox in Project Settings (Global Illumination and Reflections both set to Lumen); making it look good is a handful of habits. First, Lumen reads your materials, so PBR discipline from Module 3 pays off here: correct base color (albedo) values drive how much light bounces and what colour it becomes - a floor that is too bright or too saturated will flood the room with false colour. Second, Lumen leans on emissive materials for area lighting and glow, but very small or very bright emissive shapes are exactly where it struggles, so light the room mostly with real lights (next lesson) and use emissive for the visible source and soft glow. Third, watch Final Gather Quality, Lumen Scene Detail and the reflection quality - raise them for a clean still, keep them modest for a smooth VR walk.

A quick reality check for interiors: enclosed rooms with small openings are the hardest case for any GI system, real-time or offline, because the light has to bounce many times to fill the space and each bounce loses energy. If a room reads too dark or noisy, the fix is usually more or larger light sources and sane exposure (Module 4.4), not brute-forcing Lumen quality. And when you profile (Module 9), remember GI and reflections are among the biggest GPU costs in an archviz scene - budget for them from the start, especially in VR. Understand Lumen as a smart approximation with known weak spots, and you will get beautiful, believable, live interior light out of it.

A few concrete dials pay off repeatedly. In the Post Process Volume you can override Lumen per-area: Lumen Scene Detail and Final Gather Quality default to 1.0 - push them toward 2-4 for a clean hero still, leave them at 1.0 for a smooth VR walk. Max Trace Distance governs how far rays search for bounce and reflection; shorten it in tight interiors to save cost, lengthen it for large halls. For meshes to appear in software Lumen they need mesh distance fields generated (a project setting) and a Movable or Stationary mobility - fully Static geometry with baked lighting sits outside Lumen. Thin walls are the classic light-leak culprit: give partitions real thickness rather than single-sided planes, and enable two-sided material handling on foliage. And because Lumen reads emissive and albedo directly, a floor albedo above roughly 0.8 or a wildly saturated wall will pump false colour through the whole room - keep base color values physically sane, as Module 3 taught.