# Lumen indirect light is exactly zero: here is where it works and where it stops

**URL:** <https://forums.unrealengine.com/t/lumen-indirect-light-is-exactly-zero-here-is-where-it-works-and-where-it-stops/2844467>\
**Category:** Rendering\
**Tags:** unreal-engine, question\
**Created:** [October 24, 2026, 12:38am UTC](https://forums.unrealengine.com/t/lumen-indirect-light-is-exactly-zero-here-is-where-it-works-and-where-it-stops/2844467 "2026-10-24T00:38:39Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![FrankieDcreator](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@FrankieDcreator](https://forums.unrealengine.com/u/FrankieDcreator)\
**Post date:** [October 24, 2026, 12:38am UTC](https://forums.unrealengine.com/t/lumen-indirect-light-is-exactly-zero-here-is-where-it-works-and-where-it-stops/2844467/1 "2026-10-24T00:38:39Z")

</div>

Engine and setup: Unreal Engine 5.4.4, Linux editor running headless on a cloud machine, NVIDIA RTX A5000 (driver 535.183.01), Vulkan. Project is an open world city blockout: 296 static mesh components built from 4 basic shapes scaled to building size, one master material. Captures are SceneCapture2D at 1920x1080, and a real game view capture was cross checked against the editor capture and matches, so every number below is a true read of the rendered frame.

## What works, step by step

1. The project loads and saves cleanly. Levels, materials, and lighting settings survive cold restarts and reproduce identical numbers across four separate cold reloads.
2. The materials are fixed. An earlier checkerboard fault was traced to a texture sampler type and repaired in code; there are zero shader compile failures in any log since.
3. Direct light works. In a small diagnostic room we built (fresh imported box and floor, movable sun at intensity 3.0, movable skylight at 1.0, plain mid gray material, exposure locked), the room is provably lit: whole frame mean luminance 89.54, near black fraction 0.2812.
4. The textures are fine. The unlit base color of the production facades measures mid bright (95.64 luminance, 5.44 percent near black). The surfaces are not dark; the light is not arriving.
5. The Lumen Surface Cache is alive. On level reload it logs Surface Cache Updates of 116, then 16, 16, 37. Meshes register and update.
6. Every setting reads correct inside the same process that takes the measurement: GI quality 3, dynamic GI method Lumen, reflection method Lumen, distance field generation enabled, all component distance field flags True, every Lumen intensity that exists reads 1.0.

## Where it stops

At the last step, the bounce itself. In every configuration we have ever measured, switching Lumen global illumination on and off changes the frame by exactly zero.

- Production day level: mean luminance 48.07 with Lumen, 48.05 without. Near black 46.7 percent both ways. The facade band is identical to two decimal places.
- The diagnostic room: 89.54 with Lumen, 89.54 without, warm and after a cold restart. Every frame from that session is byte identical to the next.
- Same zero under the SM6 shader platform (we ran the whole test again under SM6; the lighting result did not move by a single pixel).
- Production frames stay far too dark as a result: day 46.7 percent near black (our pass bar is under 15 percent), night 78.3 percent.
- Light mobility is not it either. The production sun and sky light read Stationary; we flipped both to Movable inside the process (nothing saved) and remeasured. The flip provably reached the renderer (the frame moved, in the worsening direction), and the Lumen comparison in the flipped state still measured exactly 0.0. The diagnostic room, fully Movable throughout, says the same.

## The tool that could answer the next question crashes the editor

Software tracing runs on the global distance field, so we tried to read its state with the engine’s own instrument. r.GlobalDistanceField.Debug.ShowStats exists on this build. We enabled it in the diagnostic level, after several hundred settled frames. On the first rendered frame after the set, the editor asserted in the Vulkan descriptor write path:

Assertion failed: WriteDescriptors[DescriptorIndex].descriptorType == VK\_DESCRIPTOR\_TYPE\_STORAGE\_BUFFER || WriteDescriptors[DescriptorIndex].descriptorType == VK\_DESCRIPTOR\_TYPE\_STORAGE\_BUFFER\_DYNAMIC [File:Runtime/VulkanRHI/Private/VulkanDescriptorSets.h] [Line: 1016]

No statistics were emitted before the assertion, and the editor hung in its crash state. Attribution is clean: hundreds of captures in the same level and configuration across three prior sessions never asserted, and enabling ShowStats was the only changed variable in that boot. The two distance field log categories, raised to Verbose before level load, also produced zero output lines across the whole boot. So on this build, the global distance field’s state cannot be read with the tool provided for reading it. Has anyone else hit this assertion on Linux/Vulkan?

## Two side doors we tried, and what answered

Distance fields: software tracing depends on mesh distance fields, and no distance field build has ever been observed on this setup. The project setting is on, the per mesh flags read True, and we wrote the Distance Field Resolution Scale through the editor subsystem’s official build settings calls with readback proving the value landed on all four shape assets. Still zero build lines in every log: no finished build message, no atlas lines, nothing. A genuine fresh import of new meshes also produced no build line and no bounce. ResavePackages does not force it either. (We know a scale near 2 is reported to break a mesh’s field; the diagnostic room’s fresh meshes carry the default scale and show the same zero, and a session resetting the scale to 1.0, forcing a derived-data fill, and cooking the diagnostic map is under way.)

Hardware ray tracing: we tried to test the other tracing path. On the SM5 platform the renderer itself says ray tracing is disabled because the SM6 shader platform is required. Under SM6, setting r.RayTracing to 1 in the project config takes at the config layer (the project setting echo reads 1), and the same boot enumerates the card’s ray tracing extensions as present and enabled. But at renderer init the engine answers, word for word: “Ray tracing is disabled. Reason: disabled on current platform.” So on this Linux Vulkan build the hardware path cannot be switched on at any layer we can reach, even though the GPU supports it.

One more fact: PostProcessSettings on this build has no diffuse indirect intensity property at all. We checked directly. Any fix that turns that dial cannot run here.

## Already ruled out, all measured

Scalability settings, zeroed intensities, components opted out of distance field lighting, dark textures, stale skylight data, bad saves, shader failures, and stationary versus movable lights. The integrated-GPU fallback does not apply: the boot log’s Vulkan profile check examined exactly one device, the discrete RTX A5000. Brightness increases do not help: raising sky fill moved nothing in the bounce measurement, because there is no bounce to amplify. The fault is a pipeline that produces exactly zero indirect contribution while every input we can measure reads healthy.

We also ran a full research sweep of these forums and the issue tracker, GitHub, NVIDIA’s forums, Reddit, and Stack Overflow. No published report matches the full signature. The closest solved cases each cover part of it, and each resolved to a capability gate rather than to content, lights, or intensities. Two support tickets are open with our cloud host in parallel: one asks for a Windows template exception so the reference run below can happen; the other asks the platform questions only the host can answer (GPU passthrough versus virtual GPU, driver version, headless device enumeration).

## What we are asking

1. Has anyone seen Lumen contribute exactly zero on UE 5.4.4 Linux Vulkan while the Surface Cache updates normally? What was the cause?
2. What actually forces a mesh distance field build for an existing asset on a headless Linux editor, short of opening the GUI Static Mesh Editor? Commandlet, console command, or code sequence?
3. Is the Lumen Scene visualization obtainable at all without a viewport? The console view modes do not engage on our captures.
4. Is the ray tracing platform refusal on Linux Vulkan SM6 a known engine limitation of 5.4.4, and does it change in later versions?

Our next step is a reference run of the same project and the same diagnostic room under Windows and DirectX 12, where ray tracing can be enabled and the editor visualizations are available, to split platform from project. If you have seen this exact zero before, we would rather hear it than rediscover it.

---

<div class="post-metadata">

**Author:** ![ChenDong](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@ChenDong](https://forums.unrealengine.com/u/ChenDong)\
**Post date:** [October 26, 2026, 10:46am UTC](https://forums.unrealengine.com/t/lumen-indirect-light-is-exactly-zero-here-is-where-it-works-and-where-it-stops/2844467/2 "2026-10-26T10:46:30Z")

</div>

On 5.4 Linux/Vulkan this signature (surface cache updating, GI delta exactly 0, and “Ray tracing is disabled. Reason: disabled on current platform”) is a capability gate, not a light or material intensity problem. The Windows/DX12 reference run you already planned is the right split. Answering the four questions directly:

1. Hardware RT. That “disabled on current platform” line is expected on 5.4 Linux. Vulkan ray tracing is not a supported Lumen path in 5.4, even when the GPU enumerates the extensions and r.RayTracing=1 is in the config. SM6 vs SM5 does not unlock it. It is an engine platform limit of that version, not a project setting. Do not expect the hardware trace path to turn on here. Later versions started exposing Vulkan RT, still not DX12 parity.

2. Why the bounce is exactly 0. With hardware tracing off, the only other trace is the mesh distance field / global distance field. Screen traces do not save a headless capture: they need a real view’s depth and temporal history, and a SceneCapture or offscreen editor often has neither, so a miss is black. If the DF atlas never filled, every trace misses and toggling Lumen changes the frame by 0. Your log (no distance-field build lines, verbose DF categories empty, diagnostic room at scale 1 still zero) matches an empty atlas, not the “scale near 2 breaks the field” case. Surface-cache updates only mean cards are registered. They are not the structure software Lumen traces for the bounce.

3. Forcing a mesh distance field build without the Static Mesh editor. The project checkbox does not rebuild meshes already in the DDC, and ResavePackages does not either, which matches what you saw. -nullrhi will never build them; you need the real Vulkan RHI. Dirty every static mesh so the mesh compiler runs, then save. With the Python Editor Script Plugin, headless but not -nullrhi:

```python
import unreal
sub = unreal.get_editor_subsystem(unreal.StaticMeshEditorSubsystem)
reg = unreal.AssetRegistryHelpers.get_asset_registry()
assets = reg.get_assets_by_class(unreal.TopLevelAssetPath("/Script/Engine", "StaticMesh"), True)
for data in assets:
    mesh = data.get_asset()
    if not mesh:
        continue
    lod0 = sub.get_lod_build_settings(mesh, 0)
    sub.set_lod_build_settings(mesh, 0, lod0) # dirty + rebuild, which emits the DF
    unreal.EditorAssetLibrary.save_loaded_asset(mesh)

```

UnrealEditor-Cmd Your.uproject -ExecutePythonScript=/abs/rebuild\_df.py -stdout -unattended -nosplash

Afterward the log should show mesh distance field build lines. r.GlobalDistanceField only updates the clipmap from fields that already exist. Also confirm DefaultEngine.ini under [/Script/Engine.RendererSettings] contains bGenerateMeshDistanceFields=True. That is the checkbox property. r.GenerateMeshDistanceFields is not the config name.

1. Lumen Scene view modes without a viewport. Those are viewport modes. They do not composite into SceneCapture2D, and a headless editor has nothing to switch, so the console view modes staying off is expected. Read LogMeshDistanceField / LogDistanceField, or a non-headless HighResShot, or the DX12 run. Skip r.GlobalDistanceField.Debug.ShowStats on 5.4 Vulkan: the descriptor-type assert you hit is a debug-buffer bug on that RHI, and it is not the cause of the zero bounce.

Once fields actually exist, the scaled city blocks are a second, separate failure. A scale far from 1 (and any non-uniform scale) bakes a bad field even when the build log is healthy. Keep the diagnostic room at scale 1 until the atlas is non-empty, then place the blocks with a uniform scale near 1. There is nothing to amplify until a trace hits, so skylight intensity and the missing diffuse-indirect post-process property will not move this delta.

---

<div class="post-metadata">

**Author:** ![FrankieDcreator](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@FrankieDcreator](https://forums.unrealengine.com/u/FrankieDcreator)\
**Post date:** [November 6, 2026, 7:36pm UTC](https://forums.unrealengine.com/t/lumen-indirect-light-is-exactly-zero-here-is-where-it-works-and-where-it-stops/2844467/3 "2026-11-06T19:36:14Z")

</div>

Update, November 6, 2026. First, thank you to ChenDong: your reply named the cause ranking we had backwards. We had treated the missing distance field build lines as a likely false alarm and chased capture configuration first. Your empty-atlas reading fits every log we have, and we are running your step 3 today: the rebuild script over every static mesh, under the real Vulkan editor, then a fresh Lumen on/off measurement of the diagnostic room. Results will be posted in this thread either way they land.

Two record corrections to the original post: the machine now runs driver 580.178.04 (the post named 535.183.01), and the Windows/DirectX 12 reference run is blocked on our side: our cloud host no longer offers Windows machines to accounts created after July 2024, so that split cannot run there. If anyone knows another route to the same comparison, we would take it.

Below is the current state of every open engine problem on this project (UE 5.4.4, Linux, headless, RTX A5000, Vulkan SM5), measured on the live project. Any pointer on any one of them is welcome.

1. Chaos vehicle will not turn. Steering input reaches the wheels (runtime steer angles 17.15 / 24.5 degrees at input 0.7, the expected Ackermann pair), all four wheels stay in contact and rolling, suspension loads and moves, yet rolling yaw delta measures -0.007 degrees over 1219.3 cm of travel with 76.0 cm of lateral slide. Our pass bar is 10 degrees. Epic’s template SportsCar in the same harness yaws 43.212 degrees, so the harness is excluded; the defect sits in our vehicle’s own setup. Prime suspects: the cornering-force leg (tire friction / lateral slip / cornering stiffness) and two neighbours we still cannot read: our chassis PhysicsAsset body setup (centre of mass, inertia) and numeric suspension spring/damper values, both unreachable from this build’s Python surface. Our runtime wheel radius reads 35.0 against the template’s 39.0 / 40.0. Ask: which single mis-set best fits correct steer angles, full contact, and about 1 percent yaw with a sideways slide? And what is the reliable route to read a PhysicsAsset’s body setups on 5.4.4 when Python does not expose them?

2. Lumen contributes exactly zero. (This thread’s subject; status: the distance field rebuild test is running today, see above.) Everything else stands as posted: day frame 48.07 with Lumen vs 48.05 without, near-black 46.7 percent both ways, diagnostic room delta 0.0 in every configuration across 16+ sessions, surface cache updating normally throughout.

3. The shipped Derived Data Cache pak crashes the editor. Engine/DerivedDataCache/Compressed.ddp (1,494,093,578 bytes) asserts inside FPakFileCacheStore::GetValue on texture fetches, an index and length of -1 into an array, recurring in crash folders back to October 22. The pak is banked aside and boots are clean since, but every boot pays cold-cache shader compilation, measured at 665 s. Ask: is a same-version clean-file swap the complete cure, or does the pak store need a rebuild or index repair as well?

4. Full-editor boots stall after “Engine is initialized”: the log freezes after Derived Data Cache maintenance, the editor futex-waits, and Python passed via -execcmds never executes. Commandlets run clean end to end (about 32 s), so all our automation routes through them. Ask: known causes on 5.4.4 Linux (Zen DDC, shader worker spawn, Vulkan enumeration), and what thread or state capture best discriminates them mid-stall?

5. Headless tooling limits close audit routes: no PIE begin-play in headless runs (possession unproven; movement proven in Simulate only); PhysicsAsset exposes no body setups in Python and SkeletalMeshComponent has no get\_bone\_location; runtime wheels answer getters but get\_suspension\_length does not exist and wheel class defaults answer zero numeric suspension properties; r.GlobalDistanceField.Debug.ShowStats asserts on this build (already in the original post). Ask: known workarounds, C++ editor utilities, commandlets, or console paths for any of these.

6. Minor and unexplained: our saved night lighting state regrades at 53.38 mean luminance / 0.5775 near-black against its saved record of 52.88 / 0.5818, while every rig value reads back exact on a cold load and the day capture reproduces exactly (94.70 / 0.0933). No established cause; listed in case it rings a bell.

We grade fixes on measured deltas, not plausibility: steering yaw must reach 10 degrees in the same harness, and the Lumen versus None delta must move above zero. Thank you for reading.

---

<div class="post-metadata">

**Author:** ![FrankieDcreator](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@FrankieDcreator](https://forums.unrealengine.com/u/FrankieDcreator)\
**Post date:** [November 6, 2026, 7:55pm UTC](https://forums.unrealengine.com/t/lumen-indirect-light-is-exactly-zero-here-is-where-it-works-and-where-it-stops/2844467/4 "2026-11-06T19:55:38Z")

</div>

Results, November 6, 2026, as promised. We ran ChenDong’s step 3 exactly as written, and it found a real defect before it found anything else: our DefaultEngine.ini carried only r.GenerateMeshDistanceFields=True under [/Script/Engine.RendererSettings]. The actual property, bGenerateMeshDistanceFields=True, was absent. That line is now in, and it is very likely why no distance field build was ever observed on this setup.

The rebuild itself ran under the real Vulkan editor (driver 580.178.04): the script touched 182 meshes, and the log carries the first distance field build lines this project has ever produced: 10 “Finished distance field build” lines across 7 meshes, including SM\_Room\_01 (3.5 s, 126x126x119 sparse field). No errors, no asserts.

The bounce still measures exactly zero. The diagnostic room was remeasured cold with the identical method and warm-up as our October 23 baseline: the instrument control reproduced exactly (89.54 mean luminance, 0.2812 near-black), and Lumen on vs off reads 89.54 / 0.2812 both ways, band 79.73 / 0.4445 both ways. Delta 0.0.

So the empty-atlas theory, at least in its simple form, does not survive its own test on our setup: fields now build, and the delta does not move. Two honest caveats: the build lines name 7 meshes, and none of them is a city blockout mesh or the diagnostic room’s box and floor meshes, so we cannot yet swear the room’s own fields are in the atlas; and the measurement boot itself logged no build lines. Our next step is the capture layer (persistent view state and the GI/reflection overrides on the capture), and after that the platform split, if we can find a route to it. If anyone has seen fields build and the delta still sit at exactly zero, that is now precisely our signature, and we would like to hear it.