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?