How do I stop the Oculus Rift from pausing my app when taken off

Unity Engine
1

When I take off the headset it pauses my app and the mirrored screen goes to black. How can I stop this behaviour? (Other than taping over the sensor) I want it to continue to run my app and continue to mirror to the screen.

3 Likes
2

Ditto

2 Likes
3

No response? i’ve the same problem, pausing the app and putting mirror image black is f**cking anoying…

4

Edit OVRManager.cs from the Oculus Utilities package.
Find the line “internal static bool runInBackground = false;”, change false to true.

2 Likes
5

It would be really nice if Unity wrapped this up into VRSettings to allow us to remain model/brand agnostic. I’ve avoided downloading the OVR SDK so the application would work with either the Rift or Vive.

1 Like
6

Don’t you think that OVR SDK is a requirement to get your app approved on Oculus store?
Please correct me if I am wrong :slight_smile:

7

I’m not planning to use the Oculus store.

Either way, I feel it’s unreasonable to be required to use either the OVR player controller or OVR camera when I need to support the Vive as well (plus whatever other VR headsets that come out next year).

8

You could probably just strip out the minimal bit of relevant code from the Oculus Utilities and run it when VRSettings.loadedDeviceName == “Oculus”. I’ve done something similar to be able to set OpenVR into seated mode without having the whole package cluttering up my project.

9

The bool “internal static bool runInBackground” is not available anymore in OVRManager.cs (ovr_unity_utilities_1.15.0).

Any alternative?

3 Likes
10

Any news on this?
We need to prevent Oculus to pause/stop the application when the HeadSet is removed.

Thank you.

11

The way I dealt with this annoying issue, is to use the Oculus camera rig NOT Unity’s built in camera VR.
This allows some flexibility as there are more settings available, for example OVRPlugin.ignoreVrFocus = true; will always keep the Oculus enabled even when the headset is removed.

As far as I’m aware this is the only way as Unity has not given us the ability to control this.

Let me know how you get on

12

Hey guys, I’m curious as to what the use case is for this?

Currently Oculus VRFocus doesn’t effect the editor and you can still get orientation data and render, but for standalone (so long as Run In Background is enabled) we’ll stop rendering camera’s that are targeting eyes, but we will still render cameras that are set to render without XR tracking. We could make a general solution ignore VRFocus that would continue to render the VR cameras in this case, but a use case would be nice.

Are you trying to use this for testing or is this a feature of your application? I’m not sure why you’d want to continue rendering the VR cameras if the HMD isn’t being used.

13

In our existing design, we require a program operator who is not using the HMD to have access to a desktop interface which controls the program settings for the virtual reality experience. This operator needs to have access to the desktop settings regardless of if there is a user currently wearing the headset.

Ideally, we would like the HMD to display a “please wait” screen while the app is being configured from the desktop.

We have all of this functionality working fine in the Unity editor with the existing OVR scripts and Unity canvases. It is only when the app is compiled as standalone that we run into the sensor sleep issue which prevents the desktop operator from accessing the app from the computer monitor unless the headset is being worn.

14

Looks like we were able to achieve the desired result with a combination of using a second camera in the scene set to Target Eye (none) for our main display, and then select “Run In Background” under the player settings > resolution

15

We had a similar set-up as huxley.

The menu system would be operated when the headset was not on (i.e. entering user details), once that was done the user would then wear the headset and play the game. The issue was the application would pause once the headset was removed.

This was a couple of years ago so maybe things have changed within Unity since then.

16

Same. The app I was working on at the time used a hybrid of the desktop and headset hybrid where the UI control could be interacted with either in VR or by mouse. This was necessary because sometimes there were complicated settings that wouldn’t work too well in VR space (like typing a note, for example). So you’d remove the headset, type something, click on other things, etc. then re-enter VR mode.

Of course, having the app pause while the headset was removed defeated all that.

1 Like
17

any solution for this yet?

1 Like
18

Forget it. Oculus Rift and Rift S will stop from next year. Concentrate more on Oculus Quest. It is better.

19

But the truth is, whenever you target any platform you’re porting. I watch these YT videos about the engineering that went into making Gameboy games on 8KB of VRAM, thankfully all we have to do these days is change some lines of code.

I second that the Oculus Quest 2 might be the platform to target but ummm…with the whole ‘requiring your real name’ thing from FB, I don’t see SteamVR stalling any time soon.

20

Yea well looks like our data will be collected real soon.