Your hitches are gone — that was garbage collection. Now the steady cost. Lumen is on by default in UE5, it looks fantastic, and it's eating your frame budget in a way that isn't obvious from the viewport.

The good news: Lumen's stated shipping target is large open worlds at 60 FPS on current-gen consoles, and the High scalability level contains settings aimed at exactly that. It's not a cinematic-only feature. But you have to know which knobs matter.

The trade you made

Baked lighting: hours of build time, near-zero runtime cost, nothing moves.

Lumen: zero build time, a few milliseconds every frame, everything moves.

For a solo dev iterating at 4 AM, "no light builds" is worth real frame time. Just be clear that's the deal — and note that Lumen and GPU Lightmass don't coexist. Pick one.

Two halves: Lumen Scene and Final Gather

Every optimisation guide throws cvars at you without saying what they touch. There are two pieces:

Lumen Scene — a simplified representation of your world used to compute indirect light. Surface Cache stamps each mesh's surfaces onto an atlas (roughly six to eight orientation cards per mesh) and lighting is solved on those cards.

Final Gather — the per-pixel resolve that combines Lumen Scene with screen-space and traced contributions into the lighting you see.

Your bottleneck moves between them depending on the scene. That's why one person's cvar list makes your game slower.

Software vs Hardware ray tracing

Software Ray Tracing doesn't trace triangles. It traces Mesh Distance Fields — precomputed volumes storing distance-to-nearest-surface — merged into a Global Distance Field. It needs Generate Mesh Distance Fields on in Project Settings, runs on a wide range of hardware, and is the fastest Lumen tracing method. Epic recommends it for games that can't afford hardware tracing, or as a fallback for GPUs without support.

Its cost is independent of instance count and overlap, because it traces one merged field. That makes it a great fit for kitbashed and heavily overlapping content.

Its limits are real: distance fields can't represent features thinner than their voxel resolution, and there's no skeletal mesh GI. Your character doesn't bounce light.

Hardware Ray Tracing traces actual triangles and evaluates lighting at the hit point instead of reading the lower-quality Surface Cache. Higher quality, needs RT-capable hardware, and its cost depends heavily on how much your meshes overlap.

Which one is default has moved between engine versions. Don't trust a tutorial — open Project Settings → Rendering → Lumen and read it yourself.

The three settings with the best ratio

1. Screen traces. Lumen tries screen-space first because it's cheap, then falls back to world-space. Turning screen traces down in your Post Process Volume is one of the more direct levers, at the cost of accuracy for off-screen contributors.

2. Max Roughness To Trace. By default every pixel with roughness below 0.4 traces a dedicated reflection ray. Above that, it gets a free approximation from Lumen GI. If a big chunk of your screen is smooth — wet streets, polished floors, water — that threshold is your reflection cost. It's in the Post Process Volume, and clampable via r.Lumen.Reflections.MaxRoughnessToTraceClamp from scalability settings.

3. Skybox and giant meshes with HWRT. A mesh that overlaps the entire scene is a hardware ray tracing performance problem. Disable Visible In Ray Tracing on your skybox. This one is nearly free and catches a lot of people.

Debug views worth knowing

Show → Visualize → Mesh Distance Fields. If a mesh looks blobby or is missing here, that's your explanation for lighting behaving strangely under Software tracing. Whiter areas mean more ray march steps — that's cost, visualised.

Lumen Scene and Lumen Surface Cache visualisation modes show what Lumen actually thinks your world looks like, which is frequently not what you think it looks like.

Why old advice is wrong

Most Lumen tuning content dates from 2022–2023, when "Lumen can't do 60" was received wisdom. Epic has shipped meaningful hardware-tracing performance work since, and the calculus for what's affordable has moved.

The lesson isn't "Lumen is cheap now." It's: measure on your engine version and your target hardware, and treat any cvar list older than your engine as a starting hypothesis, not a recipe.

One thing that hasn't changed: Epic does not officially recommend full Lumen on mobile.

Common pitfalls

  • Copy-pasting a cvar list from a 2023 video. Different engine, different bottleneck, possibly slower.
  • Software tracing without Generate Mesh Distance Fields. It has nothing to trace against.
  • Skybox visible in ray tracing under HWRT. Free performance you're not taking.
  • Expecting characters to bounce light under Software tracing. No skeletal mesh GI. That's the system, not a bug.
  • Ignoring the roughness threshold on a scene full of smooth surfaces. Your reflections cost more than your GI.
  • Enabling GPU Lightmass with Lumen on. They don't work together.
  • Profiling in the editor. Say it with me: packaged build.

30-second recap

  • Lumen trades build time for milliseconds per frame. Baked trades the reverse. You can't have both — GPU Lightmass and Lumen don't mix.
  • Two pieces: Lumen Scene (world proxy + Surface Cache) and Final Gather (per-pixel resolve).
  • Software traces distance fields — fast, wide hardware support, cost independent of overlap, no skeletal GI, misses thin features.
  • Hardware traces triangles — better quality, cost scales with mesh overlap.
  • Check which is default in your version's Project Settings.
  • Biggest cheap wins: screen traces, Max Roughness To Trace (default 0.4), skybox out of ray tracing.
  • Measure on your version. Old cvar lists are hypotheses.

Next Sunday: Nanite — when it helps, when it hurts, and why "just turn it on for everything" is bad advice.

— Marco