This looks like a precision problem, does it go away if you move closer to the world origin? If so, that will give us a clue on how to fix it.
The increased noise on High scalability is due to a faster setting Lumen uses on High:
r.Lumen.ScreenProbeGather.StochasticInterpolation=1
You can override that to 0 in your DefaultScalability.ini to reduce the noise, at a slight cost.
1 Like
Yes that’s definitely something we can implement, and want to improve. We already have automatic change detection for the direction light and skylight intensities (like if you switch from day to night) but not on any local lights.
- Lumen only uses Radiosity for lighting the Surface Cache, which is only seen indirectly through reflection or final gather rays. Lumen uses radiance caching for the main final gather (solving the first diffuse bounce) which is resampled for rough specular, as well as additional reflection rays for smoother reflections when roughness is below .4.
Check my Siggraph talk on Lumen’s Final Gather for more details:
-
Yes Radiosity requires finite elements, for Lumen these are the Surface Cache texels. We trace from Surface Cache texels against the Global SDF, then sample last frame’s lighting at the hit, that gives infinite diffuse bounces through feedback. However if you do that naively you get a bunch of noise artifacts, so the Radiosity gather has some techniques to make the best use of a small number of rays (caching, probe interpolation and occlusion, spatial filtering, temporal accumulation).
-
Screen and world space radiance probes are tracing rays which hit the Lumen Scene and sample its lighting (direct + indirect from Radiosity). When you set Ray Lighting Mode to Hit Lighting, it instead recalculates direct lighting at the hit point (tracing new shadow rays to each light), but still uses the Surface Cache at the hit point for indirect.
Basically Lumen Scene is only used for multi-bounce (and GI seen in reflections) while the Final Gather (using screen + world space radiance caches) is solving the first diffuse bounce with way higher quality, and solving rough reflections.
Try cranking up Final Gather Quality in the PPVolume
That’s probably from Lumen’s optimization for rough specular - it reuses the diffuse rays for any roughness values greater than .3. You can try raising r.Lumen.Reflections.MaxRoughnessToTrace, however Lumen Reflections can’t really handle denoising such rough reflections (nor is it performant).
There were two improvements for foliage over-occlusion:
- Two Sided shading mode, which I had to revert
- Reduced Global SDF over-occlusion, which made it in
I’m not aware of any changes that would have made foliage darker in 5.0 release compared to preview 2, other than the two sided shading model thing.
That said, you can tweak just how much the Global SDF over-occludes with:
r.LumenScene.GlobalSDF.UncoveredExpandSurfaceScale
r.LumenScene.GlobalSDF.UncoveredMinStepScale
Those aren’t enough though, there will still be black spots where the Global SDF says ‘fully occluded’ incorrectly. It’s something we have to fix.
2 Likes
Lumen Surface Cache does use the Ray Tracing Quality Switch, however the problem is Lumen Screen Traces are just reusing what’s on the screen so these kind of ‘different Lumen Scene than main view’ techniques just cause view dependent lighting due to Screen Traces.
Lumen doesn’t support tiled rendering yet, and it will likely be very difficult to support due to heavy use of screen space operations that will introduce seams at tile boundaries.
Yes that’s a problem. We do want to add Hit lighting to every method and eventually a full Hit Lighting path that doesn’t use any Surface Cache, but that’s pretty far out. We can probably fix most of the foliage over-occlusion while using HWRT by just evaluating the opacity mask during traversal, without full Hit Lighting. I’ll add that to the list.
I’ll add to the list. We should be able to handle source length, however shadowing from a long line light is still going to operate on the center.
1 Like
Lumen reflections on translucency are lower quality and leak, although usually the leaking is limited to ~2m. This is more leaking than I expected. The new (5.1) High Quality Translucency Reflections fix this, at least for the frontmost layer.
1 Like
Welcome back 
Will this be the case for rect lights too? Or all light sources? This would be interesting to know, if we would want to build some longer rect lights, then for better shadows it would probably be better to use several smaller rect lights than one big rect light, to get better shadows.
Someting else related to rect lights and Lumen: I made a post in another thread, where i mainly used rect lights in combination with emissive materials (this post here: (New Lumen in UE5) Why is the ceiling of my parking garage so dark? - #2 by Suthriel )
Particularly this video here:
and there i noticed, that Lumen seems to not like those rect lights, which are sitting under those ramps, that lead up and down.
You can see, how everything around the ramp lights goes really dark, if only the rect lights are active - starting at timestamp 0.44 to minute 1.25. Especially at the time 1.10 to 1.20, where i go closer to the ramp light and look at it.
Auto Exposure is off in that scene (it´s set to manual), and everything is built from regular blocks to make sure, that they work properly with Lumen.
Does Lumen not like diagonal ramps? ^.^
looks to me, as if it were a “screen trace issue”, where the ramp goes out of screenspace and/or the lit up area is too small then (visible), causing the bounces to disappear.
Should be easy to verify though, by recreating similar angles with other lights.
May be wrong though, just a guess based on what I see. (If something disappears when going out of screen, its usually “screen-space-something”.
It seems to be related to the object’s movement speed (around 11000 cm/s top speed in this case). I didn’t notice any correlation between the flickering and the distance from world origin.
YouTube Link 2
Yeah, it is screen tracing, but why? As far as i understand it, screenspace stuff or screen trace is the last resort, the fallback or failsafe method, if everything else fails.
But why does everything else fail at those ramps, so that it has to use screen trace? The only difference between such a ramp and all the other blocks is it´s angle, same for the rect light and it´s emissive block.
Might be worth investigating.
I did some investigation, I can find similar things happen on normal walls, not at an angle.
I also noticed that lumen does a lot of weird things which I cant yet put into context properly, but the whole “Voxel” thing it uses randomly culls stuff, for example.
You probably found a bug, or a technical limitation. (Probe traces should hit your ramp… unless the ramp was culled.)
1 Like
Think you have this reversed, the fallback method is the Lumen Scene. It first traces against the screen because (I assume) it is the highest quality view of the world that Lumen has, it only falls back to tracing the Lumen scene if the screen traces fail.
1 Like
Screen space is going to be used in a lot of smaller areas where larger methods are going to lack detail, mesh distance fields are going to be used in areas where screen space techniques are going to quickly fail, like under meshes. Global and mesh are going to be relied a lot more on screen edges, global is going to be used a lot in large safe areas
1 Like
Thats a cool view, can we enable that in our projects? So in this case, at least for the ramps, it probably should switch to mesh distance fields, but it seems, it doesn´t do it for some reason.
Ok, would make sense too. I guess, i interpret all the screen stuff as the fallback, because it cannot handle anything, thats outside of the view (even if its something as bright as a Sun or Nuke ^.^). so i prefer other methods, which are able to react to stuff outside of the screen.