Hey, SPEC:
5.4.4 - i7-8700K+RTX 4070 Ti Super
Issue can’t be recognized in Editor Pie, (need to be Game) - also same problem with DoF
Hardware RayTracing Lumen setting:
Foliage Issues that comes with some sort of “shadow movement” also there are similiar issues with Depth of field on 50% screen (DLSS ultra performance makes things even worse).
As you see Cinematic scalability fix a bit those issues and more screen %
Would be cool to use this feature with 50% for DLSS ultra performance on Epic setting. I can provide DefaultEnigine and PostProcess if needed. If there need to be switching something in material in foliage please let me know.
All the best!
Pozdrawiam!
yeh. looks like a side effect of raytracing dense foliage and being rng. sometimes the rays get out and sample a lit probe. sometimes it just hits the underside of another “leaf” polygon. and being in “shadow”. in software lumen most of the leaves are non existent in the sdf and rays get out to shine. hmm…
1 Like
There is an issue with Lumen, not sure if its still in 5.5+, but in 5.4 its definitely.
- if you have small moving objects (I had a bunch of 10x10cm cubes following splines as decoration)
- Lumen will after some time “break down” and start to “flicker”. (can take a few minutes to appear, but then Lumen goes completely crazy as if it is regenerating its scene slower/constantly, making this visible.)
- This also happens when the objects that move dont have a Mesh Distance Field and are effectively removed from the Lumen Scene due to this.
PS: Nice to see this thread still going, and Krzysztof still being here with us 
1 Like
I have seen this a few times with using poly-per-blade type grass where large patches start strobing.
A video always helps. An isolated-issue project, even more.
But with Lumen hardware raytracing - distance fields are not used.
but I am running software lumen.
I dont have one right now, and no time to make one at the moment, just this Screenshot of what they looked like (with lumen still working as intended):
Its literally just cubes moving along a spline, with an underlying “factorio logic” for efficiency reasons. (easy to replicate if performance doesnt matter.)
Tried with MDF, without, ISM, normal meshes, etc… but never could resolve this, and then scrapped it. (That was like 6 months ago, and I was really fighting with 5.4.X in general… its one of those “just skip it”-versions.)
That said: I could isolate it to those cubes moving around → no cubes, no problems.
I assume: they cause a lot of updates and that somehow overwhelms lumen over time, because they “accumulate” somehow? (maybe some cache not being cleared fast enough? idk.)
I also remember it happening faster the more cubes there are, but dont quote me on this.
those seem to be small objects that may hit the bottom of the probe resolution and how often they are “captured”. also… that’s a repeating pattern. i’d guess at some point the repetition makes it’s way into the temporal data and it ends up fluctuating. it’s like an interfence pattern. at some point it hits equilibrium and overlaps and creates high peaks in the waveform. something like that.
what happens if you change the distance inbetween the cubes? or vary the size and distance. or vary the lumen update rate to counteract the repetition. hmm…
I noticed in this picture you increased the probe density a lot compared to default. Does it help with the quality ?
I found two cvars dealing with probe density and their “blurriness” or something but no matter how much I changed those, the quality did not changed to a great percent, More like plus minus 10%.
sry to say, but… this is default. it’s just a small distance. literally just 3.5 meters of travel for the light. maybe 5 meter and something from the camera that manages the grid size lod.
the only thing that is maybe relevant and non-default is the exposure. it’s not autoexposed and i eyeball the light levels. this is maybe not accurate of photorealistic, but works in most cases and my render style.
level created by ue4arch
2 Likes
for me that should be optimized / fixed cause isn’t production ready?
FIXED but it cost alot:
r.Lumen.ScreenProbeGather.DownsampleFactor 5
FIX
also in PPV - but cost even more - similiar result (need to be set to 6 value to see)
this command help a little but it cause smearing:( :
r.Lumen.ScreenProbeGather.Temporal.DistanceThreshold (type number)
smearing
@Krzysztof.N Is there a global illumination system planned that would be lighter than Lumen, possibly allowing for GI baking and the interpolation of various scenarios, perhaps with a probe-based system? Lumen is very resource-intensive (even though performance can be optimized with various tweaks, it still remains quite demanding given the current PC setups most players have).
It could be useful to have a GI solution where developers handle the pre-calculations instead of passing the cost onto the player, which is unfortunately still far too high for players’ hardware.
Not sure if I understand this question correctly.
The main cost of Lumen is tracing GI and reflection rays per pixel, but this is also what allows it to skip baking, unifies lighting, reduces leaking to minimum and doesn’t require any parametrization like UVs.
If you start baking GI and reflections into probes, then basically you arrive back at Lightmass + reflection captures, which we already have in the engine.
I’m talking about a solution similar to what NVIDIA’s RTXGI was, for example: probes that could be dynamic, very low-cost, and adaptive to scene changes in real-time, while also being bakeable if needed. “The Final” uses it as well, for instance. 
It was less precise than Lumen, but in terms of computational load, it was very lightweight.
So you mean DDGI. The issue with DDGI is that by default probes are being placed in a regular grid around the camera, which means that you need to have really thick walls to prevent leaking, and some things like non-axis aligned walls, doors or cars just can’t be really handled by it as you can’t make them thick enough for the low-res VSM visibility.
Also VSM used by DDGI makes things look weird, as it basically looks like a sharp shadow casted from the center of the probe. Imagine that you have one probe in a room with a table. Now everything under the table will either cast a black shadow or will leak if you force reading from nearby probes.
It works kind of OK for outdoors, where leaking isn’t a big issue, but hen you start adding indoors now you need to somehow mark outdoors/indoors or manually place probe volumes to fix the issues. And if you manually place the probe volumes based on the scene geometry, you can’t really handle geometry changes.
Now if geometry needs to be mostly static, why would we even trace any rays at runtime? Tracing rays is pretty expensive so why not cache ray hit points and just relight hit points at runtime using a cached GBuffer? Baking form-factors also allows for better visibility functions than VSM, making it look more like GI than a point light shadow. So now we again arrive back at Lightmass, but with an “Enlighten” twist added to it. Which I believe would be a useful addition, but it’s not really Lumen at this point, as it has more in-common with Lightmass.
1 Like
Interesting, yes, I’m referring to DDGI. I believe that in their solution, Nvidia allows for setting an approximate global DDGI, as well as a much denser one attached to the player.
I’ve already made several general tweaks to Lumen in my game ( A Silent Desolation on Steam ), but I still can’t reduce the costs as much as I’d like. That’s why I’d love to have the GI calculations only occur at key moments (like when the directional or skylight moves) and remain inactive the rest of the time. However, I imagine this isn’t so simple.
Also, baking with GPULightmass takes too long and is completely static, which isn’t great 
2Maenavia - recently I’ve finished “The Talos principle II” and it’s a quite nice example of UE5-based game, with tons of foliage and it’s still runs fast enough with DLSS set to “quality” (monitor resolution is 1920x1080) on maxed out graphics, so I’ve got 50-60fps for my mobile RTX 3070 (desktop equivalent is ~RTX 2080 I guess). And it’s clearly Lumen lighting - spotty & moving GI artifacts at 50+ m distance are there, reflections also Lumen (clearly visible switching between screen-space and Lumen cache on water). Maybe worth checking out how they did that (there was a video on youtube from developers, as far as I can remember), at least if those numbers looks desirable for your project.
MOAR screenshots if needed.
1 Like
Taking this discussion, @Krzysztof.N ,
If the main limitation of the DDGI are the probes, wouldn’t be possible to automatically set their spacing based on geometry? (More dense around them, like in Importance Volumes).
But, more important and more “current”: why keep hit points relighting, if there have been no changes in light sources nor geometries? I mean, if lights and geo is keeping their same values, wouldn’t be possible to keep the cache and lighting “static”, without the need to update it in every frame? And only do it if anything changes (and only around that change, not in the whole scene).
talk about lumen freezing? you can do that using a cc. be aware it will freeze with the importance/lod in place where you froze and will not update or enlarge or shrink or compute any surfaces tiles beyond that point. literally frozen.
lumen is like gpu lightmass with lod for performance. it needs to evaluate the lod from the player position to update. performance management. you do not want full updates for the whole world. and partial updates may introduce propagation glitches and hitches in the lighting. that’s why it is temporal and runs all the time. gotta deal with that. hmmhmm.
you could tick that freeze/unfreeze with an interval. the consequence is you gotta run a couple of frames for the temporal update and you loose surface cache reflections.
(nvm… the edit. i did not find a bug. just left an emissive light that looked truly static. weirdge.)