Skip to main content
Up and Coming
January 10, 2015

Unity crash when activating OVRManager

I’m making a game where you can switch between VR and 2D mode at will by hitting a key or setting “VR mode” on or off in the options. In the older SDK 0.2.x versions with DK1, it worked fine.

But I’ve run into a problem with all of the SDK 0.4.x versions so far. I’m using DK2 now. When I try to activate my VR cameras, Unity crashes. Same thing happens in a stand-alone build.

I’m on a Windows 8.1 machine. Unity 4.6.1f1. OR SDK 0.4.4.

What’s weird is that I can do a specific sequence of events in the editor to get it to work, and then it works from that point on. I had to rename OVRManager.Start() to OVRManager.OnEnabled() to allow toggling back and forth at will.

The steps to get it to work:

1) Leave OVRManager component UNCHECKED. If it’s checked initially, I get a hard crash when enabling the GameObject. I have only one GameObject with an OVRManager component.

2) Run the game in the editor and hit the key to change from 2D cameras to OR cameras. The gameplay screen turns solid gray.

3) In the inspector, manually activate the OVRManager component by using the checkbox. Now everything will work. But doing the equivalent programmatically results in a hard crash.

I do get an editor log when it crashes. The end of it typically looks something like this:

========== OUTPUTING STACK TRACE ==================

(0x6422B444) (d3d9): (filename not available): Direct3DCreate9 + 0x130ae
(0x53FE1A99) (OculusPlugin): (filename not available): (function-name not available) + 0x0
(0x53FE192C) (OculusPlugin): (filename not available): (function-name not available) + 0x0
(0x53FE325E) (OculusPlugin): (filename not available): UnityRenderEvent + 0xce
(0x007BF0A7) c:\buildagent\work\d63dfc6385190b60\runtime\misc\plugins.cpp (154 + 0x0): PluginsRenderMarker + 0x47
(0x006B59AC) c:\buildagent\work\d63dfc6385190b60\runtime\gfxdevice\gfxdevice.cpp (957 + 0x9): GfxDevice::InsertCustomMarker + 0xc
(0x011127C6) c:\buildagent\work\d63dfc6385190b60\runtime\gfxdevice\threaded\gfxdeviceworker.cpp (1277 + 0x0): GfxDeviceWorker::RunCommand + 0x3596
(0x01115DE1) c:\buildagent\work\d63dfc6385190b60\runtime\gfxdevice\threaded\gfxdeviceworker.cpp (215 + 0x14): GfxDeviceWorker::RunGfxDeviceWorker + 0x51
(0x0090993D) c:\buildagent\work\d63dfc6385190b60\runtime\threads\thread.cpp (40 + 0x9): Thread::RunThreadWrapper + 0x2d
(0x7604919F) (KERNEL32): (filename not available): BaseThreadInitThunk + 0xe
(0x77C80BBB) (ntdll): (filename not available): RtlInitializeExceptionChain + 0x84
(0x77C80B91) (ntdll): (filename not available): RtlInitializeExceptionChain + 0x5a


One slightly unique thing is that I have a set of six layered 2D cameras and a set of equivalent OR camera rigs (so 12 total VR cameras), if that has anything to do with it.

Any thoughts on this?
    This topic has been closed for replies.

    11 replies

    SteveTackAuthor
    Up and Coming
    March 22, 2015
    Got it working finally! The "timer" trick was the key for me. My issue seems to have nothing to do with multiple cameras or moving OVRManager to another GameObject. It's all about letting the Oculus Rift OVRManager complete its initialization stuff before mucking around with it. It does require changing the Start method in OVRManager to OnEnable.

    Here's a small Unity 4.6 project showing what I did:
    https://dl.dropboxusercontent.com/u/28342849/VRCameraSwitch_UnityProject/VRCameraSwitcher_Unity4.6.zip

    The test scene is in Camera Switcher Assets/Scenes. If you click on the CameraModeSwitcher GameObject in the Hierarchy, you can toggle "Start in VR" on and off and set the amount of time to wait for the switch to 2D mode if applicable.

    It's the same basic technique that @welby posted and that I've tried before. The difference is you can start in 2D mode, or at least it looks like you are.

    My game was disabling VR cameras as soon as the game launched in 2D mode, but that always caused issues when then trying to then switch to VR mode. I think the initialization isn't done until the end of the current frame or something.