Level Streaming

Hi

We noticed the same 'hiccups' in Unity 5 while loading level files additive-asynchron like in Unity 4.
What is the reason?
Currently we use one GameObject with all Level-Objects as childs.

 

*bump*

(sorry, it's very important)

 

Are you trying that in editor or in a build? In editor, there is some more stuff going on than in a build, so a build should be faster.

 

Also imo it's not the best idea to load everything as one gameObject, try to make your "loader" that loads one by one object asynchronously in loop using coroutine and yields between every object loading. Or you could even make coroutine wait till it will load first GO, and then start loading next etc...

 

LoadLevelAdditiveAsync should load objects in a background thread, so you shouldn't have to make your own loader.

 

Just noticed the same thing, apparently making the loading async still doesn't change much...

 

Yes, me too. this API dosn't do better than U4! So sad....

 

Can someone from UT comment on this please?

Thanks.

 

I can't belive what you ppl are talking, because I use loadlevel async for huge scene and it works perfectly for me. Im afraid that you don't understand what async loading is. Yes its done on separate thread, but that has nothing to do with hiccups, because when it loads this object it must be rendered, set on scene etc, and it has nothing to do with async loading. When you load some big, complex object(s) to the scene it's impossible to have absolutely no hiccups. Loading level async don't causes any hiccups, its "creating" them when they are loaded. But I must admit that I don't have big experience working in Unity with async loading, so Ill check this when at home and have some free time. But again, for our huge scene it loads perfectly smooth, and then big(few seconds) hiccup, when LOADED. If you talking about this situation, its perfectly normal, and unavoidable. And again, as I told earlier in this scenario own loader that loads objects singly WILL help, because Unity will create objects one by one, not everything at time when asynchronously loaded .
So no, async load is not some dark magic function that will load your procedural world perfectly smooth with one line of code.... Don't blame Unity for lack of your knowledge, it's just not that easy to make smooth gameplay loading. And yes, even Skyrim has hiccups when you walk through big world, but they are so small that you probebly won't even notice them(it's well optimized). Sorry for english, lot of difficult words xd. (what I described on async loading was with Unity 4.5.5)

 

@Roni92

Are you even using the Unity 5 Beta? Those are rather strong assertions for someone who admits to not having much experience with Unity's async loading.

For those of us using Unity 4.x, can you actually post screenshots of the stats and data (comparing async loading time vs asset bundle sizes) to backup your claims?

 

First, as I said, my exp with async load is with 4.5.5, not tested in 5beta yet.
Second, who said I use asset budles?
Third, what loading times has to do with hiccups ?

 

http://forum.unity3d.com/posts/1575296/

 

Great to see they even improved this method. I referenced to Unity 4.5.5 because ppl talking here that nothing improved in 5. For me, async load level is great method already in Unity 4 and should really be treated like just luxury addition, that engine makes lot of dirty work for ya.

 

According to the OP, they haven't "improved" it. Apparently, seamless asynchronous loading has been advertised for quite a while, despite experiences to the contrary.

 

Yes , maybe the hicups is caused by the shader compilation, So I do a test : with shader precompiled, then do the LoadLevelAdditiveAsync, it still have some hicups, very obviously. Then I delete some objects in my scene, make the scene small enough, do the test again, it also has hicups but it is very small and acceptable for me. All objects in my test scene is static, they will be batching together with a combined mesh, So I think the combine operation maybe the cause of hicups? Or maybe the objects entering the view frustum is too many in the first few frames after the scene is loaded ? I am not sure but make the scene objects fewer is working.So if you want no [small] hicups when running the game, and still want to use the static batching, make the big scene into small chunks, and load each chunk when needed,is OK.

 

Enabling many colliders at once will also cause a hiccup.
They should be turned off by default, and their enabling should be spread over multiple frames.

I worked that out when enabling/disabling terrains, I was not loading anything at runtime, but it's something to keep in mind.

 

@ NA-RA-KU ; Noted!! good tip

 

I found that U5 is loading faster than U4,very good!

 

I've just downloaded the latest beta, and I can confirm that Async loading is indeed faster. For myself, the main culprit responsible for the performance bottleneck when using LoadLevelAdditiveAsync was Mesh.Bake PhysX CollisionData. It came in at a whopping 569.46 ms. Note that the scene I am trying to load contains a 32768 tri mesh terrain with a mesh collider.

With 5.0, this same method is still the main performance bottleneck, but the impact has been reduced to 84.63 ms. There is still a slight hitch in game play, but it is manageable, and of course I could try to split the mesh terrain up and activate the colliders over a series of frames for better performance (I'll try testing this soon).

I'm curious though, are there any efforts to further improve the PhysX performance? @Kim Riber statement suggest there will always be some performance impact, since there is a "final step that needs to happen on the main thread."

Yet this is contrary to the information found in the Script API here, where it's stated that,

This statement has been on that page for over two years, and while it's clear it's a lie in regards to Unity 4, I think many hoped Unity 5 would rectify the issue. Can we squash that hope now, or will performance continue to improve?

The Async loading methods should work as intended out of the box, without having to manually deactivate/activate colliders gradually in order to achieve optimal performance.

If a final step is needed to integrate the loaded scene assets, why can't this step be carried out over a series of frames? I imagine that most users do not actually use the newly loaded scene until the async operation is complete, so there should be no issue with extending the final integration step over a period of time. Or am I way off?