Feedback about scene loading

We're mid 2021 and there are no improvement in async scene loading.

The current system is very limited which makes our life difficult. Loading should not be such a hindrance so we can concentrate on the million other things a game requires.

I'll give you a scenario: In this current game I am jumping through hoops to lower the load time on Switch, hiding async scene loading whenever I can to avoid loading screens.
It is done by pre loading the next level during transitions such as fade to black, and, so far it is quite successful in simple linear phases such as title to world map.
But when the possibilities of pre loading branch out, for example from the world map to any level then my attempts at pre loading levels when the player is close to a hub fails.
When a scene is loading there is no way to stop it. Also if you change your mind and want to load another scene you cannot because the previous one needs to be activated first to release asyncop!

That's bad.

None of those problems are solved by addressable because it is built on top of it.

So what's needed are:

1. remove the activation requirement
2. allow to stop an async operation at any point
3. ideally allow for concurrent loading

Of all the things you guys are working on and the great new tech, the one thing that I hope to see in the near future is an improved version of our humble scene loading.

 

I agree that this is a big problem. One of the issues for us is object activation spikes (Awake/Start calls/OnEnable), which creates stutter when loading the scene asyc. The solution is to just turn off everything and activate them manually in a few frames. But this should be something that Unity handles, as it creates a lot of work to get right: for example this can cause desync issues between objects, because some of them are already getting updated while other ones are still disabled.

We had a few successes in decreasing load times and fixing some of these issues for our own game. We are building each scene into its own assetbundle, loading the whole thing into memory first, and then load the scene from that. This way things load 2x faster because Unity doesn't have to access the file a million times. Also, you could cancel that file load at any time if needed.

 

4. Run asset integration step not on the main thread

 

this issue was just opened
https://issuetracker.unity3d.com/is...e-at-the-same-time-one-of-the-scene-wont-load

 

What if update calls were disabled on that scene until everything has had awake / enable / start called? That seems less prone to breaking at least

 

That's the plan, to disable update calls until we manually call Awake/OnEnable/Start functions. But then we have to either manually handle updates ourselves or disable all MonoBehaviours on all these objects to prevent updates (which will make the OnEnable/OnDisable being called again). You can see how much more work this can be. But Unity could do this in the back-end and we wouldn't need to change a line of code.

 

No they could not.

This problem comes from some very fundamental guarantees Unity has about scenes, which are all very powerful on their own:
- Every object in a scene can hold a reference to every other object in the same scene.
- In the Update and Start methods of all Behaviours, every single other (active) Behaviours in the same scene has had Awake and OnEnable called on them.

Pretty much any code written in Unity might rely on these guarantees - either on purpose or accidentally. If that's changed, by eg. postponing some calls or whatever, a lot of code would break.


One way to improve this would be to make it possible to split one scene-asset into several independent parts that would be loaded one at a time. That would require preventing references across that boundary from existing when authoring the scene - or require having references go only one way. If you do that, doing things like first loading the level background, then loading static gameplay, then loading dynamic gameplay would be doable without breaking any dependencies.

I assume the solution Unity will want to go with instead is to use DOTS/ECS. The problem with that solution is that you're then using DOTS/ECS, which as of now seems to be an order of magnitude larger problem.

 

To go back to what @laurentlavigne is talking about, there's a lot of jank that can be fixed that's independent from the load hitch problem.

When a scene load has been set to not allow scene activation, we should be able to throw it away. That would allow us to start preloading scenes that the player might want to enter, without having to then actually use it if they change their mind.

That's much worse than the OnEnable/Start spike problem, because that's a problem we can do something about. It's a ton of work to do, but it's possible to have all of the stuff in the scene in an activation list and then activate things over time in an order that fits our game.

We can't do anything about not being able to stop a scene load, so that prevents any kind of speculative scene loading.

 

But the order is not guaranteed unless you set the execution order it in preferences, so running these methods in a few frames instead of all at the same shouldn't break anything, the execution order could still be respected and you wouldn't know if this awake method was called at the same frame as the other one. I guess there could be some complicated situations where this could break things, but for that they could make it an option when loading a scene.

 

This I agree that this is a bigger issue.
Although if you could solve this problem by loading the scene in additive mode, having all objects in the scene disabled on build time (a requirement for hitch-less loading) and then activate the scene you don't need and destroy all objects. It's very ugly solution, but it's there.

 

I agree that not being able to stop a scene load is a very big issue I have run into as well - in open worlds being able to "pre-load" scenes is a very important optimization that is unusable in Unity...