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
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.
6 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?
2 Likes
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.
HISMs do not appear to work correctly with Lumen. ISMs are fine.
With HISMs apparently you need to enable Nanite for them to work with Lumen at all (why?), but even if you do, they will receive indirect lighting but won’t bounce any of it into the scene.
I found a post from 2022 describing the same issue.
Are those non-Nanite meshes? non-Nanite ISM are disabled for performance reasons.
It looks like I made a mistake in my testing. There seems to be an odd quirk with the editor that LOD settings in the static mesh asset window can only be applied by closing the window (is this right?). So I didn’t fully enable Nanite on all of the relevant meshes.
What’s actually happening: Lumen works fine with both ISMs and HISMs, but HISMs only if you enable Nanite.
That’s better than I thought, but still, why require Nanite? Using Nanite and HISMs together feels a bit redundant, and naturally not everyone wants to use Nanite in their project. My project loses a little over 10% performance using HISMs with Nanite vs using ISMs, and I expect most or all of that is from Nanite.
We’ve run into a few projects with complex HISM foliage where Lumen surface cache capture was crazy expensive so we disabled it by default. Most projects which use Lumen also use Nanite for everything so it’s not a big deal in practice.
They’re (supposed to be) applied by pressing the “apply changes” button. You might think pressing the save button would apply the settings but you would be wrong. You might also think the apply button would be in the toolbar like every other editor window, but you’d be wrong again because the static mesh editor doesn’t care what is “logical” or “consistent”… so instead there are FOUR different apply buttons in the details panel.
As for whether or not it’s right… well… I don’t know if it’s “right”, but this is how it’s always been.
1 Like