a massive shader recompilation is not-desirable, but not-permanent either. And if it fixes the issue, I’m generally for incurring a temporary cost to rebuild x, and/or y, and/or z.
it’s still in the development stage. so what?!? we all hate shader comp. yes. just take a chill pill for 10 minutes. it’ll run great when you’re done cooking. : )
Updating…
Weird, but disabling Nanite in specific plant of foliage, then it appears on surface reflections
Is there any new setting in 5.6 that I don’t know about yet?
Foliage reflections seems not working in UE 5.6. Did anyone notice this too?
In this example below, only the satic mesh plant is reflected by surfaces. The foliage, not.
(Lumen reflections, hit lighting for reflections, HRT on - the same configuration I usually use in 5.5)
Lumen looks good only when not in motion, when in motion there’s so much ghosting it is insane.
Look at this, engine on default maximum settings:
Who thought this was acceptable? Who would release a game like this? Ubisoft I suppose… Things didn’t go that well for ubisoft though, did they?
Fix this, and lumen would be great. But as is even if it looks worse in every other way than the ghosting more or less, I’m still considering just using ssgi instead.
I’ve seen TAA blamed for ghosting a lot, and surely some of it is, but that right there, that is all Lumen’s fault.
In the below video I disabled antialiasing and motion blur just to be sure:
I noticed that setting software raytracing mode to detail trace eliminates an enormous amount of ghosting, but it’s still too significant even with that set:
2 Likes
@Krzysztof.N & @Daniel_Wright
Of course, you’ll know I’ve been saying the same thing for almost two years (the smearing issue above)
We didn’t need hardware RT Lume, we needed SW too look like stable option here.
It’s a complete mess & every game suffers from these problems.
As someone who showcases this engine to millions of people Lumen’s temporal reliance is the biggest complaints I hear from developers & customers. It’s 2x+ slower to achieve quality similar of SVOGI which was less prone to these issues(darks areas where bad).
Move indirect lighting to stable SH or SG. And one again, I’ll going to ask for support for static environments with moving lights.
I don’t care if it needs to be another GI system altogether, this is hurting so many projects & people are sick of it.
Maybe related with the posts above, unfortunately:
Please, how would you try to reduce this ghosting? I have already tried many things (and I’m supposed to not be a beginner):
It’s a fan spining on the ceiling of a room, during an accelerated day/night cycle, so the room’s GI is changing. All settings quite maxed out.
Thank you very much!
reduce the speed it’s turning, maybe. looks quite fast. i dunno how fast those turn realistically, tho. in europe we don’t have those. just open windows for ac. this is not a helicopter either way.
also… don’t measure the feedback performance with accelerated daytime. nonsensical use case. ofc it’s not gonna do it that quickly with data changing too much. how fast does the sunlight angle change in your room? consired baking the gi? it’s a matter of choice to get a stable result for the gi application.
I would try:
- r.Lumen.ScreenProbeGather.Temporal.FractionOfLightingMovingForFastUpdateMode
- r.LumenScene.Radiosity.UpdateFactor
Thank you both, @glitchered and @pezzott1,
@glitchered, I usually lose some information from your posts due to the way you write — maybe due to excesive informality or slangs? I’m not sure, since English isn’t my native language. By the way, I live in Europe, and we have ceiling fans. Also, that 3D fan is already spinning much slower than my real-life fan at its minimum speed — a tradeoff I had to make to reduce ghosting.
And yes, it’s definitely a real use case: a user might want to study the sun’s movement without having to wait an entire day, but a couple of minutes. That’s just a light changing over a “loooong” time, compared to almost every game having instant on/off lights, which is a much worse scenario for this issue.
GI has to be dynamic in this case, since it’s a complex ArchViz project where many meshes can be changed in real time.
Thank you @pezzott1, only that first cvar helped a very little, with values like 0.5–0.7, but the issue is still quite noticeable.
I’ve isolated the issue further, trying to clear up some of your doubts. Here’s a video showing the problem at an unrealistically 18rpm slow speed, with fixed lighting in the scene (which obviously improves things, however it’s not a solution, just a tradeoff or downgrade):
Thank you!
1 Like
By setting r.Lumen.ScreenProbeGather.Temporal.ClearHistoryEveryFrame to 1 for debugging I found this type of ghosting vanished completely (although my test scene was less detailed).
This means the primary source of the ghosting is the SPG temporal history. This is why you saw some improvement with the previously mentioned settings.
Instead, I propose you should simply reduce the number of frames that are allowed to be accumulated during your accelerated lighting moves, and increase them during slow lighting moves.
Try r.Lumen.ScreenProbeGather.Temporal.MaxFramesAccumulated (default 10)
This can be safely reduced (or even disabled temporarily) proportionately to the lighting update speed needs as to reduce ghosting, although you might in return see more noise. With temporal accumulation it is always going to be a delicate balance between noise and ghosting.
Ray reconstruction and ray regeneration denoisers handle this particular case more gracefully though, so in the near future this will be less of a problem. Ceiling fans were a specific problem Nvidia showcased to demonstrate the improvements of their denoiser.
3 Likes
Thank you @BananableOffense ,
I punctually use clear/reset the history, when passing from day to night, for example, as lumen keeps some surfaces shinning like emissives. But making it every frame destroys the lighting quality and causes a lot of flickering, as you already know, but for others, too.
About temporal accumulation is one of the mitigations I thought of, but as you pointed, could cause more noise, while Lumen is not the most noise-free lighting system. In fact I rised the accumulated frames to 15, as Archviz is a ‘slow game’, but this changed the whole concept, needing to be treated like a lightning FPS. I tried with a value of 3, which caused huge inconsistencies. Also with 5, with a slightly better result, but both cuased fast flickering too, making it VERY noticeable. 8 seemed like the minimum acceptable value, suffering some noise.
Ray Reconstruction is the best solution for now (I also implemented it), but it doesn’t solve it totally, and at a high performance cost.
So… I finally decided to reduce the fans speed at a very minimum, like blown by a soft breeze… but this also blow my mind.
BTW, @Krzysztof.N , I noticed noise increase in short range AO.
Using the exact same cvars (I define like 50, so probably not missing any important with a new different default value) and project settings:
I was suffering a similar issue in 5.5 in a different project, but using TSR was cleaning it a lot, looking like in this 5.3 shot:
But in 5.6, with TSR and even DLSS enabled (same effect behind a wall TV, for example):
By default short range AO now runs at half-resolution and goes through a denoiser. It made short range AO ~x2 faster and I didn’t see any issues anywhere.
You can restore the previous approach using:
r.Lumen.ScreenProbeGather.ShortRangeAO.DownsampleFactor 1
r.Lumen.ScreenProbeGather.ShortRangeAO.Temporal 0
3 Likes
Thank you @Krzysztof.N ! Worked as expected. I will try to make a repro scene for you, during next weeks.
A side question, please: does it have sense to ask if are you considering something like stochastic (Megalights) for RT AO? All lights are now Megalights, but only if using short RT AO we will still need to use Nanite Mode 1.
BTW, I also noticed a little discrepancy in RT AO:
5.3:
5.6:
(Ignore the blueish layer I added in 5.3, as colors were warmer in that version)
In 5.3 looks more fine and detailed. But in both versions look like missing some darkness under the cushions, isn’t it?
Hi guys,
We recently upgraded to 5.6 and noticed that when creating panoramic renders with MRQ, the scene is a lot darker with the same settings, as if there is barely any GI contribution, especially from skylight and directional light. Is it a known issue, is there any workaround or cVar which could possibly fix it?
These images are with 5.5:
And these are with 5.6:
If I increase the light intensity and the indirect lighting intensity, I get a more blueish result, but still dark:
Mmm, my random guess is to check can light pass through glass in windows - maybe this glass is treated as an opaque surface in 5.6 for some reason.
1 Like
I deleted the glasses, unfortunately I got the same result.
you checked the output colorspace? if i push those dark renders to gamma 2.2 they have approximately the same visual brightness (eyeballed it). they are for sure more saturated and less contrasty. those are tonemapper things, i guess.
1 Like