Lumen GI and PBR values

Development Rendering
, ,
1

We’re exploring an issue with Lumen GI in locations like tunnels and bigger darker interiors.

[Image Removed]

When entering interiors Lumen scene is noisy and updates very slow, in dark interiors there are a lot of artefact caused by the high lighting intensity, fog also appears to catch these values and looks brighter than the scene intensity. The slow update is more noticeable when entering the ‘’interior’’ with a fast moving camera. The options in the Post Processing Volume Lumen GI settings are not helping, also sky leaking isn’t an option as it adds high intensity and makes the local lights not visible, but also flattened the scene.

Lighting is set close to PBR values with average EV 12 (exterior). Sun intensity is 22K, skylight/HDRi reads from the sky atmosphere illuminance. Lumen is using default settings, no ray tracing. Geometry is split to pieces and Nanite. UE 5.54

[Image Removed]

There is a post processing volume in the tunnel just to reduce the bloom and lens flare. Fog is off in most of the videos but the one in the entrance to show case the GI leak in the volumetric fog.

Video: Tunnel_PBR_01 - it’s a 180m long tunnel with moving camera.

Video: Tunnel_PBR_03 – same tunnel but faster moving camera where we can see the slow GI update.

Video: Tunnel_PBR_02 – it’s very long tunnel, end of the geometry is outside of the GDF range.

Video: Entrance_PBR_01a – 100 m long tunnel with a curve is going to same size room, high contrast on the entrance, them splotchy artefacts before the GI slowly update and fade to black, the noise is moving based on the camera position.

Enrance_Fog_PBR_02 – same interior but with the fog ON.

We did try with very low (non PBR) values and GI looks stable no artifacts (or at least not visible), Sun intensity is set to 160 Lux, average EV 4.5 (exterior).

Video: Tunnel_nonPBR_01 – no artefacts.

We did also try different workaround like a volumes to decrease the sun/sky intensity when inside, PPV with high exposure values to hide the noise, sky leaking and adding lights with very high intensity, etc.

Overall, we are looking for natural solution, with less help from Post Processing Volumes, animated lights, hidden emissive, etc.

How we can improve Lumen to cooperate with sun/sky PBR values, without these visual artefacts?

Thanks!

2

Hope everyone at Epic enjoyed a nice summer break!

It would be great to get a response on this.

3

Hey there! We had a great summer break, thanks for asking! Sorry we weren’t able to get to you before we left.

Last time I was chatting with folks about splotchy lighting like this it was more the opposite of what you’re describing. They were using non-physical light values and then using local exposure to get brighter values in the shadowed areas. It was like they took a dark image into Photoshop and expected the Levels adjustment to fill in missing steps in lighting values. I don’t suppose you’ve got anything like that going on in this scene, do you?

I do want to flag before I get too deep that I’d be really curious to see the differences between SWRT and HWRT. We’ve been making some improvements to the performance of HWRT (especially into 5.6) to make it more viable for 60 fps situations and at better quality than can be achieve with SWRT. The added benefit of HWRT would be that you’d get to use the Lumen Farfield which will help with everything beyond the lumen scene distance (although you’ll probably need to do some work to ensure that your tunnels HLOD correctly, since I’m not sure default HLOD methods would preserve any concavities).

I think it’d also be really helpful if we could take a look at this level ourselves. Are you able to migrate it out to a standalone project and upload it for us to tinker with? It looks like it’d be pretty small in terms of disk size.

Thanks!

4

Hey [mention removed]​ , thank you for looking at the question.

First one - no, that’s not our case. The set up PBR, sun/sky int. are very close to the real ones.

We did try with HWRT but it doesn’t look very different, I’m adding a video (RT_ON_02), this is UE 5.54.

I’ll move the scene to a project and send it over.

Thank you!

5

Hey [mention removed]​,

Just sending the project, UE 5.54, level: Lumen_and_PBR, Please, let me know if there are any issues opening the project.

Thanks!

6

Hi,

I opened your project and looked around a bit. Even outdoors is already pretty noisy, mostly because you have a really bright sun baked into your sky envmap. Removing such relatively small and bright light sources would help Lumen to converge outdoors.

Most of the lag is coming from radiance cache. You can disable it using `r.Lumen.ScreenProbeGather.RadianceCache 0`. It will make lighting changes much faster and remove some of the grid artifacts, but it should be also more noisy (through for some reasons it isn’t in this content).

Translucency and fog indirect lighting is using a pretty low resolution volume for performance reasons. You may try to increase its resolution (r.Lumen.TranslucencyVolume.* and volumetric fog / translucency lit volume CVars) to reduce leaking if you can afford that in your budget.

I’m not really sure why non-PBR values would change anything. Unfortunately I couldn’t open those videos (it only shows me 4 files), but in general it shouldn’t matter whether you use lower or higher lighting intensities. Like if you set your sun to 12EV and exposure to 12EV it will result in exactly the same image as sun set to 1EV and exposure set to 1EV.

This tunnel is also too challenging for Lumen, as it has to be lit from multiple indirect bounces. I think realistically you need to work around those limitations by adding there some direct lighting, a tiny bit of sky leaking and maybe constraining exposure, so that it doesn’t go so low. If you’re open to larger hacks, then you could also try to disable/modify things like indirect sun intensity when you’re in this tunnel in order to reduce leaking and other issues.

7

Hi [mention removed]​

Thank you for the answer.

I’ll check on how the sun in the HDRi image impact the scene, thanks for that.

When set r.Lumen.ScreenProbeGather.RadianceCache 0 it’s the Lumen scene is definitely more stable but with lots of micro noise, is there an option to denoise it? We’ve found increasing the r.Lumen.ScreenProbeGather.RadianceCache.ProbeResolution helps but guess this will be on the performance?

Translucency - we will discuss this option, thanks!

About non PBR values - in theory this is right, the behavior should be the same but with low values for the sun/sky these artefact might be only visible when exposure is set to -10, something we usually don’t do, so the tunnel interior looks just dark without visible noise (or at least not in our exposure range). That’s what we meant with Lumen is working better with non PBR values as the scene looks more stable in the exposure bracket 2EV to - 2EV instead of 12EV to - 2EV if that make sense. I’m adding the video again.

Hacks - we’ve already got a bucket of :), but thought first to try without and then move to that option.

Keeping the exposure high make the local lights not visible so we need to set them up high above BPR values to have a visual impact, the same with adding sky leak. They are also too bright from outside the tunnel/interior.

Thank you!

8

Hi [mention removed]​

Thank you!

I’ve moved the project to 5.6 and got some questions:

How r.Lumen.CachedLightingPreExposure (default 8) change works? For example if it’s 2 or 4, is clamping the lower value or changing the whole range?

r.SkyLight.RealTimeReflectionCapture.PreExposure - it’s not active for me, do I need to change something in the editor settings?

Thanks.

9

Ah, yes, clamping exposure helps, as GI has to do less work there.

One thing to watch out, is that before 5.6 we support around ~[-16; 16] exposure values and outside of that some energy may be lost. This was fixed in 5.6 and there are now controls for shifting this range: `r.Lumen.CachedLightingPreExposure` and `r.SkyLight.RealTimeReflectionCapture.PreExposure`. By default we also now shift everything by 8EV, so that supported range is ~[-8;24], which by default covers physically based lighting range.

“When set r.Lumen.ScreenProbeGather.RadianceCache 0 it’s the Lumen scene is definitely more stable but with lots of micro noise, is there an option to denoise it? We’ve found increasing the r.Lumen.ScreenProbeGather.RadianceCache.ProbeResolution helps but guess this will be on the performance?”

Radiance cache itself is a way to denoise, as it allows to share distant rays. Increasing probe resolution means that there’s some kind of issue with tiny bright elements, where some probes are able to pick them up and other can’t. And yes, x2 higher res means x2 slower tracing part of radiance cache update.

“Keeping the exposure high make the local lights not visible so we need to set them up high above BPR values to have a visual impact, the same with adding sky leak. They are also too bright from outside the tunnel/interior.”

For the gameplay elements, which have to be always visible (think lightsaber in Star Wars, which requires constant brightness no matter if it’s a middle of a day or dark night) we use “Inverse Exposure Blend” property. It won’t help with your issue here (enviro lighting), but could be useful for some gameplay stuff.

10

So looks like skylight fixes are only in UE5-Main.

How it works is that it shifts the entire range of cached lighting values by multiplying everything by 2^Value. Floats have around -16 to +16 EV range, but most likely people want to light for ~-8EV to 24EV, so we shift this range by default.

11

Hi [mention removed]​

Unfortunately I can’t find any big improvements on 5.6.

[Image Removed]

What only in UE5-Main means? Is it something we need to wait for in the next 5.6 update?

Thanks!

12

“What only in UE5-Main means? Is it something we need to wait for in the next 5.6 update?”

It means that this didn’t make it into 5.6 and exists only in our trunk / main branch (ue5-main), which is accessible from P4 or GitHub. You could try to integrate it manually or wait until the next release. Through not sure if this is going to be very useful, as I don’t think lack of GI energy is your main issue here.