Is there any way to exclude specular highlights from diffuse indirect screen traces? (I’m on Vulkan, if that matters)
Path Tracer comparison for good measure:
1 Like
As you noticed already the only way is to disable screen traces for GI, so that we don’t incorrectly sample specular as surface lighting on screen space ray hit.
2 Likes
Makes sense, if unfortunate. Thanks anyway for the answer.
1 Like
Any way to make screen traces skip First Person meshes? I have static lighting disabled so I assumed Lumen would be able to take advantage of the first person gbuffer bit to skip screen traces but that seems to not be the case.
1 Like
Hi~ This issue has been resolved in version 5.7.3, thank you~.
2 Likes
In ue 5.7 Ive noticed that lumen quality had dropped a lot, more noise, light artifacts, i also know that they said 5.7had some performance gain which sits together with what I’m experiencing so does anyone here know what Cvars. They changed? Or at least cvars i can tweak to adjust the lumen scene quality to get a good looking scene and also something that works with fast moving meshes without getting that annoying ghosting around the moving parts of the mesh (i know about post process and not planing to use it for now)
It’s hard to say what could cause that without any A/B screenshots or videos. There was a noise regression in 5.7 due to setting r.Lumen.ScreenProbeGather.IntegrateDownsampleFactor 2by default, but this should be reverted back to 1 in one of the hotfixes (5.7.3?).
Is the lumen irradiance field gather mode expected to be usable for 5.8, or do you expect it will still take quite some time? Also, do you have an idea what the approximate perf. savings are from using lumen and megalights simultaneously? I have a small hobby project I’m struggling to get under budget, and am just trying to figure out what my options are.
1 Like
In 5.8 Lumen-Medium should get missing features (translucency and maybe multi-bounce), but I don’t think it will get production polish as that requires to get this first into FN or licensee hands in order to receive feedback and act on it.
There’s some cost sharing between MegaLights and Lumen thanks to using the same ray tracing BVH, but there’s still a lot of added constant cost just to run it. In general MegaLights is a complicated topic due to different tradeoffs - limited BVH quality, area lights, lots of lights, denoiser artifacts… It’s great if you’re doing a cyberpunk city with lots of area lights, but if you’re doing an open world with only sun then you should stick to VSM.
No simple answers here. Ultimately only you know the details of your project and what tradeoffs you want to make.
5 Likes
That’s quite fair and more or less what I was wondering. Do you expect that there is ever a use case for megalights and lumen medium being used together, or is megalights considered a high-end enough feature that it won’t be a viable option for Switch 2?
Hi,
I’ve used r.Lumen.ScreenProbeGather.TracingOctahedronResolution previously to increase GI quality and reduce noise. We now noticed this setting introduces different, very fine noise on some materials, especially on rough materials.
Here’s a sphere with r.Lumen.ScreenProbeGather.TracingOctahedronResolution 4
On the right is the material preview. I’ve removed anything (normals etc) that could produce any fine noise.
And here with r.Lumen.ScreenProbeGather.TracingOctahedronResolution 24
Overall, the quality is a lot better. No weird splodges. Performance impact is ok. But we get this very fine noise, with lots of dark (almost black) dots.
During movement, this noise completely disappears, but once my camera is still, the noise appears.
Roughness on this mat is 0.5. In this case it’s a clear coat, but I’ve seen the same with non-clear coat, rough plastic materials. It’s not Lumen Reflections, as the mat is outside of my roughness threshold and the same issue appears without Lumen reflections.
On UE5.6 btw
Any hint what could cause this, or which parameter to use instead to impove GI quality? I don’t like the effect a low downsample factor produces (small splodges, instead of bigger ones).
Hmm, I think this has actually nothing to do with TracingOctahedronResolution. The effect is just more visible in darker areas.
Here’s another shot with a simple material. Unfortunately the noise is screen space. It scales when I zoom out and gets even more visible when viewing an object from further away.
Is it just an overall limitation of scenes with very little direct light?
Try increasing r.Lumen.ScreenProbeGather.FullResolutionJitterWidth.
Edit: I discovered there’s a barely documented feature of Lumen called Fast Update Mode which is basically exactly what I asked for here. It somehow determines where things are moving quickly and updates the lighting rapidly around them. The relevant cvars are:
r.Lumen.ScreenProbeGather.Temporal.FractionOfLightingMovingForFastUpdateMode
r.Lumen.ScreenProbeGather.Temporal.RelativeSpeedDifferenceToConsiderLightingMoving
r.Lumen.ScreenProbeGather.Temporal.MaxFastUpdateModeAmount
Note: Hit Lighting must be off for this to do anything at all.
Adjusting these will reduce or eliminate temporal smearing, but can also introduce a lot of flickering localized around your character while in motion. There’s even a Lumen visualization mode for it, but it seems broken.
Original post:
I have spent a lot of time experimenting with Lumen the past couple weeks, and I think I’ve got it just about tuned to perfection for my project. My major gripe with it feels like an old one: there’s just some very noticeable ghosting around moving characters.
There’s no TAA or TSR, it’s just Lumen itself. There are some vars to improve it but they come at the expense of flickering elsewhere, it’s just not very acceptable. And this is at higher framerates even (120); 60 fps is quite awful.
There must be a way to selectively update the parts of the screen where characters are moving more aggressively, or something like that. Whatever temporal smearing may exist in the environment is perfectly acceptable, it’s the character motion that’s a problem. It seems like it’s the problem point in most games with temporal issues. I think it’s both a big problem and a tightly bounded problem. Surely there is a solution to be made here?
Aside from that I’ll just share a couple of oddities I’ve come across.
As per this thread, in the lumen visualization it’s showing for me that lumen is tracing reflection rays against unlit materials in my scene.
Edit: apparently it was a bug and fixed for next release
The other thing I want to share is the r.Lumen.ScreenProbeGather.RadianceCache.ProbeResolution cvar has pretty wild and unpredictable results when you change it. I found that, subjectively, I liked the way it looked in some more shadowy areas when set to 100, though it’s a little expensive. But otherwise it seems like maybe it’s another case where it wants a power of 2 as setting it to values other than the defaults of 16 or 32, and maybe 64, either just look kind of different or very weird and dark.
Edit 2: Sorry for the long post but I think this deserves its own attention
Lumen has features like r.Lumen.ScreenProbeGather.Temporal.DistanceThreshold and r.Lumen.ScreenProbeGather.Temporal.RejectBasedOnNormal that do a pretty good job of rejecting GI light on top of the character from the screen probe gather temporal filter. What they don’t do is address the hole left behind the character in the screen probe gather, where light basically doesn’t accumulate due to it being a screenspace operation, leaving behind dark trails.
Apart from the Fast Update Mode, which is a welcome but imperfect workaround, I think a solution addressing the underlying issue here would be welcome. Could there be some way to selectively bypass certain indicated meshes in the depth pass, or something like this, so that the geometry behind them could accumulate light properly and not leave holes behind when they move?
1 Like
Doesn’t seem to make any difference. Weirdly enough the noise is unaffected by most variables. Temporal, Bilateral filtering, AA. Noise stays exactly the same.
I think in 5.6 only power of two values are allowed for TracingOctahedronResolution, but 16 leads to the same noise. Cutoff seems to be 10, with noise becoming stronger and stronger ramping from 10 to 16.
Can you explain briefly what the concern is with supporting SM5? My understanding is that GPU hardware has broadly supported SM6 for about 10 years. Are you only concerned for GPU hardware released before that time or is there some other reason for wanting to support SM5?
You’re right, there is pixel-sized noise in some of the shading with Lumen. It just seems to me to be part of how Lumen looks. Like you I haven’t seen it affected by any cvars. I’m kind of surprised it’s not filtered out like other elements of lumen are.
Edit: I wonder if this is intentional. It seems like they are sampling a noise pattern but did not reseed the noise every frame, which would cause it to vanish into the temporal filtering. Instead we get a static noise pattern.
FYI TracingOctahedronResolution can be any integer in 5.6 but in 5.7 it is indeed only set to powers of 2.