Lumen GI and Reflections feedback thread

[jblackwell]

If you’re looking to boost diffuse lighting quality, then try ‘r.Lumen.ScreenProbeGather.ReferenceMode’. It strips away most of Lumen’s real-time optimizations and cranks up the sample count for diffuse lighting immensely, but it costs 7-8ms extra at 1080p, and it scales very badly. Use it if you need high-quality lighting, but it’s not a good setting to ship with.

TBH I find it pretty useful, ‘reference mode’ basically means matching the path-tracer, so you can get essentially as-good results in slightly less than real-time.

[ThinVeil]

Hope this is the proper place for this. I’m trying to create a mirror in UE5.
From what I have read and videos I have watched so for, it is difficult to do so.

I can get close with Lumen GI and Reflection, but I have some noise I just can’t seem to get rid of. On the Screen left is the post process settings I have cranked these settings up and they don’t seem to do too much after a certain amount.

Here are the Lumen views I know I have some surface cache issues, I don’t think that is the casue of the noise

EDIT: I forgot to show this. with Lumen GI and Reflection if I look at the mirror at an angle the artifacts disappear. Not sure why, but wish I could get that result facing the mirror.

Then I thought well maybe I can mix Lumen GI and ray trace reflection, but with ray trace reflections it doesn’t seem to show bounced lighting. Even if I do ray traced GI and reflections

.
Is this something that’s just not possible in 5.02? Should I just do Lumen GI and planar reflections to achieve a mirror?

[jblackwell]

Lumen reflections are more limited in some ways than standalone RT reflections, and quality is currently one of them.

To begin, the reason the artifacts dissapear when you look crossways to the mirror is because of lumen’s screen traces: basically, lumen uses a high-quality version of screen-space reflections as the first tracing method, and the detail problems go away because it’s reflecting exactly what’s on screen, and not the lower-fidelity lumen scene.

If the reflected area isn’t visible in screen-space, then lumen falls back to ray-tracing the ‘lumen scene’, a lower-res version of the world that’s cheaper to trace against. Lumen GI is high-quality for the first bounce and then uses faster methods for subsequent bounces, which is why the reflection of the scene lighting is so low-res. It doesn’t explain what the dots are, they don’t look like noise as much as a glitch in the surface cache’s scene parameterization.

Most of your settings are red-lined already, but I’ve noticed that lumen scene quality tends to max out at 8, so you could get a bit more quality if you wanted. Enabling hit lighting allows for highest quality as well, and lumen reflection quality scales up to 8 too, if you’d like to increase it. I’m assuming you’re using hardware RT with all of these settings.

Standalone RT reflections aren’t aware of lumen GI, so you’ll get a very strong lighting discontinuity. Planar reflections are very expensive and they have strange support limitations, and I’m quite frankly not even certain they’ll work with lumen. My recommendation, if your content allows it, is to use baked lighting and standalone RT reflections-it’ll pick up on GI, you can set the spp count to whatever you need for highest quality, and it supports multiple bounces.

[jasonfong1986]

Hi, I’m running into some weird lumen lighting issue when camera angle change. As shown in the video, the wall will be lit when camera angle can’t see the corner. As well as the white Ikea shelf will be lit if camera angle can’t see the wall behind it.

[ThinVeil]

Thanks Jblackwell!

I started playing with just baking and using Standalone RT reflections and it is getting me results that I am looking for. It’s not the ideal scenario because I REALLY wanted that dynamic GI in reflections, that looks clean.

I hope Lumen can resolve this with later versions of 5.0.

[jblackwell]

Happy to help if I can, lumen gave me enough headaches and I’m happy if I can help others avoid it. Especially happy you’re seeing what you need.

I really do hear what you mean, dynamic GI in the primary view looks amazing but it totally breaks down with reflections. I read a note from one of the devs that they’re looking to enable hit lighting options for every trace behavior with lumen, which would essentially forgo the surface cache entirely and access the high-quality GI we want directly. Unfortunately, I checked UE5_main, and from the way things are developing it doesn’t look like that’ll be on the table for 5.1.

If github’s any indication (and it very well may not be), we’re looking at substantial performance improvements for lumen, support for full lumen reflections on translucency and SLW, improved reflections filtering, better foliage and shading model support, and more. I’m very excited, not to mention Nanite working with WPO and masked materials, I’ve tried it out and it’s already super cool. Good luck with your project!

[Miguel1900]

But be carefull, because they have broken the RT reflections, as you can see here. In some certain situations, it’s easily noticeable:

What's this trail around objects? (RT reflections issue in UE5)

I have been testing Ray Tracing VS Lumen on UE5.0.1. When using RT, I notice some trails or ghosting around some objects. Also noticed it on a different project before (with UE5 too). Oh, and it comes from a 4.27 project, where worked perfectly, and just migrated to UE5, to compare. What can it be? [ue5 ghosting.PNG] Thanks!

[jblackwell]

Huh, that’s interesting. I wasn’t aware of that being a problem, but I know Epic just adjusted the temporal filter on lumen reflections to be more responsive, so I wonder what things will look like in the future. I’m aware RT reflections are technically deprecated, but lumen simply can’t support the same level of quality or feature set, at least in arbitrary cases. When lumen reflections can support multiple bounces, I’ll be very happy.

[jasonfong1986]

@jasonfong1986

Hi, I’m running into some weird lumen lighting issue when camera angle change. As shown in the video,

After some investigation, I find the weird indirect light are actually result from “Detail Trace” which is the result of tracing against the “Mesh Distance Field”.

However when I turn on the “Mesh Distance Field” view, all those walls and shelf are having enough distance field resolution.

How to fix it…?!

[BananableOffense]

Use the Lumen Scene View to inspect. This will color code potentially problematic geometry.

[jblackwell]

I’d also consider disabling screen traces via ‘lumen_screenprobegather_screentraces’. It’s often the culprit behind strange lighting discontinuities from my observation.

[gulopbr]

Is there a possibility in the future for low powered devices have at least some limited Nanite support, such as mobile devices?

[dpotuznik]

hi everyone,

i found this CVar to improve GI Quality
r.Lumen.ScreenProbeGather.SpatialFilterNumPasses = “3”
by default is 3 :

with 32:
r.Lumen.ScreenProbeGather.SpatialFilterNumPasses = “32”

i use for rendering not in real time game , but may be it can be used

have a nice day

[jblackwell]

Do you mean Nanite, the geometry rendering system, or are you talking about lumen? If the former, this is not the thread for that topic, I believe Nanite may have a dedicated thread.

For Lumen, the dev team has said essentially…no. It’s just too expensive at the moment, and it would burn through power too fast. Although, ‘mobile’ is kind of an interesting distinction at this point, ranging from a mid-range smartphone from a few years ago all the way up to a device like the steam deck, which is even capable of ray-tracing.

There’s nothing saying it couldn’t be possible, but it certainly isn’t scalable at the moment.

[dampflokfreund]

HW and SW Lumen should perform pretty similar. If you get such a frame drop from HW-Lumen, then its possible you have a lot of overlapping meshes that need to be optimized. If you look for faster real time GI, then I can recommend RTXGI which works well on AMD too.

[Farshid]

Panorama in Movie render queue is not working with lumen
Also does not has path tracing option

[jblackwell]

Have you worked with RTXGI in production cases? I’ve experimented with it somewhat (I was mainly interested in trying out NVRTX’s caustics features), and I generally found it to be more prone to light-leaking then lumen. Not to mention the need to set up manual probe volumes.

Also, doesn’t RTXGI suffer from the same BVH complexity problems that bring HW lumen with overlapping messages to a halt? Just curious.

[Rawalanche]

I know this may be a bit far fetched, but I wonder if it would be technically possible to bake Lumen into lightmaps.

Lumen provides great realtime preview workflow, unlike CPU/GPU lightmass, where you need to wait couple of dozen minutes to see the result. Non the less:

• Lumen doesn’t scale down to mobile
• Can be too expensive for certain scenarios/target hardware
• Sometimes you don’t need GI to be dynamic, so you may be wasting performance

The idea of being able to click a button and have the Lumen illumination pretty much dumped into lightmap textures much faster than GPU/CPU LM could, yet with not that much worse quality would be a great proposition.

And volumetric lightmap could work as well, since Lumen is essentially a volumetric lightmap, just a dynamic one.

So the idea of switching GI scalability to cinematic and rendering both surface and volumetric lightmaps using lumen sounds really nice to me.

I know lumen does lots of stuff in screen space, so I am not sure how feasible would be to perform those in the UV texture space, but if that would be possible, I’d love that option.

Current workflow with GPU/CPU Lightmass is to tinker with the settings, start light build, cross your fingers, wait for quite significant amount of time, get most likely bad result, tinker with some more settings and repeat.

With Lumen baking, the workflow could be: I see what I am getting, I like it, so when I press the button, that’s what I will get, just in the lightmap textures. The only uncertainty about the output quality left to be concerned about would be lightmap UVs and resolutions on your meshes.

[jblackwell]

I believe the Lumen team issued an answer to a similar sort of question as yours last year. Obviously lumen has evolved massively on a technical level, but their answer still generally seems to track with the technological development: Lumen | Inside Unreal - YouTube

[jblackwell]

It’s an interesting idea that you posit, certainty, and it does offer many of the use cases where lumen is impractical.

As the stream elaborates at 1:57:24, lumen operating on screen-space means it doesn’t pick up on many of the UV seams or other errors and artifacts lightmass might miss. It also makes lumen lighting different, as it operates on screen pixels (and lumen scene texels), and concepts like lightmap resolution don’t exactly translate to method either.

I don’t work with baked lighting often as part of my workflow, but I’ve experimented with GPU lightmass before and generally found it to be very fast, especially on the ‘bake what you see’ mode (granted, I have an RTX card).

Volumetric lightmaps are an extremely interesting question as well, especially given how lumen handles translucency and particle lighting. I do believe lumen has a translucency grid in concert with the distant probes system, so while what you’re suggesting certainty isn’t out of the question, I personally don’t an easy path to integrating the systems with lightmass.

Of course, you are correct: lumen doesn’t scale down to mobile, and it creates some strong performance limitations. However, lumen can scale down to DFAO and SSGI, which are mobile supported features. Not to mention experimental methods such as lumen’s irradiance fields. It’ll be interesting to see how the pipeline matures and support evolves.