I stumbled across something troubling recently that I really don’t know how to solve and I’m hoping for some insight here.
We have some quite large scenes in our game with many objects. When our largest scene is loaded from disk, there is a period of time where Windows believes the game has stopped responding. If the user clicks with their mouse during this time Windows will present the usual “application has stopped responding” dialog
This is bad user experience when nothing is actually wrong and the game is just loading. The immediate reaction is going to be that the game is broken and to close it. At the very least, it appears unprofessional.
This occurs when loading the particular scene from Application.LoadLevelAsync, or right after the Unity splash screen when making a build with just this scene. Both development and non-development builds. It occurs before Awake is called for any script, so it appears not to be code related (though could be serialization related). It occurs if loading from disk takes a long time for any reason: resource contention, slow hardware, large scene, etc. Since we have a very large scene, this happens regularly even on an SSD with little to no resource contention.
It’s very easy to reproduce this behavior with any moderately sized scene by simply playing a build from a USB 2 flash drive.
How can we stop this from happening? It seems this should be considered a bug in the engine.
I’ve narrowed this down silghtly. It only occurs when the game is running in a window. It happens when running Fullscreen Windowed, or in a bordered window, but it does not occur when running in fullscreen Exclusive Mode. I’ve tested on D3D 9 and 11.
Yea, that’ll likely hide the issue for most people. I’m assuming application code and the windows message pump both run on the same thread. So any blocking operation you do from the main thread will eventually cause this. Async loading still has a stall when it runs OnEnable and friends on everything in the scene, but assuming you’re not doing something insane it’s probably short enough to avoid tripping windows’ “not responding” behavior. Back in the day I found it to be a much better practice to avoid OnEnable, OnDisable, etc and do your own setup/teardown so you can control how long you block. Better still to do setup from another thread, but you can’t use most Unity API from other threads so it’s mostly a wash.
Anyone have a solution? I’ve never seen it happen on my computer regardless of window setting but it happens on other computers all the time. Unity 2019.4.1f1 here
If the problem is caused by loading 1 large scene async, you could also consider splitting that scene into several smaller scenes, which you load one after the other. Since any asset referenced within a scene is loaded with the scene, also eliminate any references to assets you aren’t using, or if just not using immediately you could move them around so you load them later closer to when they are needed.
On large audio assets, especially large music files, set loadInBackground to true for all of them other than the music you’re playing first. This will allow a scene which references them to finish loading and start playing before the audio assets have actually finished loading from disk. (that’s also why you leave this disabled for the first song, if you want it to be playing with the start of the scene)
Thank you there is some good advice here. In my case I have a main hub that always needs to be spawned in, but then I also have a bunch of prefabs with references to assets that need to be instantiated but not immediately. I think that moving these prefabs to a different scene and loading them additively would help with the initial load time a lot.
