in the part of our application which is used for offline image generation we’re seeing an undesired behavior and are unsure which is the best way to mitigate that.
There is a pretty long time (2-3s) after switching from a non-Lumen-GI to a Lumen-GI image in which the scene visibly settles. The effect can be seen in the Editor in the attached video. After selecting an environment and a car the scene is rendered without Lumen in a default setting. After switching to the interior view our app activates Lumen GI + Lumen Reflections and the scene take long to settle.
Afterwards if I manually deactivate and activate Lumen GI the time to settle is negligible. But if I switch to a different Car (an therefore activate a non-Lumen-GI scene) and reactivate Lumen GI the effect shows up again.
My guess is that the changed geometry in the scene requires at least new acceleration structures.
In the trace I can see during that time that per frame Update Lumen Scene is called. Is there a way to reduce this initial setup time even if it increases the time per frame? We like to have more control over this time frame so we can know for sure when the scene is ready to render.
I would prefer CVars, since we don’t have the possibility to make changes to the Engine.
You can try adjusting the following Lumen CVars to see if they help:
r.LumenScene.SurfaceCache.CardCapturesPerFrame
r.LumenScene.SurfaceCache.CardCaptureFactor
However, looking at the video, it’s hard to tell if this is entirely a Lumen issue, or some other camera / post processing settings are contributing. It looks like there might be a large exposure adjustment for instance, which might be contributing to the issue. Can you try with a fixed exposure to see if this makes a difference.
To help further, it might be useful if you are able to create a small reproduction of this issue in a blank project. Then we can have a look at what settings might be affecting this, as this level of noise seems unusual.
I investigated further and tested the CVars you proposed. I tested a bunch of combinations of r.LumenScene.SurfaceCache.CardCapturesPerFrame between 30 and 9999 as well as r.LumenScene.SurfaceCache.CardCaptureFactor between 1 and 256. Sadly it didn’t affect the behavior of the scene.
I have found another way to reproduce the issue which should rule out any form of auto exposure related effect:
I start with a car and an PPV (Actor + PPV component) with disabled Lumen GI -> I then hide the cars geometry and show it again -> Then activate Lumen GI -> The scene lighting takes long to converge to the final result (as seen in the initial video). The same effect occurs right after I hide and show the geometry while the PPV has Lumen GI enabled. Maybe this helps you to help me pinpoint the issue. If I toggle Lumen GI without hiding the geometry the change is near instant.
Some more information which might be useful narrowing it down: we’re using regular Shadow Maps and Nanite. Lumen GI is off by project settings and only activated on demand in a PPV. i wasn’t able to create a simple reproducer, I guess this effect is only this visible because the scene is somewhat heavy.
If you’ve got any more suggestions for CVars to try, please let me know.
In addition to the Lumen surface cache settings mentioned above, there might be some other settigns to improve the speed at which Lumen updates. Can you try changing the following settings on the post process volume:
On the PPV, under Global Illumination > Lumen Global Illumination > Advanced
Lumen Scene Lighting Update Speed: Controls how much Lumen Scene is allowed to cache lighting results to improve performance. Larger scales cause lighting changes to propagate faster, but increase GPU cost.
Final Gather Lighting Update Speed: Controls how much Lumen Final Gather is allowed to cache lighting results to improve performance. Larger scales cause lighting changes to propagate faster, but increase GPU cost.
[Image Removed]Other useful settings can be found here.
If the above doesn’t help, you can try changing the following CVars:
Disable r.LumenScene.Radiosity.Temporal: Whether to use temporal super sampling on Radiosity. Increases quality, but also adds latency to the speed that lighting changes propagate, and animated noise in the results. Enabled by default.
Increase r.LumenScene.Radiosity.UpdateFactor: Controls for how many texels radiosity will be updated every frame. Texels = SurfaceCacheTexels / Factor.
Increase r.LumenScene.DirectLighting.UpdateFactor: Controls for how many texels direct lighting will be updated every frame. Texels = SurfaceCacheTexels / Factor.
Enable r.LumenScene.FastCameraMode: Whether to update the Lumen Scene for fast camera movement - lower quality, faster updates so lighting can keep up with the camera.
Enable r.Lumen.Reflections.RadianceCache: Whether to reuse Lumen’s ScreenProbeGather Radiance Cache, when it is available. When enabled, reflection rays from rough surfaces are shortened and distant lighting comes from interpolating from the Radiance Cache, speeding up traces.
Disable r.LumenScene.Lighting.Feedback: Whether to prioritize surface cache lighting updates based on the feedback.
Increase r.LumenScene.MeshCardsPerTask: How many mesh cards to process per single surface cache update task.
Disable r.LumenScene.SurfaceCache.CardCaptureEnableInvalidation: Whether to enable manual card recapture through InvalidateSurfaceCacheForPrimitive().
Enable r.LumenScene.SurfaceCache.Freeze: Freeze surface cache updates, useful for debugging.
You might also be interested in the findings from this case: [Content removed]
On a sidenote, is there a reason why you are using regular shadow maps instead of virtual shadow maps (VSM)? Nanite works best with VSM (and streaming virtual textures) since these are all virtualised (geometry and texture maps). Switching to VSM will probably not have any affect on the Lumen update speed, but might give better visual results.
I didn’t test every combination of values you provided, but what brought a bit of positive effect were the PPV settings “Lumen Scene Lighting Update Speed” and “Final Gather Lighting Update Speed”. But I had to crank it up to 16, which is, as of my understanding, the limit what the engine uses.
The CVars had very little if any effect, though. I might have to dig through the CVars for the Lumen Final Gather, this PPV setting subjectively had the most effect on the scene. Any recommendations what to check first would be greatly appreciated.
Anyways, these changes enabled us to reduce the time we had to wait to render an image a little bit, which is nice.
In regards to your question why we don’t use VSM: I simplified a bit there. We use either CSM or VSM depending on which type looks better and produced the least artefacts.
thanks for the update. If changing the final gather settings yields an improvement, you may try changing these ScreenProbeGather (Lumen’s default final gather method) related CVars, but keep in mind that all of them trade off speed versus quality:
r.Lumen.ScreenProbeGather.ScreenTraces.HZBTraversal Default value: 1 (faster when disabled) Whether to use HZB tracing for SSGI instead of fixed step count intersection. HZB tracing is much more accurate, in particular not missing thin features, but is about ~3x slower.
r.Lumen.ScreenProbeGather.Temporal.MaxFramesAccumulated Default value: 10 Lower values cause the temporal filter to propagate lighting changes faster, but also increase flickering from noise.
r.Lumen.ScreenProbeGather.Temporal.MaxRayDirections Default value: 8 Number of possible random directions per pixel. Should be tweaked based on MaxFramesAccumulated.
r.Lumen.ScreenProbeGather.DirectLighting Default value: 0 (faster when enabled) Whether to render all local lights through Lumen’s Final Gather, when enabled. This gives very cheap but low quality direct lighting.
r.Lumen.ScreenProbeGather.DownsampleFactor Default value: 16 (higher is faster) Pixel size of the screen tile that a screen probe will be placed on.
r.Lumen.ScreenProbeGather.TracingOctahedronResolution Default value: 8 (lower is faster) Resolution of the tracing octahedron. Determines how many traces are done per probe.
r.Lumen.ScreenProbeGather.RadianceCache.ProbeResolution Default value: 32 (lower is faster) Resolution of the probe’s 2d radiance layout. The number of rays traced for the probe will be ProbeResolution ^ 2