How to handle scene loading in Unity like when using SteamVR (compositor)

Hey Jashan

      Thanks for the explain.  
      For this kind of feature,  you actually can use OvrOverlay to do that.
for example
1. you can clear your game background to black
2. make sure ovrOverlay ( compositor layer ) is rendered  ( at least send into compositor once )
3  then enabling your CPU heavy work.   
4. you should be able to see ovrOverlay updating with correct tracking even you background app doesn't update. Technical speaking,  ovrOverlay ( compositor layer ) was send into the async timewarp,  will update there all the time with 90 FPS  regardless your game's FPS.

       I understand this way might be not friendly enough for most developers,  we are considering to provide a more specific prefab / or function to do this automatically for developers,  however,   so far, I can't promise the specific time frame for this feature

jashan said:

... also, does anyone know why sometimes, the compositor does no head-tracking (i.e. all layers from the compositor "move with the head", or stuck in front of your face)? 

Apparently, no one knew. I don't know for sure - but here's what I found out so far. This issue put me near giving up, so I'm leaving this here in case someone else runs into the same issues; this might save you some headaches (and Oculus engineers, please at least read the last paragraph):

It had something to do with the scene: I could grab the file "level0" from one build where it worked correctly, and use that to overwrite that same file in a build where it didn't work, and that way I could "fix" such a broken build (and also, break a build where it worked by doing it in the opposite direction). Unfortunately, I'm not aware of a decent way to look for differences in two such files (they were also the exact same file size). Mind you: Those are not the scene assets in the Unity projects, but the binary levelN files in the build.

I did have sessions where I could reproduce it in the Unity editor for a while, but even when Unity said the current scene had no changes compared to what's stored on the disk, making a copy of that scene, and switching over to that copy would make it work in the editor again. Then, switching back to the scene where it didn't work just a minute ago would keep it working. It was not easy to get the Unity editor into the state of this not working, and I don't know for sure what exactly caused it - all I know is that it usually happened after doing a build that produced a faulty build.

In one of the sessions where it didn't work in the editor, I spent quite some time trying to debug OVROverlay to figure out what might be causing this. The most likely candidate obviously was the headLocked flag, which gets set when the OVROverlay is attached to a descendant of the main camera. I could not validate this to be the cause of the issue - headLocked was never set to true in any of my test-sessions but they did show the faulty behavior. One possible explanation could be that this somehow got cached in the runtime handling the compositor from a previous session, but that's just random guessing.

Still, not knowing of a better way to solve this, I removed this whole headLocked stuff (no responsible VR developer should use headlocked stuff, anyways, so it's not like I lost anything of value). Also, as I saw that OVROverlay uses Camera.main, and you probably use that more often, I made sure to only have the VR camera tagged with MainCamera.

From the looks of it, this did fix it; potentially due to Camera.main behaving more as you expect it in some other places of your integration. The thing is: Camera.main is not a reliable way to check for VR cameras. If you check for Camera-components where Camera.stereoTargetEye is not StereoTargetEyeMask.None, you actually reliably do what you probably thought you were doing by using Camera.main.