Summary
A USceneCaptureComponent2D with bCaptureEveryFrame = true and bRenderInMainRenderer
=false causes FLumenSceneData::IndirectLightingAtlas and RadiosityNumFramesAccumulatedAtlas on the shared Scene->DefaultLumenSceneData to be set to nullptr every frame.
This permanently resets Lumen Radiosity temporal accumulation for the main view, producing severe indirect-lighting flicker — most visibly in Lumen Reflections on water. Direct lighting is unaffected, which makes the issue look like Radiosity noise rather than a resource-lifetime bug.
Engine version: UE 5.8.1
Fix we tested
Guarding the destructive branch with the bLumenActive flag already computed at the top of the same function resolves the issue completely:
else
{
if (bLumenActive)
{
LumenSceneData->IndirectLightingAtlas = nullptr;
LumenSceneData->RadiosityNumFramesAccumulatedAtlas = nullptr;
}
}
With this change, r.Lumen.Visualize 24 saturates and stays stable, and the GI flicker — including the reflection flicker on water — is gone.We could not identify a memory regression from this change:
Questions
- Is the unconditional nulling intended? It appears to conflate two different meanings of “this renderer did not produce the atlases”: “nobody needs them anymore” (safe to release) versus “this renderer simply isn’t doing Lumen work” (must not release).
- Should a renderer that performs no Lumen work be allowed to decide the lifetime of scene-shared Lumen resources at all?
- A very similar hazard is explicitly guarded elsewhere, in FDeferredShadingSceneRenderer::UpdateLumenScene()
// Refresh LumenScene if some updates were ignored due to Lumen being inactive
// For scene captures, don't trigger a reupload unless the scene capture has view specific LumenSceneData (not the default data)
if (!bAnyLumenActive && (!Views[0].bIsSceneCapture || &LumenSceneData != Scene->DefaultLumenSceneData))
[Attachment Removed]