Critical Lumen Instability in UE5.6: Artistic Control Severely Impacted

[Jhosep_Chevarria]

Hi Unreal Engine community, I have a big issue issue with Lumen. This is a core issue in Unreal 5.6. Migrating, creating a new project, or cloning the project with the exact same settings won’t fix it. I tried using lots of CVars to see if the issue could be solved, but no, Lumen behaves completely differently in Unreal 5.6. The default values are good and look almost the same as in previous versions, but if we tweak them even slightly, Lumen behaves in a completely different way (huge issue for devs aiming for a more artistic route).

Broken in Unreal 5.6:

• Diffuse Color Boost (advanced Lumen setting) is broken. It also boosts directional light, completely breaking the scene (whether new, cloned, or migrated). Importantly, it breaks car reflections and building materials, and even scenes with less sunlight, like alleys.
• The way Lumen handles color bounces, including Surface Cache and Hit Lighting has changed. There’s a new CVar (which I don’t fully understand) that seems to play a role. Its default is 8, but changing it to 0 slightly mitigates the color issue. However, the problem with Diffuse color boost (regardless of method) persists, but only in Lumen scenes.

CVar in question:
r.Lumen.CachedLightingPreExposure 8 (default)
r.Lumen.CachedLightingPreExposure 0 will reduce color issues a bit.

Comparison: 5.5 vs 5.6, cloned project, exact same settings (Hit lighting, looks the same with surface cache), Diffuse color boost value = 4:

Left, UE5.5, Right, UE5.6:

Broken reflections (directional light and other lights are also boosted):

Huge color problem with Lumen using diffuse color boost (value 4)

Comparison and how they look normally.

I’m surprised no one spotted this except a previous post, this is huge for artists, default values, as I said, are ok, but changing something from Lumen (lights or post process) will fully break the scene.

Easy to reproduce: add a post process volume to any default scene, add a vehicle or colorful asset, and increase diffuse color boost, all the Lumen issues will appear.

[Jhosep_Chevarria]

Another test, this time a bit more extreme but simple, this time with no diffuse color boost or any post process setting, default lighting (low sun), using default basic template settings, empty project (engine assets):

Top: Lumen scene
Bottom: Detail Lighting

Test 2, No hardware ray tracing:

[IronicParadox]

Diffuse color boost is on the material calculation, not the light. The rays are just bouncing around more accurately now and distributing their energy around the scene better. The equation for color boost is simple: Color ^ (1/Boost). If you go too high in boost, like using four for instance, you’re going to blow things out extremely badly by raising something to the power of 0.25(fourth root). A value of 0.5 becomes 0.84. Even the documentation recommends avoiding going above 2 because “It works best to keep the value below 2 as it also causes reflections to be brighter than the scene.”

Other than the exaggerated second image with color boost 4, it all of the images in your two posts look far more accurate in the 5.6 versions, in terms of the light energy levels being bounced around, but again, you’re driving the boost too high and causing some ugly discolorations like in the narrow corridor shots in the second post… In instances like these, you need to lean more into exposure tweaking, rather than trying to artificially color boost things.

[Jhosep_Chevarria]

We can achieve diffuse color boost through material calculations, there are indirect methods (not a direct setting), which work well for color bleeding. However, the Lumen diffuse color boost (correct me if I’m wrong) derives its effect from the scene color captured via ray tracing or distance fields, not the materials themselves. In Unreal 5.6, it appears to also amplify direct lighting and other non-material sources, which shouldn’t be influenced by material-side calculations.

Moreover, material calculations alone shouldn’t introduce the color noise issues seen in 5.6. The problem isn’t with the equation itself unless the equation was incorrect in 5.5 and earlier versions.

Yes, the documentation has long advised against using values above 2, but this recommendation has been around since 5.1. I don’t believe 5.6 suddenly makes that guidance newly relevant or justifies the behavioral shift we’re seeing. In fact, even values as low as 1.2 can break a scene now. So the argument that “you’re just using it wrong” falls apart when identical values behave differently across versions.

Additionally, the suggestion to “just tweak exposure” entirely misses the point. You’re not trying to correct a photometric imbalance. You’re deliberately exploring artistic lighting paths that require nuanced bounce control. Exposure tweaks cannot replicate that level of intent.

It’s not just about photometric correctness. It’s about the posterization, oversaturated color bleeding, and low-light breakdown Lumen exhibits in 5.6. These issues weren’t present in 5.5 or prior versions. Yes, there are workarounds, and these problems may go unnoticed in well-lit or default scenarios, but they severely restrict creative direction when exploring non-standard or mood-driven lighting.

Also, in my second set of screenshots (Second Post), I’m not using any post-process settings. This is Lumen in its raw form.

[IronicParadox]

@Jhosep_Chevarria

Lumen diffuse color boost

Even if you’re doing this on the Lumen side of things, it’s still going to use similar exponential math and still going to be prone the same problems as what I said in my previous post.

Here are are the only updates to the Lumen implementation that was introduced in November 2024:

April 15th, commit ea535de:

“Lighting Only View Mode - override materials for all bounces in Lumen and Path Tracer. Having this only on primary rays made it akward to investigate lighting as it unbalances direct and indirect lighting. This is also what lighting artists prefer.”

April 30th, commit 5fac3c0:

DiffuseColor = min(saturate(DiffuseColor * (DiffuseLumBoost / max(DiffuseLum, 1e-8f))), 0.99f);
(they added the max(DiffuseLum, 1e-8f) check so that it can’t divide by zero).

What you’re probably seeing are the changes to the lighting only view mode. You could test this pretty easily by making a backup copy(store it on your desktop our somewhere outside of the UE folder structure to play it safe) of the LumenDiffuseColorBoost.ush shader file and commenting out the DiffuseColor = DiffuseColor.rgb * View.DiffuseOverrideParameter.w + View.DiffuseOverrideParameter.xyz; line with // , then relaunch the editor to recompile shaders and test again. You might also have to edit out the two lines that changed in the same commit in PathTracingCore.ush, if you’re testing with path tracing.

Also, if you went back to UE5.5 and added that line to the same file, you’d likely see similar results in your testing (5.6 still has much more accurate lighting, so they’d still differ to some degree)

[Jhosep_Chevarria]

Just to clarify, this isn’t an issue caused by Diffuse Color Boost itself. That feature is simply amplifying underlying issues that already exist in Lumen as of 5.6.

This isn’t about view modes or debug overrides either. It persists in runtime, in clean projects, even with post-processing off. My point is that the underlying lighting behavior in Lumen has changed, and Diffuse Color Boost is just the mechanism that makes those regressions clearly visible.

Thanks for pointing out those commits,really appreciate you taking the time to dig through the changelog. I’ll take a closer look myself,see if anything else stands out and do my testings.
That said, I still think the main issue here goes deeper than those updates. While the shader and view mode changes are interesting (especially for debugging), they don’t fully explain the regressions I’m seeing, particularly how Lumen now handles low light, bounce color fidelity, and exposure caching. Diffuse Color Boost just happens to reveal those flaws more clearly.

New test, now comparing with Path tracing from Unreal 5.6 (Path tracing looks the same, no changes detected).

Left: UE5.6 Path tracing, Center: UE5.5 Lit mode, Right: UE5.6 Lit mode. No post process, no changes, no diffuse color boost, everything set to default, clean projects.

[IronicParadox]

@Jhosep_Chevarria

Left: UE5.6 Path tracing, Center: UE5.5 Lit mode, Right: UE5.6 Lit mode. No post process, no changes, no diffuse color boost, everything set to default, clean projects.

Show the material for the objects, since that’s what actually handles what color lighting is being bounced around due to energy conservation math and so on.

What are the light properties? Like is it using color temp to pick the color?

Also, are you using SWRT or HWRT for Lumen?

[Jhosep_Chevarria]

Thanks for the follow-up. Just to clarify:

Material: I’m using the default Unreal Engine Basic Shape material, nothing custom or modified.

In this specific context, showing the material wouldn’t clarify much, it’s already a known and neutral component.

Lighting setup: Everything is from the default template map, with no manual overrides to color temp, indirect intensity, or advanced light settings.
Light rotation is the only change, purely for mood variation:
Pitch = -6.545278, Yaw = 176.658151, Roll = 112.360672
This simply creates a low-angle sun for soft shadows. No other light properties were changed.
Post-processing: Disabled. The screenshots (except my first post) reflect raw Lumen output.

I’m keeping everything simple and reproducible to isolate what I believe is a Lumen-specific lighting shift between 5.5 and 5.6.

The mention of energy conservation and bounce color logic applies when testing custom shaders or albedo tweaks, but that’s not the case here.

Everything is default, engine Basic Shape material, default template lighting, no post-process, no exposure tweaks, same project config across UE5.5 and 5.6. Only light rotation was adjusted to simulate low sun. I’ve framed a clean, controlled comparison that makes the regression in Lumen’s behavior undeniable.

SWRT and HWRT comparisons

Left: UE5.6, Right: UE5.5

Path tracing, for reference:

[IronicParadox]

@Jhosep_Chevarria

Light rotation is the only change, purely for mood variation:
Pitch = -6.545278, Yaw = 176.658151, Roll = 112.360672

So the lighting is very warm then and close to the horizon, which is warned against for lighting and shadowing since it can lead to very long traces.

@Jhosep_Chevarria

The mention of energy conservation and bounce color logic applies when testing custom shaders or albedo tweaks, but that’s not the case here.

No, the rays start out with an energy and color, hit a surface and based on that surface, an amount of that energy is removed, some amount of the ray’s color is imparted onto the surface and some of the sufrace’s color get’s picked up by the ray that then goes on to hit other surfaces, rinse and repeat until the ray is either out of energy or reaches some maximum trace distance.

I mocked up a default level with the same adjustments to the sun angle and roughly the same scene composition. Here are the results:

Oh and my Lumen scene views are always broken with a bunch of black static TV horizontal noise stripes everywhere, don’t know why, but maybe I need to repair the engine or something. Might also be be an AMD GPU or driver issue though.

Also, nothing is non-uniformly scaled either. A segment of wall was made with the cubegrid tool and then duplicated for the other side and the top. The cube on the left is just a cube uniformly scaled up to plug light from coming in the back. Obviously, there is some light leaking since the walls and ceiling share the same edge there, but I left it there to try to introduce artifacts and noise.

[Krzysztof.N]

Hi,

In 5.6 there were a few changes, which could be responsible for those changes:

• Indirect lighting intensity and diffuse color boost now also affect hit-lighting. People were complaining that when enabling full hit-lighting those controls didn’t do anything, so we fixed that. But if you used hit-lighting only for reflections then those controls only affected GI. I think we need to fix this and makes those controls only affect non reflection rays, so that it works in a more expected way
• We tweaked a bit diffuse color boost equation, so that it now leaves value/saturation intact and only boosts luminance. As otherwise all boosted materials were just becoming white
• Shifted cached lighting range, so that it’s possible now to use realistic lighting values without clamping indirect lighting (loosing indirect bounce). Range was now shifted, so that you can use [-4;24] EV exposure values. You can set it back to previous state by using r.Lumen.CachedLightingPreExposure 0 and r.SkyLight.RealTimeReflectionCapture.PreExposure 0

With default indirect lighting intensity, diffuse color boost and those CVars set to 0 I expect that 5.6 will generate the same image as 5.5 here.

[Jhosep_Chevarria]

Hi @Krzysztof.N Thanks for the info.

• It’d be great if those controls could affect only non-reflection rays, keeping them isolated will be useful for tuning GI without impacting reflections or direct lighting. A toggle or CVar for this would really help maintain flexibility.

• Makes sense to avoid washed-out whites when cranking values. Thanks for the clarification.

• Using the proposed CVars made the bounce behavior much closer to what I saw in 5.5 so this change definitely plays a role in the visual shift.

Thanks for taking the time to look into this, appreciate the insight, and I really hope the fix makes it in.