Hi guys,
I’d like to use FStreamLevelAction and LatentManager to load levels/maps asynchronously. The levels can be loaded, but it seriously effect the FPS when streaming. I know maybe I the streamed level/map is too large, but the asynchronous loading should not effect main tick I think. Maybe I do something wrong, could anyone tell me how to load levels/maps asynchronously and smoothly without “stuck” the main tick?
P.S. Should I set bIsShouldBlockOnLoad to true or false?
Hi,
bIsShouldBlockOnLoad should be false. Otherwise main thread will be blocked till level is fully loaded.
Level streaming right now happens in the main thread and distributed across several frames.
There are 2 main steps.
Loading a level package and all assets used by the level. Look at ProcessAsyncLoading in UWorld::Tick function. Main thread gives up to 5ms each frame to process level loading.
Once level package is fully loaded, next step will be: register all level actors in the scene. (create rendering primitives, physics objects). Actors registration is also distributed across several frames, look at UWorld::AddToWorld.
Streaming performance depends on how complex your actors are, you want AActor::RegisterAllComponnets function to do less work. For example big landscapes can have hundreds of components, so big landscape registration will certainly hitch. You should subdivide such landscapes to a smaller patches, the good number of components will be 64 in one patch.
Level streaming performance should be measured only in a cooked builds. In the cooked build all assets are stored in optimized formats, so engine don’t have to do additional work on them during loading and actor registration.
Thank you for your reply.
So is there anyway that I can stream levels/maps asynchronously using other thread instead of the main one?
Maybe I can decrease the time limit of AsyncLoading and AddToWorld, but I don’t know if it is a good idea.
P.S. Why 64 is a good number of components in one level?
Currently there is no way to load levels on other threads. But we have plans to work on this, as this is how it should be.
I doubt that decreasing time limit will help with hitches, usually hitches caused by a particular actors in the level (landscape, foliage). Actors registration during streaming is done per actor, assuming that each actor will not take too much time to register. This is true for most actors, because they hold just a few components. But landscape and foliage actors depending on settings can have hundreds of components which makes registration process for them expensive. Experimentally we found that 64 components per landscape patch does not cause hitches.
Great! Could I know when will we get the real async loading function?
This is scheduled to August, September. You can see it here and vote up! [][1]
[1]: