Lumen GI and Reflections feedback thread

hmm, thinkint about it, it makese sense - but only if you have dedicated RT hardware (that doesnt suck… cough AMD cough)

Of course, with Software Lumen the shaders are used for the calculations, but with RT-Lumen the otherwise unused RT-Hardware should be used.

On my 6900XT though, I lose 30% of my FPS when using Raytraced Lumen, but meh, guess I will just put the option in.

PS: I was still thinking about the old RT-GI, which is unused now, and performed a lot worse, my bad.

Lots of discussion about the performance issue. I understand I mentioned this in the post, what Im really trying to solve first is the quality of the image and how to get my subtle details back that existed in UE4 and in the PBR roughness and metalic portions of my texture. Whys is all the detail getting blown away and how can I fix it? thought pointers or places to look would help.

1 Like

If you’re referring to losing fine detail in rough specular reflections, then I can answer that:

Lumen image quality works well for near-specular and near-lambertian surfaces, so if a material is either perfectly reflective or diffuse, it resolves really neatly. For surfaces in between (around .4 or so), lumen can’t denoise those rays effectively, so it tends to either clamp that fine detail away (which may be what you mean), or it gets really noisy.

There’s a command that lets you adjust the threshold that the fake rough reflections kick in, ‘r.Lumen.Reflections.MaxRoughnessToTrace’, and give it the value you want lumen reflections to trace against (E.G, giving it ‘1’ will mean it will trace rays against totally rough surfaces and basically disables it entirely.

Unfortunately, there’s no real solution for the noise that I know of. Beyond just cranking up the reflections quality in the PP volume, Lumen’s current reflections solution basically can’t handle those surfaces without either biasing or noise, so short of looking to art direct around them, you could always use the path-tracer.

1 Like

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.

1 Like

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?

1 Like

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.


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.

1 Like

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.

1 Like

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. :slight_smile:

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!

1 Like

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


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.

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…?!

1 Like

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

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

1 Like

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

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 :slight_smile:

have a nice day


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.

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.

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

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.