Common Loading Screen and StreamingPauseRendering interaction

Development Platform & Builds
, ,
1

This question was created in reference to: [Common Loading Screen - transition between maps shows black screen in [Content removed]

Hey, I’m evaluating CommonLoadingScreen plugin from Lyra to use as-is, or a custom solution is required instead. I’m loading a World Partition Level using Seamless transition (as well, created an empty map and set it as TransitionMap). I have exactly the same question/issue as referenced question: Loading Screen is being displayed, then Black screen with Throbber, and then Loading Screen again.

I found out, that black screen+throbber are caused by StreamingPauseRendering module, which set a delegate to GEngine->RegisterBeginStreamingPauseRenderingDelegate.

When placed breakpoint, it seems, that WorldParition calls UWorld::BlockTillLevelStreamingCompleted() which calls GEngine->BeginStreamingPauseDelegate->Execute(GEngine->GameViewport->Viewport); and aforementioned module renders a black screen with throbber.

I want to have my loading screen widget instead of default StreamingPauseRendering, so I modified void ULoadingScreenManager::Initialize(FSubsystemCollectionBase& Collection):

void ULoadingScreenManager::Initialize(FSubsystemCollectionBase& Collection)
{
    FCoreUObjectDelegates::PreLoadMapWithContext.AddUObject(this, &ThisClass::HandlePreLoadMap);
    FCoreUObjectDelegates::PostLoadMapWithWorld.AddUObject(this, &ThisClass::HandlePostLoadMap);

    // Disabled Streaming Pause Delgate
    GEngine->RegisterBeginStreamingPauseRenderingDelegate(nullptr);
    GEngine->RegisterEndStreamingPauseRenderingDelegate(nullptr);
    
    const UGameInstance* LocalGameInstance = GetGameInstance();
    check(LocalGameInstance);
}

Is this the way to have no black screen with throbber? Maybe some setup is wrong, what should I check? Player is not set to wait until streaming is complete. Level is loaded using UCommonSessionSubsystem::HostSession / GetWorld()->ServerTravel.

It was also mentioned that CommonLoadingScreen was “likely in an incomplete state”, can one assume that now it’s in complete state, or some changes are pending?

Best regards,

Bohdan

[Attachment Removed]

2

Hi,

Your workaround is correct; I have a note to add something similar to CommonLoadingScreen since it’s unclear that two “loading screens” are actually showing at once in this scenario, and we’ve seen a few reports of folks running into similar problems. The CommonLoadingScreen plugin and much of the other systems in Lyra aren’t really being developed further, so I’d treat anything in there as something provided “as-is” (though we do our best to fix issues when they’re reported).

Best,

Cody

[Attachment Removed]

3

Hey Cody,

Thanks for the answer. May I assume you will improve this scenario in near future or don’t rely on that?

I’m curious, in some projects we don’t have that Streaming Pause module kicking in. I don’t understand why it’s not 100% repro

[Attachment Removed]

4

Hi,

I wouldn’t count on anything in the near-term, it would be simple enough to add the lines to unregister those delegates but I’m not sure we have QA resources to verify that doesn’t cause other problems. In the case of Lyra, the black screen with the throbber is actually being created but its underneath CommonLoadingScreen, so it has never been noticeable. It’s possible that something similar is happening in some of your projects (where it does pop up but the z-order is different for whatever reason), or it could be related to the timings in UWorld::BlockTillLevelStreamingCompleted (where that delegate is fired).

Ultimately, the best solution would be a more globally accessible flag that anybody (such as a load screen plugin) can use to inform other systems that it’s going to handle displaying the load screen. The delegate we bind there in FStreamingPauseRenderingModule::BeginStreamingPause *does* check if a loading screen is already visible from FDefaultGameMoviePlayer, but there isn’t currently a good way for it to check more broadly if *anything* is handling the load screen (which is why CommonLoadingScreen doesn’t get noticed by FStreamingPauseRenderingModule). However, we don’t currently have any plans to refactor things here, so for now it’s likely simplest to just unhook that delegate since you know you’ve got your own loading screen to use instead.

[Attachment Removed]

5

Good! Thanks for the explanation. Will keep my eyes on it

Best regards

[Attachment Removed]