Lumen GI and Reflections feedback thread

[Krzysztof.N]

@Miguel1900

Please, remember the bug where multi bouncing reflections are not working in Lumen reflections + baked lighting. (Tested today on 5.4, still missing). This is the cornerstone for Lumen reflections being finally ready to work with baked lighting scenarios, which are still used/preferred by TONS of developers. (Not -only- for multibouncing mirrors, but a mirror reflecting a glossy floor near big windows, for example).

Thanks, wasn’t aware of that and just fixed. Though not sure how useful it will be for rough reflections due to noise.

For standalone Lumen reflections you can also enable r.Lumen.HardwareRayTracing.HitLighting.ReflectionCaptures 1 which will sample reflection captures at the last hit point, just like deprecated Ray Traced Reflections.

@Miguel1900

Add the option, cvar, material option, per object option, anything, to enable/disable emissive materials contributing to Lumen GI.

Like jblackwell wrote, this one is tricky as Lumen uses screen space traces for improving quality and screen space traces sample what you see on screen.

If you are fine with disabling screen space traces then you can use Ray Tracing Quality Switch Replace node to do custom material modifications for world space traces (Lumen Scene).

Alternative approach is to use r.Lumen.ScreenProbeGather.MaxRayIntensity and r.Lumen.Reflections.MaxRayIntensity to lower exposure relative energy limits. This will reduce noise, but will remove energy.

When reading your feedback it occurred to me that we could set max emissive limit by substracting emissive value from the final pixel color. Need to try it though to see if it can be useful for various use cases.

@Miguel1900

Reintroduce the variable “r.Lumen.HardwareRayTracing.MaxTranslucentSkipCount”. As an user pointed, it seems that the current value behaves erratically in some scenarios. Nevertheless, adding an extra variable doesn’t hurt and can provide more flexibility and optimization possibilities. I mean, “why not”?

It was removed because instead of retracing ray on a translucent hit r.Lumen.HardwareRayTracing.MaxTranslucentSkipCount times we now skip all translucent meshes. I’m not aware of any issues with it.

@Miguel1900

Increase the Lumen sampling headroom
Reduce dependency on temporal accumulation

Yes, our current approach doesn’t scale that well to offline rendering. Those are two big R&D topics for us and we are searching for an alternative approach for the high end PC use cases.

@BananableOffense

A per shading model toggle would honestly be good enough for most cases I think.

We already do this for skipping GI screen space ray hits on foliage (subsurface or thin two sided shading models). As you noticed it’s hard to generalize it though.

@Miguel1900

Why so much effort for current gen consoles, when they will become obsolete in not much time? (And not a lot of games will be released with UE5 before that date?). I think nobody would care about not using Lumen nor Nanite in current-gen consoles. Even more if using them requires some tradeoffs that users don’t want.

Likely current gen consoles are going to be the main visual target for games for next 5 years. Maybe even more - in the current generation only recently first games targeting PS5/XSX+ started to appear. So that’s a pretty important use case to solve well.

@Miguel1900

Was Lumen conceived as an scalable engine, to be able to evolve and cover the needs of trully next gen consoles and future PCs, in 5 years?

Yes, the idea was always to start from the consoles and then scale down and up. Likely it will be a mix of reusing existing Lumen parts and creating new ones as needed.