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
- The project loads and saves cleanly. Levels, materials, and lighting settings survive cold restarts and reproduce identical numbers across four separate cold reloads.
- 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.
- 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.
- 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.
- The Lumen Surface Cache is alive. On level reload it logs Surface Cache Updates of 116, then 16, 16, 37. Meshes register and update.
- 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
- Has anyone seen Lumen contribute exactly zero on UE 5.4.4 Linux Vulkan while the Surface Cache updates normally? What was the cause?
- 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?
- Is the Lumen Scene visualization obtainable at all without a viewport? The console view modes do not engage on our captures.
- 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.