Setting the GlobalIlluminatinQuality scalability level to Low or Medium through user options seems to disable Lumen and cause the rendering context to be re-created.
For some reason, if this is done during a cinematic (full screen video), the level lighting seems to be disable after the cinematic ends.
If you change the quality level back to High or Epic which re-enabled Lumen, normal lighting is restored. This does not happen when a cinematic is not playing.
The only work-arounds we can think of are not great - force all scalability settings to re-apply at the end of each video or add awkward rules around when options are available.
We are using the default engine settings for GI:
This is not something we’re very familiar with and are hoping for some ideas on what could be going wrong when changing this while the scene is hidden behind a video.
`[GlobalIlluminationQuality@0]
r.DistanceFieldAO=0
r.Lumen.DiffuseIndirect.Allow=0
r.SkyLight.RealTimeReflectionCapture=0
[GlobalIlluminationQuality@1]
; Enable DFAO when Lumen is off
r.DistanceFieldAO=1
r.AOQuality=1
r.Lumen.DiffuseIndirect.Allow=0
r.SkyLight.RealTimeReflectionCapture=0`
Steps to Reproduce
Load map with an intro cinematic (full screen video) and change the global illumination quality scalability setting to Low or Medium during the cut scene.
Hello,
Thank you for reaching out.
I’ve been assigned this issue, and we will be looking into why disabling Lumen during a cutscene is breaking lighting for you.
Can you please send us a minimal test project that demonstrates this, and include screenshots or video of the issue?
The guide for test projects: [Content removed]
Hi Stephen,
We’ve been looking at ways to repro and don’t know that we can easily create a demo project as all of our maps stream assets in and load on the fly. They aren’t umaps we can re-create outside of the game.
I understand that would make this difficult to debug, but hoping it looks like something obvious you can suggest.
I’m attaching screenshots of the issue.
- low-cutscene is the issue where we set scalability to low during the initial cutscene before showing the rest of the level.
- low-normal is how low normally looks.
- ultra is now ultra normally looks
Hello,
As a test, can you try enabling “r.SkyLight.RealTimeReflectionCapture” after the cutscene plays, in both cases? If this helps, you could add this to your project’s Scalability ini as an override.
It is possible that the Skylight’s cubemap it out of date.
Is your scene meant to be used without Lumen? You can override the scalability inis to make sure Lumen is always on.
> Is your scene meant to be used without Lumen? You can override the scalability inis to make sure Lumen is always on.
Not that I’m aware of at least not intentionally. The issue goes away if we reset Scalabiilty manually through user settings after the cut scene ends and doesn’t occur when entering a map without a cutscenes. The screenshot I attached of low-normal is with Luman disabled.
Some results from testing.
Setting r.SkyLight.RealTimeReflectionCapture to 0 after cut scene does fix the issue.
However, setting to 0 before loading the map seems to repro the original issue but at any quality level (Low or Epic). It seems setting r.SkyLight.RealTimeReflectionCapture to 0 again after loading the map resolves it.
I’m not sure I understand what that implies.
Hello,
Based on that result, it sounds like the Skylight is using stale capture data after the cutscene ends.
Some options for you to try depending on your performance budgets:
- You can keep r.Skylight.RealTimeReflectionCapture enabled across all your scalability settings to make sure dynamic changes are always accounted for
- If not, trigger a skylight recapture on-demand to make sure the right skylight cubemap is used
- If a recapture is expensive, you can also try using a pre-captured cubemap in these cases to avoid some of the recapture costs
You might also want to integrate the change found in CL: 37388300 on //UE5/Main, that fixes some issues when switching between scalability values with landscapes.
Please let us know if this helps.
Stephan, I am having trouble locating that commit in the github repo. That CL doesn’t show up in any seraches on github or locally.
Some good news.
Porting that CL did not fix the issue by itself but setting r.SkyLight.RealTimeReflectionCapture=1 for Low and Medium does fix the issue.
We’re looking into why lighting is different during the cut scene and when e should re-capture.
Hello,
RealTimeCapture runs over multiple frames to generate the cubemap which can be the issue you are seeing when lighting in your scene varies drastically. This can be controlled with the CVar “r.SkyLight.RealTimeReflectionCapture.TimeSlice”.
Please keep in mind disabling this can cause performance impacts.
If you are not able to use RealTimeCapture for your use-cases, you can also trigger a recapture using the RecaptureSky() function on USkylightComponent or using the console command “r.SkylightRecapture”.
This will also cause a performance impact and please ensure that you are setting the component to SLS_CapturedScene.
Please let us know if this helps.
We are going to try enabling realtime capture on low and medium since it doesn’t seem like this needs to update beyond the initial capture which is somehow blocked when disabling during the initial cut scene.
That seem simpler than finding the perfect spots to manually capture and use the more expensive call you mentioned.