Skip to main content
jashan
Up and Coming
January 9, 2019

OVROverlay rendered correctly from HMD in editor - but from origin in builds

Does anyone know why sometimes, the compositor does no head-tracking or is stuck in front of your face (i.e. all layers from the compositor are rendered to the HMD from origin aka position / rotation zero, instead of from the HMD position)?

So far, this seems very random to me: It always works correctly in the editor (i.e. OVROverlay instances are in world-space, and rendered from the actual HMD pose), but earlier, I made a build, and the build had the compositor stuck. Then, I did some work on the project, eventually did another build: Now it also worked correctly in the build. And currently, again, in the builds, the headset renders from origin. This only occurs in the compositor, otherwise, the game renders just fine. Also, I never saw this in the Unity Editor - only in builds (this is obviously on Oculus Rift, via Oculus SDK).

I have now done quite a bit of experimentation trying to make this work correctly in builds again - but no matter what I do, the compositor is "stuck on the HMD" (i.e. all the OVRLayer instances are rendered with the camera at origin, instead of being rendered from the actual HMD position).

Version information: Unity v2017.4.12f1, Oculus Utilities v1.32.0, OVRPlugin v1.32.0, SDK v1.33.0. I originally reported this here, but that thread became a little big.
This topic has been closed for replies.

2 replies

jashanAuthor
Up and Coming
January 15, 2019
Can anyone give me a hint on what's going on with this?

I spent the last few days dealing with this issue and it seems that something is happening with the scene that causes this: I've had a build where it worked, and one where it didn't work, and I was able to fix it for the build that was broken by overwriting the file level0 in the broken build with the one in the working build. Meanwhile, I also got to see this in the editor. But I see it one time, reliably over a few play sessions (hit play in the editor, see the issue, stop playing, rinse, repeat), make a copy of the scene (which has no apparent changes in Unity), open that copied scene, it works again, open the "original scene", it still works.

So it seems that whatever change is happening in the scene does not mark the scene as dirty in Unity but it does go into a built version of the scene most of the time, but not always.

This has been a nightmare to debug for a feature that has always worked flawlessly without any issues in SteamVR / OpenVR! I don't see how a Unity game can even break the Oculus compositor this way: This should be rendered by the Oculus runtime outside of our game, once I have passed the textures to the compositor. All overlays including the skybox overlay are rendered from camera at origin (0,0,0), no rotation, regardless of the actual HMD pose.
jashanAuthor
Up and Coming
January 16, 2019
Apparently, no one had a hint. I still don't know for sure - but here's what I found out so far:

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.
Terms & ConditionsAccessibility statement