Starting async load causes massive lag spike

I'm also having problems also with getting Async stuff to work 100% correctly, without a few hiccups.

I've identified 2 things so far.

Particles, if you have 'Renderer' set and give it a texture/material, then it causes a little stutter. I'm guessing maybe the texture load its self is not Asynced in the load. I'm going to play around, and see if I can load the particle with no Material/Texture, and then after load, assign it with a Resources.LoadAsync... but I'm not holding my breath with that to not cause some other stutter 'somewhere'

Also, I found a bug with Reousrces.LoadAsync(), where if a texture/png being loaded was flagged with 'No Compression' in the import settings, then it causes stutters on loading.

I reported this to Unity, and unfortunately, I got a reply saying 'Duplicate' of another bug. Looked at this bug and its been in the 'queue' since 2016... so I'm guessing its in the 'wont fix' bucket also. That seriously annoyed me, since I spent a loooong time getting a test case to demo it for them

See here: https://issuetracker.unity3d.com/issues/async-load-is-not-async

At this point, I'm nearly thinking its far too much effort to try and get Async to work, as I've spent considerable time, trying to hunt these things down.

 

It is totally possible in the player if you follow such rules as: use async loading, load small scenes (if you need to load huge scene make sure all objects are disabled, awake functions are fast (better absent) and do timesliced enable yourself), minimize GC allocations.
In the Editor - unlikely - you can use profiler (with Profile Editor and/or Deep Profiling) to see the source of syns reads.
Basically if you see hiccup - use profiler and try to find the origin of it.

These lags come usually from explicit and implicit sync loads.
Explicit ones are all non-async Load/LoadAsset api. Implicit are assets - e.g. non-streaming audio, shaders, other assets which might stall main thread during "integration" stage.

 

The following video explains how the time-sliced-awake has been implemented for INSIDE. The relevant part starts at 9:50

Spoiler: Unite 2016 - Tools, Tricks and Technologies for Reaching Stutter Free 60 FPS in INSIDE

However, the conclusion of this talk, as far as I remember, is that you can't achieve a stutter free streaming game in Unity without modifying the Unity engine source code. That might be one reason why 99.9% of all Unity games have hiccups.

 

@alexeyzakharov I really appreciate you sharing this info with us, helps a lot. I'm wondering if you could be a bit more specific about "small scenes". I can think of a lot of different aspects that make a room "small" or "large". I'm building a 2d cinematic platformer for PC and console, so selfishly I'm interested in things like:

- Number of sprites
- Size of sprites
- Number of static vs dynamic objects
- Hierarchy depth, is there a depth point where things become costly to load
- Number of particle systems, and particle system complexity
- Number of lights and use of dynamic vs baked lighting
- Post processing effects
- Draw calls
- Batching targets

Of course, I can (and do) test different combinations to eval performance impact. But if there are well known thresholds that we should adhere to it would make my (and I'm sure others) life much easier.

@Peter77 Great talk by the INSIDE guys. I came away with the same sentiment as you -- they heavily modified the core Unity code base in order to achieve stutter free performance. Perhaps someone from Unity could give us a delta of what the INSIDE guys needed to do relative to the current version of Unity? Unity has definitely moved on since INSIDE, perhaps the custom code they need to write is no longer needed?

TIA!

 

@v2-Ton-Studios will be great to have someone from Unity to give us hints on how we can manage a INSIDE-type-solution with the current Unity version.

 

Any news on this?

 

bump http://prntscr.com/n2rsl1

 

It would be a good thing to test the newly introduced subscene setup for streaming scenes. Maybe take a look at the MegaCity demo? Also texture mipmap streaming can now help with big scenes.

I'm looking forward to create worlds now that Unity is focusing on performance and overall smoothness.

 

in my case reason was that we have big parent prefab with lots of other little prefabs inside it, added as overrides. So we just unpacked top, parent prefab. And it's ok, no freeze on MergePrefabs(). Reason wasn't Async itself

 

Sorry to necro... but this is still a very big issue, and the solutions go towards breaking your workflow and several other things that are worst than having a loading screen without stutter.
Isn't the goal of async loading to share the burden of loading between several frames to avoid a stutter, no matter how big the thing you're loading?
For what you guys say, I understand that there are some things that under the surface get loaded sync, so that tampers the async method and creates the stutter (otherwise I don't get why there should be a hiccup in an async load). My scene is already pretty small an I don't want to load a smaller one. I have stutter problems even when loading sounds async. This seems like a bug to me, or even a flawed feature. Is there some official response on this after 6 years? Will it ever be fixed? Or is there a proven workflow to eliminate the stutter without loosing key features?

 

Have you tried:

1. In a build?
2. With a small async upload time slice value in the quality settings?
3. With no script in the loaded scene? Or at the very least, no script with Awake calls?

We load terrain meshes at runtime using Asset Bundle async operations and it now works without hiccup for the most part. And yes, Unity is working on world streaming tech, probably powered by subscenes / DOTS.

 

Hi, thanks for replying. I have tried with the quality settings already and yes: playing witht the slice and buffer does help, but without getting rid of it completly. Keep in mind that according to the docs this option is only related to loading textures. I also played with the importing options of sounds like "load in the background" and such, and the different type of loading types (stream, load uncompress, etc). As far as I know, there's no option to set the buffer and slice of sounds.
I have loading screens, and the "loading" animation stutters everytime. I don't want to get rid of the Awake functions... between those two options, I prefere the stutter, wich is just unwanted for cosmetic reasons. Though, may I say that if that's the condition, then this is probably a bug. Also, I've seen stutter even while loading sounds during the gameplay.
I'm gonna test further in a build. I've seen this issues in a build, but I don't think, I have checked after changing the quality settings.

 

2022, still getting huge cpu spikes when you load assets. In mobile, the phone freezes for half a second. It doesn't matter if you use addressable and async. The problem is with Unity engine that it is not multithreaded so when you add the objects into the scene, it blocks.

 

That is not true. There are loading threads for textures, meshes and more. TextureStreaming does not cause spikes. Loading meshes doesn't cause spikes. What causes spikes is the Awake of GameObjects and things like merging lighting of two big scenes.

If you want seamless streaming on mobile, use DOTS Hybrid Renderer and subscenes. This way you get rid of GameObjects and consequently their associated spikes. You could also load the rendering data yourself and use DrawMeshInstancedIndirect to draw with a minimal amount of GameObjects, again avoiding hiccups.

See Megacity.

 

Using DOTS right now it's like putting a bullet in your head. Just watch all the DOTS complaints and lack of updates on multiple threads. If we are forced to use a different product to get something as basic as this, we may just do that and forget Unity ever existed.

 

Then read the second part about DrawMeshInstanced and minimal use of GameObjects and you won't have hiccups. Also think of Virtual Texturing and other production-ready, memory-streaming options.

Furthermore, there are many developers, like our team, using DOTS for their projects. We have more issues with HDRP, like it not running on Switch, than with DOTS that runs perfectly well on PC/Mac/Linux, Xbox One/Series, PS4/5 and Switch.

There are always people complaining everywhere in the forums about everything. Sometimes you just have to try to do the things you want and see if they work for you or not.

 

How does DrawMeshInstanced avoid hiccups? Do you have an example? I've just tried it but the freeze is when loading/instantiating the object it seems. Before it even hits drawmeshinstanced.

 

You'd have to store your Mesh and Material in an Asset or all listed on a single GameObject to avoid instancing too many objects in a single frame, then draw them.

 

So, what creates the spike slowdown then? The gameobject instantiating?

 

Yes, the more you instantiate GameObjects and scripts with .Awake functions, the higher the spike you'll have. You can profile the spikes.

In the previous game we shipped, Kona, we streamed terrain tiles and scenes without hiccups on PS5/XBSX. On lower end platforms, we had to live with spikes because of the aformentioned problems. We have scripts and too many objects in scenes we load. If you want no spike, you have to get rid of all these objects and scripts.

 

Isn't that what I said? That you can't use the default game engine because it doesn't multithread it? Otherwise, loading gameobjects and displaying them would not create spikes. At the moment even if you load a single gameobject with a cube, it spikes briefly. The only way around this is not to use the default Unity system, which is to write a way to render and load the objects without using gameobjects. It sucks.