Check the lumen scene debug views, when there’s large difference between the lumen scene and the final stable image temporal accumulation is going to be much more obvious.
1 Like
Just remember that certain PBR values will make lumen work harder; eg: roughness specifically can cause lumen to fire off extra rays:
NO IDEA what you are doing with your forest. just a reminder w/lumen it’s not just materials + mesh = cost it’s materials + mesh + PBR = cost.. :-/
1 Like
Fortune that @myasga can only delete his messages.
Hey, i wanted to clear things out without spam. Actually found solution to solve flicker for Lumen with DLSS - yeah its not a fancy like it should be- but acceptable imho. Seems noone liked the way i do that . So Better to not waste my time to sharing the experience if it so bad? I think engineers here should provide out of the box working stuff. My shortcuts seems rage everyone - better to hide in basement and keep quiet. Excuse me if it bothers You.
All the best.
Tiny dev (not even indie)
myasga
Hello! I’ve encountered a weird issue and I figured I’d cross-post it here since I’m fairly sure it has something to do with Lumen in conjunction with the volumetric fog.
I sometimes get small localized colored flashes at various locations in my scene. It happens while both in editor, playing, and in builds. I haven’t managed to find a way to reproduce it (tried moving the camera fast, in small increments, walking, running, etc.) Here’s an occurrence I captured:
Here’s my original post for more info on my set-up: Small, bright, random color flashes in Volumetric Fog with Lumen 5.6.1 (If anyone as any leads, I’ll make sure to update it as well). Thanks!
1 Like
5.7.1
Bumped the SM5 Lumen Fix to 5.7.1 and added some fixes. Probably time to call End of Life on SM5 Lumen going forward after studying UE5-Main. Looks like 5.7.1 will be the last D3D SM5 “unofficial” branch with 5.6 being the last epic release to support it.
https://github.com/uno1982/UnrealEngine/tree/5.7.1-Lumen-D3D-SM5-Fix
It’s been a great run! …. Mid and Low range cards will miss you dearly!
1 Like
I have encountered the exact same thing. It’s not Lumen related since we have it without Lumen running and we are just using traditional baked lighting and reflection probes. I think it started after maybe 5.3 though I can’t be sure.
In UE5.7 Lumen hardware ray tracing, reflections are inconsistent with the scene’s appearance after enabling Skylight Leak.
The threshold for Skylight Leak seems to be incorrect in reflections.
SkyLight Leak ON
SkyLight Leak OFF
r.Lumen.SkylightLeaking.ReflectionAverageAlbedo
This issue has been resolved using this parameter.
The default threshold for this parameter is 0.25. I changed it to 0.035, the same as in the scene, and the effect is much better. I don’t know why this threshold causes decoupling.
1 Like
Somewhere in 5.5 or 5.6 we changed how sky leaking works in reflections. Instead of just adding sky energy to each ray we now simulate skyleaking as “sky lighting on a diffuse reflection hit” X “r.Lumen.SkylightLeaking.ReflectionAverageAlbedo” X “PPV Sky Leaking Parameter”. Basically instead of everything becoming semi-transparent (sky is visible through walls in reflections) sky is now lighting hit points. Additionally we don’t apply skyleaking to reflection screen space traces, so that reflections show exactly what you see on screen. This allows to push sky leaking parameter (as in - inject more diffuse GI energy) without destroying reflections.
So if you’re seeing those changes after upgrade from an older version than 5.6 then it’s an expected change. Also your base colors seem to be pretty dark, so indeed it may require to tweak that CVar a bit.
5 Likes
Basically instead of everything becoming semi-transparent (sky is visible through walls in reflections) sky is now lighting hit points
Wish I’d known this sooner, this change makes it a lot more useful
That’s so weird O_O Have you managed to make it go away somehow?
Hi, I’ve noticed switching from 5.6 to 5.7 the CVar r.Lumen.ScreenProbeGather.TracingOctahedronResolution now seems to accept only power of 2 values, whereas in 5.6 it could be any integer. This is a setting that has a large effect on performance, so I’m curious as to why we wouldn’t rather be able to set it with higher granularity. For example, 8 might look too rough but 16 is too expensive.
Yeah, non-pow2 values didn’t work correctly (broken lighting) and on some NV drivers were even causing crashes (we were reading/writing groupshared memory out of bounds). Maybe one day we can revisit that and allow more granular scalability control.
1 Like
Submitting a bug report for UE5.7.2. Pressing F11 to switch to full-screen mode causes the engine to crash.
Lumen hardware ray tracing is enabled by default.
@Bio_Weapon are you able to consistently reproduce that crash?
Could you share a project that we can use to reproduce it?
@Bio_Weapon I think this is a known issue that was addressed in 5.7.3.
Can you test it in 5.7.3 (released today) and let us know if it’s still a problem?
5.7.3… just testing my baked room again. and i have…
a petition to implement:
- basic sky athmosphere computation for raytraced reflections.
- correct skylight for main pass and matching skylight shadows for raytraced reflections.
-
maybe both of them should work?
-
maybe bother marching volumetric fog in reflections?
something? anything to make this clean and stable visual work?
those still are very incomplete sky traces. i really gotta use a skybox and have no athmospheric fx or ambient “fakes”?
this one is even more weird. “refractive” glass.
where does the compositor fall apart? you know?!?