Head tracking while loading a scene

You probably want to use Application.LoadLevelAdditiveAsync(..). You can check the isDone variable to know when the loaded content is ready for use. Application.backgroundLoadingPriority will control the balance of resources the system puts towards loading the new scene vs running the original scene.

http://docs.unity3d.com/ScriptReference/Application.LoadLevelAdditiveAsync.html
http://docs.unity3d.com/ScriptReference/Application-backgroundLoadingPriority.html

sweet, thanks, that's exactly what I was looking for. The long blank loading screen that started my last demo got it rejected from Oculus share because they thought it froze up. This will make my new demo shinier :)

After messing with LoadLevelAsync for a long time, I'm still not able to get my program from stopping for that ~30 seconds of loading. If I use the option AllowSceneActivation set to false I get no stop, but as soon as I set this to true, the 30 second delay still occurs. It seems like the LoadLevelAsync function is "loading" the scene fine, but then when it "activates" the scene, the pause still occurs. (My scene has a HUGE amount of mesh colliders that take a while for the computer to process) I've tried all types of ways to run the function from coroutines in order to solve the problem with no luck. All I managed to do was move the 30 second delay from right at the begining to after the user selects "play demo" from a menu, which is slightly better but not great. I'm using a scene for my opening menu, a scene for the big scene loading, and the big scene. Again, to cite the Helix demo that proves it can be done, it looks like they do things the same way I'm attempting to get this to work because they also use 3 scenes in that demo. I'm pretty sure the one in the middle is the part that shows the loading progress. Does anyone have any insight on this? I need to start working on something else and I'm stumped. Thanks in advance.

Here's a sample of what I was trying to do on the script called from the second scene, the loading scene.

using UnityEngine;
using System.Collections;

public class loading_screen : MonoBehaviour {

	private AsyncOperation ao;
	GameObject Obj_dialog;
	int test = 0;

	// Use this for initialization
	IEnumerator Start () {
	
	//this Obj_dialog stuff is just for displaying an image in front of the player
	Obj_dialog = GameObject.Find("help-dialog");
	Obj_dialog.renderer.material.mainTexture = (Texture)Resources.Load("loading_screen",typeof(Texture));
	yield return  StartCoroutine(loading_level());
        //tried executing LoadLevelAsync from here, from everywhere really, with the same results

	}

	IEnumerator loading_level () {

                //this test stuff is not important, I just wanted to see how the code was flowing, basically it just calls start_loading();
		while(test<20)
		{
			test++;
			print (test);
			if (test > 19) start_loading(); 

		}
		yield return WaitForEndOfFrame();
	}

	Coroutine start_loading () {
		
		ao = Application.LoadLevelAsync("birdland");
		return WaitForEndOfFrame();
	}
		
}

For the record, I'm not sure exactly how this would work in Unity, though the theory will work.

Use a "pre-loader" scene with something like a loading bar. You can disable player movement/controls, but leave headtracking on. This will load... fast. While that scene is playing, use a game object to load the big scene. The progress bar will show the user the percentage of the next scene that is loaded.

"molton" wrote:
It seems like the LoadLevelAsync function is "loading" the scene fine, but then when it "activates" the scene, the pause still occurs. (My scene has a HUGE amount of mesh colliders that take a while for the computer to process)

Can you break your scene up into multiple parts? Not sure if this will help, but you might want to load the new level with its GameObjects disabled and then activate them incrementally from a coroutine. It's also good to avoid initial overlap between your colliders. Can you load the scene in a simple state and then use scripts or gravity to position the objects? Failing that, does AssetBundle.LoadAsync behave any better for you?

Thanks saviornt, that's kind of what I'm attempting. It's more complicated than I hoped it would be though

"vrdaveb" wrote:
Can you break your scene up into multiple parts? Not sure if this will help, but you might want to load the new level with its GameObjects disabled and then activate them incrementally from a coroutine. It's also good to avoid initial overlap between your colliders. Can you load the scene in a simple state and then use scripts or gravity to position the objects? Failing that, does AssetBundle.LoadAsync behave any better for you?

Thanks vrdaveb, I noticed a model I made a long time ago with overlaping geometry with coliders causes performance problems, didn't pin it directly on that but it probably is the problem. That being said what causes the slow loading time, or scene activation time, or whatever is the hundreds of tree models with mesh colliders enabled.

I have not tried the AssetBundle.LoadAsync yet as that seems like a lot to do, but if it actually works I'm going to try it, and if nobody has a magic trick to make LoadLevelAsync work I guess that's the next thing I'm going to try. I had previously broken the scene up into a grid for dynamically activating and de-activating models, I can probably use some of that previous organization for this if it works.

If I remember correctly with the previous activate, deactivate problem I could get it to work in 2 ways. One would have a slight hiccup while activating/de-activating and one would work seamlessly but cause the program to crash, and wouldn't even run in the Unity editor. It had to be built and ran. I think it worked/ crashed because I was using a C# mutex and that didn't work well with Unity.

can't use a mutex for one command like loadlevelAsync AFAIK, but for a bunch of asset bundles the mutex might work good, maybe Unity 4.5 doesn't hate mutex as much as 4.2.

"molton" wrote:
That being said what causes the slow loading time, or scene activation time, or whatever is the hundreds of tree models with mesh colliders enabled.

How many total objects are in the scene, and do you have all of them set to being a mesh collider? Unless you're using basic shape meshes, that will cause alot of decrease in performance. For complex models, I get a higher frame-rate / loading rate when I use simple colliders on the object.

A basic object would be, for example, a set of stairs. A complex object would be a tree.

This is apart of optimizing the game. Using basic colliders, a tree would have 2 collision boxes (the base, or trunk, of the tree, and the top, or the leaves/branches). That way the engine only needs to calculate 2 collisions, rather than the hundreds, if not thousands, of collisions per tree.

While it is less accurate, it shouldn't affect the gameplay; unless, of course, you're attempting something with hyper-realistic (such as a rain drop falling through the leaves and branches of a tree) physics.

I also assume that you've applied occlusion culling to the scene?

"saviornt" wrote:
... Unless you're using basic shape meshes, that will cause alot of decrease in performance. For complex models, I get a higher frame-rate / loading rate when I use simple colliders on the object...
...I also assume that you've applied occlusion culling to the scene?

I need the coliders to be mesh colliders because in the game you are a bird, and you have to be able to land on the branches and stuff. I might be able to make a simpler mesh model, but a box colider for the top half of the tree in not going to work. I have not messed with occlusion culling, that is a feature I always just kind of hoped Unity was doing anyway, deffinelty have to mess with that, perhaps that alone will greatly reduce the "activation" time. Thanks for the suggestion



edit: if I'm reading that right, it's sayting it needed 129GB of memory for this operation. I don't even have enough disk space free for that. maybe I should get a SSD drive for virtual memory space. It's pretty impressize to watch Unity churn away at this stuff. I might need to tweak the settings, does that sound right for a big area?

SSD's are expensive for that size and people say using them for virtual memory will make them die quickly, so I guess that's not the best option.

"molton" wrote:

I tried to click on the Quit button there.
Sorry, just came here to say that!

lol, that image hasn't been resized at all, just cropped, It still looks like you can click on it.

I had to re-install a hard drive I had put in an external enclosure to get the ~130GB to process that occlusion map. The end result was only a 21MB file, that was a relief. I was hoping I'd get a big performance boost using that but I didn't notice much difference. however, I deffinelty see a positive difference in the scene activation time. On my fast computer it went from about 30 seconds to fully load up the scene to about 20 seconds. On my laptop it went from about 50 seconds to 35 seconds. I'm suprised the overall performance hasn't been affected much by the occlusion culling. I have everything marked as an ocludee and nothing marked as an occluder, I guess that doesn't help as much.