cancel
Showing results for 
Search instead for 
Did you mean: 

Program runs with 90/180/270 degree rotation for no reason

mcc
Level 5

I have an C app based on the Native/vrapi SDK (using the open source engine LOVR.ORG). It has been working more or less fine for a couple years.

 

In the last month, I have stared seeing an unusual behavior. Sometimes, unpredictably, when I start the app, the app runs rotated. The rotation is always a clean multiple of 90 degrees. The app content is either directly to my left, directly to my right, or 180 degrees behind me. Used to, if the app was not directly in front of me, I could get it to recenter by holding down the Oculus button. Now I cannot do this, the little spinny-line-around-oculus-logo icon appears but when it completes, nothing happens. My code has not changed. This appears to have triggered based on something like an OS update.

 

Sometimes redrawing the roomscale Boundary and then returning to the program fixes this problem and sometimes it does not.

 

I see this problem on both Quest and Quest 2.

 

What could be happening? Has something changed?

5 REPLIES 5

Anonymous
Not applicable

I haven't been getting behavior quite this weird, but I have noticed some oddities in Unity when using a rig that's set up for "eye level" tracking origin. I think it has to do with the orientation of the device when it last fell asleep?

 

The position when the device falls asleep becomes 0,0,0 & forward for the start of the next session? Maybe I'm imagining it.

mcc
Level 5

Forgot to mention I'm using ovr_sdk_mobile_1.46.0, but I also saw this problem with ovr_sdk_mobile_1.44.0.

 

The sleep thing is interesting. I tested it by forcing my game to quit, sleeping the unit via the button, then waking it up again. My game was still running at a 90 degree angle to the right.

 

I tried scouring the docs and headers. I found a couple interesting things:
OVR_VRAPI_DEPRECATED(OVR_VRAPI_EXPORT void vrapi_RecenterPose(ovrMobile* ovr));

This appears to be a way to force a pose recenter. However, it is deprecated; and also there is the problem of when to call it. What I want is for the screen to recenter when the right hand "oculus button" is held down and the animation has completed. I can detect when the button is held, but what I *can't* detect is the progress/completion of the little oculus-icon animation. I'd expect there to be, like, an ovrEvent for this, but there is nothing of that type in (for example) ovrEventType.

I also found this unusual feature in the Unreal docs *only*, which seems to turn on and off auto-reorient on controller recenter— exactly what I want! It's off, and I want to turn it on!— and it is NOT deprecated. But, it is Unreal only. https://developer.oculus.com/documentation/unreal/unreal-blueprints-set-reorient-hmd-on-controller-r...

 

I guess I really have three problems here:

1. Why did there USED to be a auto-reorient-on-controller-recenter feature, and now it is gone? Did something change and I'm now expected to change the "tracking transform" by hand (vrapi_GetTrackingTransform) when the controller-recenter gesture happens? Is the auto-reorient feature present and I just have to turn it back on?

2. How do I detect when the controller-recenter gesture (the user holds down the oculus button and the little circle animation completes) has been entered?

3. There is an initial "tracking transform". Used to, it was the same as the position of the Oculus Quest main menu. Now, it is 90/180/270 degrees off from the main menu tracking transform. How do I obtain/match the main menu transform initially (as opposed to the main menu transform plus the 90/180/270 offset)?

mcc
Level 5

So I spoke to the LOVR lead dev about this and he suggested the problem might be related to recent Oculus changes around the "tracking space". I was calling vrapi_SetTrackingSpace with VRAPI_TRACKING_SPACE_STAGE, the lovr dev suggested VRAPI_TRACKING_SPACE_LOCAL_FLOOR. After switching to LOCAL_FLOOR, the recenter-gesture fixed itself. I have also not seen the 90/180/270 problem since making the change, but that problem came and went at random when I was seeing it so I do not know if the problem is fixed.

 

So this fixes my problem (1), but not (2), and may or may not have solved (3). (2) seems especially important if a user has a need to use STAGE, since my understanding is supporting controller-recenter is a VRC and another member of the LOVR community apparently had a Labs rejection due to this. How is a program using STAGE meant to support controller-recenter? Is STAGE still supported?

 

I do not find documentation of "tracking space", or a mention of "stage", anywhere on the Oculus website. There is some documentation of the various tracking modes in the headers of the vrapi sdk, but the documentation for vrapi_SetTrackingSpace contradicts the documentation for ovrTrackingSpace (STAGE is only listed under ovrTrackingSpace, not SetTrackingSpace).

mcc
Level 5

Update from my investigation: One of the Quest VRCs

https://developer.oculus.com/resources/vrc-quest-functional-9/

Makes reference to the "stage" tracking mode. It appears "stage" is still supported. So the question stands: Why does stage content sometimes appear at a random multiple-of-90-degrees offset? Can a game correct for it? (And is there any way for a game to react when the hold-oculus-button-down "recenter" gesture is entered?)

Anonymous
Not applicable

In the C# OVRPlugin file there's a reference to this method, which should be available to C as well:

public static extern Bool ovrp_GetAppShouldRecenter();

I *think* it's supposed to return true the frame after the user has performed the recenter gesture, but I've never tested it. 

 

(Edit: This might be old Rift functionality that was never removed.)