Lumen GI and Reflections feedback thread

I don’t think pre-cache has anything to do with these glitches. Problem is not that lightning is not being cached, problem is that lightning is being calculated wrongly. Lumen already has surface cache’s (cards). Something is causing lightning to update even though it should not be updated. So we are looking at a bug, not a drawback of technology.

yeah, this doesnt look like “missing” cache or so, lumen actively “deletes” its lighting information for a period of time and fails to recreate it.

Idk, need to do more investigations on this, kinda hard to track down.

Surface cache for ISM/HISM without Nanite meshes isn’t supported currently, but should work with Nanite meshes or when using HWRT highest settings which bypass surface cache entirely

Do you mean “RayTracingQualitySwitchReplace”? This one is implemented in UE5-Main, but is mostly intended for optimizations. Using it for artistic tweaks has the same issues as tweaking IndirectLightingIntensity. Namely it can’t affect screen space rays. This means that any harsh differences between “GI material” and what’s on screen will cause view dependent GI, and lighting will shift as you move your camera around.

Unfortunately Landscape isn’t currently supported :/. You could make a temporary hack by placing some meshes under the landscape so Lumen can pick them up.

Yes, this is a pretty important topic for us.

Regarding various quality issues:

  • Reflections are bad - at the moment only Hardware Ray Tracing can deliver great looking mirror reflections
  • Lumen looks bad - most likely it’s caused by using software ray tracing with large (non modular) meshes. Please try checking how the scene looks like in distance field and Lumen scene visualization to figure out which objects may cause it and are not correctly represented. Lumen Technical Details | Unreal Engine Documentation

No promises, but if anyone shares a small project with issues I’ll try to investigate what’s happening there.

1 Like

No, I actually meant GIReplace. The purpose is not so much of artistic tweaks, but rather to strip material of anything, that interferences with card baking. Fancy time-based panning textures, provided that they have some variance in em, cause perceivable discrepancy between surface cache and screen.

I’m not familiar with GIReplace. Could you explain what it is?

As for changing material between raster and cache, you could use RayTracingQualitySwitchReplace (support added in UE5-Main). It’s true that it also influences HWRT when surface cache is disabled, but the dream is that cache should be just a cache, and shouldn’t require any special material tinkering to make it work.

Did some more experiments and found out, that these issues do not appear in the editor as frequently.

often, where Lumen breaks in the cooked game, it still works fine in editor.

I already removed trees because I thought they had an effect, but no.

Packaged game (on that location, Lumen works just fine):

…moving forward 1m, and suddenly it breaks:

In Editor: same location as in the “broken” image above, it works (some differences in light, because some stuff isnt enabled in the editor.):

Pretty much all meshes in there are Nanite (Except stuff that contains translucency/masked stuff), largest ones are 4x8m, smallest ones are like 10x10cm. (the colored walls are ISMs, the same goes for the randomly generated metal-walls, but still nanite meshes.)

Mesh Distance Fields:

Lumen Visualization (when it works):

Here is what MDF and Lumen look like when Lumen breaks:

So, MDFs are fine, Lumen not so much.

I also noticed, that I can make lumen generate the GI by just randomly clicking on meshes, and it works as long as I click on something. (As soon as I stop clicking, the GI gets slowly removed again.)

So, I would say that the Scene/meshes etc. are fine, but under certain conditions lumen just stops updating its stuff properly.

Video of what is described above:

This clearly shows that lumen is capable of generating GI for the scene just fine, but “decides” to not do so unless i constantly click around. I also dont see any other obvious mistakes on my end.


Restarted again, but now the same scene that was broken previously, does work like it should:

Now going to try if this location will break in the packaged game again.

EDIT: yes, partially breaks:

At this point, I am very sure that this is an issue with Lumen, since it shouldnt calculate different results in the same scene.

All I did was to package the game, I didnt touch anything - and thats enough to make it break.

Also, the other spot where it breaks moved down the hallway a bit, randomly, without me touching anything there at all.

UMaterialExpressionGIReplace, switches(or used to switch at some point) material networks for lightmass.

Nice! Though, having explict control over surface cache only here would still be beneficial, in my humble opinion.

I do have one question about Lumen. What would be the strategy to make it work in a scene, where most of components make one huge moving object? So far, Lumen’s diffuse system fails to work there at all. Voxel clipmap constantly updates and aliases significantly. Same for irradiance field etc.

It seems Directional light, Indirect Lighting Intensity slider stops working/or gets clamped to 1 when using physical light values.

Here is a screenshot with normal manual exposure settings and lightning values:

Directional light:
Intensity - 11 lux
Indirect Lighting Intensity - 10 (I am using exaggerated value for you guys to see the difference)

Thats how it looks with Indirect Lighting Intensity on 1:

PPV - Manual exposure:
Exposure Compensation - 0
Apply physical camera exposure - OFF

The overall illuminance on the scene is 9 ish lux.

But if I go for physical based lightning values and camera exposure values:

Directional light:
Intensity = 110000 lux
Indirect Lighting Intensity - 10 - Notice how the exaggerated GI disappeared, like the value is clamped to 1 now.

PPV - Manual exposure:
Exposure Compensation - 0
Apply physical camera exposure - ON
Shutter speed - 125
ISO - 100
Aperture(F-Stop) - 14

The overall illuminance on the scene now is at my target which is - 109k lux.

So it seems to me that GI intensity doesnt work if you use real light values on directional light.

Can anybody confirm that this not an intended result by using physical light values and camera exposure? :slight_smile:

First of all: Thanks for all your work and your efforts!!!

Here is my issue with Lumen: It does NOT work on M1 macs. Is there a roadmap, when this mainfeature will come to these powerful machines as well? Cause right now, UE5 can‘t be used on a Mac like it is supposed too.

I feel like calling an integrated graphics card based system a “powerful machine” is a bit of a stretch.
The high end M1 has about 10% of the GPU performance in TFLOPs of a RTX 3070.
And on my RTX 3070 Lumen runs well, but not always perfectly smoothly.
So with 90% less GPU power I wouldn’t get my hopes up, if I were you.
Don’t get me wrong, I don’t have anything against Apple, or Macs, but you have to at least consider the numbers here.


I’m encountering some wildly unstable lighting, where the color/intensity has extreme fluctuations depending on the position/direction of the camera.

I like the new sparse distance field approach with its 3 level of detail/redirections table. Distance field on my planets ground never looked that good!

Overall i believe the DF/Surface cache approach to be really elegant, performant and delivering great results.


This the same issue that I (and many others) found, and also have seen plenty of times in the forums now, reported by many people (even outside of this thread).

Doesnt seem to be difficult to replicate then, given how many people found it, so I would expect it to get fixed sooner or later.

Hi, i have recently been updating some projects from UE4 to UE5 and decided to give Lumen a try - to see how it works etc. One thing I have noticed when I create all my sequences is that they start black and fade in. Whilst this is often a useful option it is something i would normally do in post - is there a way to remove this feature/effect?

Many thanks


Do you have auto-exposure enabled in your PPV/project settings?

[I publish my observation again since the previous one did not see the video].
With “Lumen Reflections” (quality 4.0) I found some bizarre reflections. The statue is a Nanite Mesh, the chair is not a Nanite Mesh. It seems that the Distance Fields are reflected but also the “Lit” scene depending on the inclination of the camera with respect to the reflecting surface.

That’s due to the distance field tracing switching from “detail” which is per object to “global” which is less detailed.

I find it a really odd choice to have a single, hard cutoff between the two for reflections, as it creates this really obvious artifact. Would love to see rays start tracing back into the detail per object distance meshes once they’re close enough “inside” the solid areas of the global distance field, as then you’d know you’re close to hitting a detail mesh anyway. Would be nice as an option.

Also options for a higher resolution for the global distance mesh, maybe get a smooth transition, or at least one as smooth as possible, to less and less detail.

1 Like

Finally got around to doing some tests with Lumen in UE5 tonight - Type of light displayed on top-left corner.


I am also experiencing this same issue. The overall brightness of my scene “pulses” as I move the character around the scene. I tried turning auto exposure off and on with no luck. It appears to be linked to the Skylight. If I kill the skylight it goes away. I’ve tried tuning the settings of the skylight but can never get the pulsing effect to go away completely. Please fix epic! :slight_smile:

I did some quick tests with an empty scene and some interior assets. The pulsating effect seems to be related to Directional Lights, Spot Lights and Sky Lights. Rect Light and Point light don’t seem to produce this bug, the lighting, GI / reflections and shadowing are stable and relatively clean.