Head tracking while loading a scene

It's an improvement nonetheless. Did you notice an FPS gain at least?

How many objects are in your scene currently?

no on the fps improvement so far. Not sure how many objects. At least 400, probably more.

edit: I wanted to backup my project before I tried something new but my project went from roughly 11,000 files to 1,161,344 files after the occlusion culling map baked!!! This is going to take a while. I don't know why it's copying so slowly, Windows seemed to freeze up during the preparing to copy phase.



actually, I think I'm going to revert to a previous backup and maybe try occlusion culling again as a final step. I'm going to try the asset bundle method and see if that works better than LoadLevelAsync

@molton, since I'm basically hearing "occlusion culling" and "bird simulation" in the same sentence, I thought I would just check to make sure it's the right way to go:

Occlusion culling is something that benefits certain types of scenes, but not all. If you're in the middle of a city (like NYC) with a lot of tall buildings, and you're standing in the street, there's only so many buildings you can actually see from where you are. Just the ones along the two streets you're on. Occlusion culling would be perfect for this.

On the other hand, if you're in a forest where you can potentially see through the leaves of a tree to the leaves of another tree way off in the distance, Occlusion culling may not offer you very much of a benefit (and instead you're just left with the overhead of doing occlusion culling in the first place).

If your scene does not lend itself well to a volumetric grid of cubes that can be turned on and off by Unity, you might consider doing your own culling by intelligently turning on and off parts of your map that you know can't be seen from one place to another. (Requires scripting, and intimate knowledge of the map which you have since you built it) This may still not be a good option if you're a bird that can see long distances, though.

You could also reduce your far clip plane and introduce fog -- tricky to avoid losing that sunny day feel.

And finally, greatly reducing the detail of far-away objects when you're not close enough to see that detail could help. Unity has built-in ways to do this for meshes (or you can roll your own solution since you're intimately familiar with your own scene).

This all assumes you've made everything that does not move Static and that you're using Unity pro for static batching.

Good luck!

If you're getting 30 seconds of something happening in the main thread and you've used async level loading, you should use the Unity profiler to see where all the time is going.

If you start up the profiler before you start, load the scene and then pause or stop the game, you should be able to see an enormous spike with the 30 second frame. If you select the CPU panel on the profiler, you should be able to dig down and work out what it is that's using all the time up.

The > 1,000,000 file occlusion map data that was making it impossible to backup my project was just metadata from the baking process that could be deleted without any repercussions. I deleted that and occlusion still "worked" (deleted from project root\library\Occlusion)

"drash" wrote:
...if you're in a forest where you can potentially see through the leaves of a tree to the leaves of another tree way off in the distance, Occlusion culling may not offer you very much of a benefit (and instead you're just left with the overhead of doing occlusion culling in the first place)...

Thanks, I think you are right about occlusion culling for my scene. It's strange to me that if I "visualize" the occlusion culling in Unity it would show only trees active in the cameras' views, but then if I hit play and paused the scene it would show all trees sitting there, and it performed as if all trees were there.

"drash" wrote:
...If your scene does not lend itself well to a volumetric grid of cubes that can be turned on and off by Unity, you might consider doing your own culling by intelligently turning on and off parts of your map that you know can't be seen from one place to another. (Requires scripting, and intimate knowledge of the map which you have since you built it) This may still not be a good option if you're a bird that can see long distances, though...

I managed to solve the 30 second activation time problem doing that. What I did was disabled all the mesh colliders and used that previous gameobject organization I reffered to earlier to enable the colliders of the trees I was around. That problem is solved, now I have a new problem, I get a slight hiccup while colliders are activating while the player is moving accross the game world. I should be able to fix that with threading and that mutex thing.

"PlanetTimmy" wrote:
If you're getting 30 seconds of something happening in the main thread and you've used async level loading, you should use the Unity profiler to see where all the time is going.

If you start up the profiler before you start, load the scene and then pause or stop the game, you should be able to see an enormous spike with the 30 second frame. If you select the CPU panel on the profiler, you should be able to dig down and work out what it is that's using all the time up.

I'm learning so much useful stuff in this thread :) never heard of that, will deffinelty be checking that out. It probably would have shown me what I found out. Loading the scene was not the problem, activating all those colliders at once was.

Thanks for the good info. Now that the load/activation time went from 30 seconds to 3 seconds, a blank screen for those 3 seconds will be fine, No need for constant head tracking with quick black transitions IMO

There isn't much you can do about the pause. Unity isn't actually doing much of anything in parallel when you async load, it is just breaking up the work to process a little at the end of each frame instead of doing it all at once, and some tasks cannot be easily broken down. Certainly the execution time for any of those chunks of work is not bounded in any way.

In my experience, async load just makes the load take longer without giving you real interactivity, unless your scenes are extremely simple.

Now, what it will allow you to do is display a spinner UI element that you can continue to animate kinda-sorta smoothly while the level loads. The best method I found was to first load into a scene that is totally empty except for your loading spinner UI, and then do an async load of your new scene. This is pretty much the only way to hide the long delays. Plus it reduces memory requirements since it unloads your current scene before doing anything else.

Having the same issues here, LoadLevelAdditiveAsync(..) only allows delayed screen refreshes as the next scene loads in the background, so it still causes nausea-inducing lag if there are any visuals being displayed when you call it. We reduced the amount of loads, by simply combining scenes that were smaller is size and literally translating the camera position to a different area. And of course using fade out before calling the next scene to load.

Same Unity has not addressed this, but for them I'm sure this specific Oculus implementation issue is not a top priority for them.

Hi, i was wondering if it may be because of the draw calls? How many draw calls do you have in the scene?