Background Images load too late and with wrong Image Stretch [UE5]

[JohnAmanar]

Hello! Super awesome Plugin!

Works fine with my UE 4.27 project, but after porting it to UE 5 the Default Loading Screen images are not loading until the end of the loading process, they are also scaled wrongly. The Startup Loading Screen always displays instantly and scales just fine. If I choose the same image for one of the Default Loading Screen Images as I used for the Startup Loading Screen, that one loads and scales properly.

Could you please take a look? I guess something is changed how Unreal loads/streams in textures in UE5.

Thank you!

[Hagestol]

i have the same issue

[Laguland]

Hi, what I have done in my project is to load all needed textures in StartupModule function so it will have time to load before showing on the screen :) This is not the most optimal solution as all textures are all the time in the memory but it can be optimized

[JohnAmanar]

Hi! Thanks! I've tried to add all my textures to the [Startup Loading Screen] list, but it doesn't work for me. Only the first one in the array is getting loaded. Do you mean something else with the StartupModule?

[kaasbobkaas]

Hey, did you find out how to fix this? I have the same Issue and have no idea how to fix it

[MarkarianFR]

Hello Guys,

What about a temporary fix while the "real" fix is implemented ? Already 5.0.03 and still not corrected.

[Masterfuzzfuzz]

Pretty massive issue in that the plugin is functionally useless in UE5 and no sign of it even being acknowledged.

[dzCxy]

i have the same issue,using ue5.1 @truong-bui

[xongnox]

So Laguland is right, the easy and ugly way is to preload background images from FAsyncLoadingScreenModule::StartupModule

So in AsyncLoadingScreen.h, add :

private :
   [...]
UPROPERTY()
    static TArray<UObject*> PreLoadedImages;
};

And in AsyncLoadingScreen.cpp :

[...]
#define LOCTEXT_NAMESPACE "FAsyncLoadingScreenModule"

TArray<UObject*> FAsyncLoadingScreenModule::PreLoadedImages = TArray<UObject*>();

void FAsyncLoadingScreenModule::StartupModule()
{
    // This code will execute after your module is loaded into memory; the exact timing is specified in the .uplugin file per-module

    if (!IsRunningDedicatedServer() && FSlateApplication::IsInitialized())
    {
        const ULoadingScreenSettings* Settings = GetDefault<ULoadingScreenSettings>();

        // Ugly : permanently load ALL the background images.
        {
            auto PreLoad = [](const TArray<FSoftObjectPath>& Images) {
                for (auto& Image : Images) {
                    PreLoadedImages.Add(Image.TryLoad());
                }
            };

            PreLoad(Settings->StartupLoadingScreen.Background.Images);
            PreLoad(Settings->DefaultLoadingScreen.Background.Images);
        }

        if (IsMoviePlayerEnabled())
        [...]

For a marketplace engine, you will need to have the plugin in your local project directory Plugins folder. This solution is ugly and keeps all game long all the background images in memory, but it works.

If you have a lot of background images & levels, each image for a level, a more decent solution would be to pre-load only 2 images : the start-up/main menu one in FAsyncLoadingScreenModule::StartupModule, and the background for the level to be loaded in or before calling UAsyncLoadingScreenLibrary::SetDisplayBackgroundIndex

It's so ugly i can't do a PR, but maybe this can be helpful to some folks.

[slonopotamus]

Note that startup image is not unloaded even with current implementation: https://github.com/truong-bui/AsyncLoadingScreen/issues/57

[truong-bui]

@dzCx, @xongnox I have added an "bPreloadBackgroundImages" option in this commit 0a9852f2f59626cae96958b659793a53606e1bef

You can remove all the background images from memory by calling "RemovePreloadedBackgroundImages" in the blueprint, then manually load all the background images with "PreloadBackgroundImages" function before calling the "OpenLevel" node

Please update the plugin and test if it works for you. Thanks!

[xongnox]

Nice to see you helping here @truong-bui !

I did a bit more investigation on the issue. I found :

• Cooked builds (dev/ship/distribution) seems fine without pre-loading, on SSDs and HDDs. So, it's great.

• The issue only appears when lauching Standalone from the editor. And pre-loading the image(s) in C++ only before OpenLevel does not work. Even returning a valid pointer to a valid texture to SBackgroundWidget.cpp does not work : I'm not knowledgeable enough about unreal textures resources and GPU memory management, but it may have to do with it, and not only, as I previously though, concurrent read from .pak files to memory while loading the level.

  It seems like the only fix for standalone is to load very early, i.e in StartupModule. Why does it works here ? I don't know but this may have something to do with https://github.com/truong-bui/AsyncLoadingScreen/issues/56#issuecomment-1498608390

  Thus I'm going to pre-load all background images in StartupModule with some _#if WITHEDITOR around, because it's a bit triggering when play-testing. Ie as in https://github.com/truong-bui/AsyncLoadingScreen/issues/56#issuecomment-1498257902 , without the unnecessary static but with a WITH_EDITOR.

  So from my understanding, no need to bother with Preload / Unload functions, who will do no good. I did not test to pre-load a few seconds before calling OpenLevel (instead of one line before in c++), but i suspect it would not work either.

[ERuts]

@truong-bui i see you closed this issue. Did you look at @xongnox comments? Issue seems to appear also in standalone non editor launch.

Any idea on how it definitely can be resolved? It is for sure a critical issue. Images are consistently not loaded at initial load. After that it seems ok.

Are you going to push the preload function to the marketplace version and also on 5.0, 5.1 and 5.2. I confirmed it works in your master branch.

[truong-bui]

@truong-bui i see you closed this issue. Did you look at @xongnox comments? Issue seems to appear also in standalone non editor launch.

Any idea on how it definitely can be resolved? It is for sure a critical issue. Images are consistently not loaded at initial load. After that it seems ok.

Yes, I have looked at his comment. As he tested, the cooked/packaged build works fine. So I think no need to do anything since this is mostly caused by how Unreal Engine manages texture data in memory in the editor. The preload options should be used for testing in the editor only.

Are you going to push the preload function to the marketplace version and also on 5.0, 5.1 and 5.2. I confirmed it works in your master branch.

I have pushed it to Marketplace but only for the newest version 5.2