Level loading times and Vive/compositor

Hi,

I’m trying to make the experience of loading our levels as smooth as possible in the Vive. Right now the best setup I’ve found is:

Loader map (contains nothing but our "level loading" BP)
 Sublevel - visuals
 Sublevel - effect
 Sublevel - backgrounds
 Sublevel - audio
 Sublevel - interactions

We have one of these for each unique area in the game (right now we’re at 5 or 6 of these). All the sublevels are set to be loaded via blueprint rather than always visible. The process of loading the levels is:

  1. GameInstance calls OpenLevel with the name of the loader map
  2. Level loading BP calls LoadStreamLevel (MakeVisibleOnLoad true, ShouldBlockOnLoad false) for each sublevel in order

Step 1 of this works more-or-less fine for now, it’s the second part which is having the problems.

As each sub-level is loaded, the SteamVR compositor rapidly fades in and out as the game misses frames due to loading times, and this is really ugly. We could fade the compositor in manually which might help with this, but part of the reason for having the level-loading BP is so that it can display some progress to let the user know things haven’t stalled.

We have this in our DefaultEngine.ini:

[/Script/Engine.StreamingSettings]
s.AsyncLoadingTimeLimit=1.000000
s.PriorityAsyncLoadingExtraTime=0.000000
s.LevelStreamingActorsUpdateTimeLimit=1.000000
s.LevelStreamingComponentsRegistrationGranularity=1
s.AsyncLoadingUseFullTimeLimit=False

I’m really stuck with how to make this any better. The questions I have are:

  1. Is there any way to smooth this asynchronous loading to not interfere with the main thread?
  2. Is it possible to somehow stop the compositor flickering in/out when framerate drops?
  3. Can we render directly into the compositor so we can draw our loading progress there?

Maybe there are some other avenues for improvement which I also don’t know about, too. Any help is appreciated. I can also share some profiling files if that would be of any use.

Thanks

Hi David,

You can try enabling the async loading thread that will offload part of async loading process onto a separate thread. Note that it does have some requirements that are not always easy to meet: all UObject constructors, Serialize and PostInitProperties functions must be thread-safe. Long time ago I made sure this was the case in the engine but I’m not 100% sure this is still the case (although I have tried it recently and it seemed fine). You should also make sure that your game classes meet those requirements too.

You can enable the thread in your DefaultEngine.ini or in Project Settings.

[/Script/Engine.StreamingSettings]
s.AsyncLoadingThreadEnabled=True

This may not be enough though. Since loading triggers a lot of code like adding things to the world the hitches may be a result of something that’s outside of the loading code itself. I suggest you do a profile of you game and track all the hitches down.

I’m CC’ing Nick to answer the compositor questions.

Hi Robert,

Thanks for that. I’ll try adding that line to our config and let you know how it goes. I suspect the hitches could be from adding things to the world, but all our BeginPlay/constructor code is very simple so I don’t think there should be much from our end.

Thanks again,

David

Unfortunately, the Compositor fading in is a health and safety thing, so we can’t disable it. However, we’re currently making support for using the layering system to support loading movies, so you can put up a movie or an image that’s tracked in the HMD while you’re loading. That’ll let people know things haven’t frozen, and give you a nicer aesthetic experience as you load your content.

Thanks, do you know when this might be available?

Yup, it’s currently slated for 4.13