Lumen vs Static Lightmap indirect intensity mismatch in UE 5.8 (also 5.5)

Development Rendering
, ,
1

Expected Result

The indirect illumination (color bleeding) on the interior geometry should be consistent in intensity and distribution between Lumen’s real-time GI and the statically built lightmap. Both methods should produce a visually similar result, especially in a controlled test environment like a Cornell Box.

Actual Result

The indirect lighting intensity on the interior boxes is inconsistent. The baked lightmap produces a noticeably different intensity of color bleeding compared to Lumen’s real-time GI. This discrepancy can also be clearly seen when using the “Lighting Only” view mode.

[Image Removed]

The same issue has been reproduced on UE 5.5

[Image Removed]

[Attachment Removed]

2

Steps to Reproduce

  1. use project from Repro: https://github.com/gabrielcuvillier/ue5-parametric-cornell-box
  2. Open /Game/ParametricCornellBox/Maps/Showcase_2.Showcase_2 – observe Lumen GI (default).
  3. Enable Use Static Lighting in Project Settings.
  4. Select BP_CornellBox, set geometry & lights mobility to Static.
  5. Build lighting (Build > Build Lighting Only) – observe baked lightmap GI.
  6. Compare indirect color bleeding on inner boxes (use Lighting Only view).

[Attachment Removed]

3

Hello,

Lumen and static lighting are known to not produce identical results. We don’t currently have plans to work on static lighting or make the two approaches more visually similar.

Please let me know if you have additional question.

[Attachment Removed]

4

We are seeing quite noticeable transitions/popping when switching between the two lighting modes.

Do you intend to switch between the lighting modes at runtime? If so, what is the use-case? Normally matching these lighting methods are for scalability (matching low-end lighting with mid-upper lighting).

When trying to get the different methods to converge you could try using path tracer as the ground truth and adjust your static lighting and Lumen to get as close to that as possible, but there are differences in how path tracer treats sky and directional light which make that comparison not as useful for many common outdoor situations unless you only have local lights in your scene.

Could you help us understand what are the main factors causing the differences between Lumen and static lighting? For example, are there specific aspects of the GI calculation or assumptions that make their results fundamentally different?

Lumen and Lightmass use different scene representations. Lightmass traces actual triangles but stores the result at lightmap texel density, Lumen uses a surface cache which is a card/atlas approximation at limited resolution with compressed albedo, and with possible fallbacks for distant geometry . Enabling r.Lumen.HardwareRayTracing (default 1) means traversal against BVH triangles, and different r.Lumen.HardwareRayTracing.LightingMode settings will evaluate the materials and lighting on first hit (1) or surface cache (0), but secondary bounces always come from the surface cache. Lightmass bakes N discrete bounces (NumIndirectLightingBounces), Lumen produces bounces 2+ via Radiosity, which gathers with hemisphere probes onto surface-cache pages and writes back into the cache for later gathers to read which can lead to different weighting than Lightmass.

Lumen also clamps ray energy by default, in two places: r.Lumen.ScreenProbeGather.MaxRayIntensity (10.0) on the visible gather and r.LumenScene.Radiosity.MaxRayIntensity (40.0) on the cache update but Lightmass has no equivalent. Reference mode (r.Lumen.ScreenProbeGather.ReferenceMode) raises the screen-probe clamp and is a good way to confirm this is the cause. Lumen and Lightmass also have different non-physical albedo boosts, but I’m assuming you’re starting with a no boosting. There is also the consideration that AO will have because the two paths composite AO differently. Lumen adds indirect without applying AO to scene color, static lighting multiplies by AO so the contact darkening may differ.

Another thing worth mentioning regarding how the methods are being compared is that the “Lighting Only” visualization overrides materials for all bounces in Lumen and Path Tracer, but can’t do it for baked lighting without rebaking.

[Attachment Removed]

5

Thank you, Alex, for the detailed explanation.

The main issue we are trying to address is that we are using a hybrid lighting setup, where Lumen and static lighting are used together. We are seeing noticeable mismatches in the indirect lighting, which creates a significant amount of additional work when trying to make the two lighting methods visually align.

For our test case, we created a simple Cornell box–style scene consisting of two cubes with purely diffuse materials. For the Lightmass bake, we set Num Indirect Lighting Bounces to 2. Given how simple and controlled this setup is, we would expect the underlying GI approaches to produce relatively equivalent results, or at least to converge much more closely in terms of indirect lighting energy. The image below shows a comparison between the results from Lightmass, Lumen, and Path Tracing.

[Image Removed]

We have also included a Lighting Only comparison with the direct lighting removed. In the Path Tracing result, we are showing the indirect lighting contribution (i.e., excluding the camera-ray/direct contribution). The Lightmass indirect lighting is likewise the indirect component produced by the bake and shown in Lit mode.

[Image Removed]Given this simplified test case, we would be very interested in any additional insights you may have into the energy/brightness differences between these three approaches, particularly why the indirect lighting intensity may not converge even in such a simple diffuse-only setup.

The explanation regarding the different AO compositing between Lumen and static lighting is very useful and gives us a better understanding of one potential source of the visual differences. Any additional insights into the other factors that can cause differences in indirect lighting energy would also be extremely helpful for us, especially if there are particular settings or parameters we can adjust to better harmonize the results between Lightmass and Lumen.

Also, if there are any recommended approaches or settings for harmonizing Lightmass and Lumen when they need to be used together, we would greatly appreciate.

[Attachment Removed]

6

Would it be possible to send us this test scene in a vanilla UE project? There are many settings that could be effecting the lighting and having the scene and project settings would make it easier to verify what is going on in the images.

I realized you provided the test project above, but it defaults to no global illumination and without raytracing enabled - are there other CVARs or project settings that have been changed, and what scalability level you’re using in the editor?

[Attachment Removed]

7

I believe there are a couple of few things going on. The variety of lighting (rect, emissive, direct, spot etc) in the levels amplifies the differences, it would be better to focus on a simple scene first with a single box and a single light. Lumen surface cache represents diffuse albedo so specular is merged in like this (non-Substrate path used by the test project):

DiffuseColor  = BaseColor * (1 - Metallic);
SpecularColor = lerp(0.08 * Specular, BaseColor, Metallic);
EnvBRDFApproxFullyRough(DiffuseColor, SpecularColor);
...
DiffuseColor += SpecularColor;

There’s a comment in there that states:

The legacy path uses a different formulation for composition diffuse and specular color. This result in lighter albedoSo you should also test with Substrate enabled if you intend to use it in your project.

I found that by setting the specular and metallic properties of the materials to 0, that Lumen and Path Tracer providing much more similar energies, even with Lumen screen space traces enabled. Disabling Lumen screen space traces leads to much courser indirect lighting and darker AO because it’s just using the Surface Cache and probes. Also, the project I downloaded from the website defaulted to Shadow Maps instead of VSMs.

I do not recommend using the Lighting Only visualization for comparison. It doesn’t show the correct Static Lighting equivalent because it doesn’t replace the Materials/Textures. Also, there isn’t a direct Path Tracing comparison for that visualization.

In an effort to simplify the setup, I disabled the emissive rect, used a constant EV100 of 0.1, set specular and metallic to zero in the materials, and removed all geometry and lights except for a single CornellBox and rect light and was able to see closer results between Lumen and Path Tracing. The Light Mass results were darker and using more bounces and a slight boost got it closer to Path Tracing, but we don’t expect these methods to match completely given the scene representation differences, and the way the lighting information is stored and used.

[Image Removed]The main issue we are trying to address is that we are using a hybrid lighting setup, where Lumen and static lighting are used together.

How do you intend to use Lumen and static lighting together?

[Attachment Removed]

8

Lumen lite was introduced in 5.8 for the medium scalability setting, is more performant and the new default on platforms like Switch 2.

Lumen Lite delivers lighting that is up to twice as fast as Lumen High Quality, helping developers target 60 FPS on handheld devices and lower-end PCs while preserving artistic intent.Could that be performant enough for your lower end spec platforms and keep a more consistent lighting experience so you don’t have to use light maps?

[Attachment Removed]

9

Thanks Alex,

We are currently using a hybrid approach where Lumen and static lighting are both used, and we are seeing quite noticeable transitions/popping when switching between the two lighting modes.

Could you help us understand what are the main factors causing the differences between Lumen and static lighting? For example, are there specific aspects of the GI calculation or assumptions that make their results fundamentally different?

My understanding is that both approaches are essentially trying to approximate global illumination and, ideally, should converge toward the same ground truth result. If we can better understand where the differences come from, we may be able to find ways to mask or reduce the visual transitions on our side.

[Attachment Removed]

10

Thank you, Alex. I re-downloaded the project, and after opening it, ray tracing works. I checked my engine’s project diff and didn’t see any corresponding .ini file changes. I think the thing to check is the Path Tracing option under Project Settings -> Rendering -> Hardware Raytracing. Also, I’m using Cinematic settings for everything.

[Attachment Removed]

11

Thanks Alex, for this detailed explanation.

We use different scalability settings to switch between Lumen and Lightmaps. The main issue is that when artists switch between them, they can clearly see a difference in the overall lighting energy/brightness.

We have had to use various tricks to manually compensate for these differences so that the two modes look closer.

Our expectation is that Lumen and Lightmaps are two different ways of representing the same lighting, so we would expect the overall lighting energy to be reasonably consistent, even if the detailed implementations are diffenrent.

[Attachment Removed]

12

Thanks Alex for the introduction. This is definitely one of the things we are looking at.

I noticed that Lumen Lite is still in Beta, so I’m wondering when it is expected to become stable/production-ready.

Also, when testing it on the latest UE 5.8 version from GitHub, we noticed some flickering and visual artifacts with Lumen Lite in certain cases. Do you know if these are known issues, and whether they are expected to be fixed in future versions?​ [Image Removed]

[Attachment Removed]

13

Thanks Alex,

We also verified it. The Lightmap does come out somewhat darker than Lumen. But we found that when we set the light’s IndirectLightingIntensity to a very high value (30), the Lightmap actually appears brighter than Lumen. As shown in the image below.

We have already set both r.Lumen.ScreenProbeGather.MaxRayIntensity and r.LumenScene.Radiosity.MaxRayIntensity to a relatively high value (20000).

Could you help us understand why raising the light’s IndirectLightingIntensity ends up making the Lightmap brighter than Lumen?​ [Image Removed]

[Attachment Removed]

14

These artifacts are known and largely come from the lower radiance cache grid size and low probe resolution shadows on the probes.

If you turn on the r.Lumen.RadianceCache.Visualize 1 to see the probes you can see there are very few (by design because this is for low end).

[Image Removed]If you increase the grid resolution by raising r.Lumen.IrradianceFieldGather.GridResolution and/or lowering r.Lumen.IrradianceFieldGather.ClipmapWorldExtent you can get higher coverage of the area where the artifacts are. This is with r.Lumen.IrradianceFieldGather.GridResolution increased from 64 to 128 and r.Lumen.IrradianceFieldGather.ClipmapWorldExtent lowered from 5000 to 4000. As with any world aligned grid, most of the problem areas will be where geometry isn’t world aligned which is the case for most everything in this box.

[Image Removed]The other useful controls to know about are:

r.Lumen.IrradianceFieldGather.ProbeResolution and r.Lumen.IrradianceFieldGather.OcclusionProbeResolution to tweak probe resolution and r.Lumen.IrradianceFieldGather.ProbeOcclusionBias to bias along the normal and toward the viewer to reduce self-occlusion artifacts from Probe Occlusion . Increasing the resolution improves the accuracy but traces more rays, and adjusting the occlusion bias may fix artifacts in one area but cause them in others.

Using r.Lumen.IrradianceFieldGather.AdaptivePlacement in this scenario didn’t have much impact, but that might be improved in the future to better place probes.

You’ll want to test this with you real game content to see what kind of grid and probe resolution is needed to get the best results there to see if the quality vs. performance is acceptable.

[Attachment Removed]