Problem with apps that switch to Seated mode

[bgr]

Hi, I'm trying to use this app for development so I don't have to take the headset off every so often, and I was so close to a perfect setup. However I've encountered the following problem:

in Unity, if I choose "Tracking Universe Seated" and enter Play mode, OpenVRDesktopDisplayPortal will get confused about where the overlays/colliders* should be.

(*) Note that I'm using AlphaAndScale mode, so it might appear to be working OK with default settings. I've set it up so that the overlay is in front of me as a large monitor, that is small and transparent when I'm not looking at it, and enlarged and opaque when looking at it. Once I enter Play mode in my project, looking at the overlay no longer works, and after about 10 seconds the overlay gets shifted to another position.

Ideally, the overlay would always stay at the same spot.

I've tried running OpenVRDesktopDisplayPortal from source, with [SteamVR] prefab added to the scene and set to Seated as well, but it doesn't seem to help.

[Hotrian]

This is because you are changing tracking setups in SteamVR on the fly. Technically this is not supposed to happen while an application is using a given tracking setup.

In specific, it is happening because of these lines. Before I added this line it was causing #11 to occur. E:D is the only game I know of so far that was having issues with me setting the tracking space instead of getting it - Now I'm getting it every 10 seconds instead of setting it.

Once I enter Play mode in my project, looking at the overlay no longer works,

There isn't anything I can do about this because SteamVR is calculating from an incorrect position (OVRDDP's internal model and SteamVR's internal model become desynchronized for a bit). It should work again after the 10 second timer resets though. Does interacting with the overlay stay broken?

Ideally, the overlay would always stay at the same spot.

This isn't possible because your tracking reference is changing. In one tracking space your "world center" is in one place, and in another it is in another. Seated I believe allows you to "recenter" your world center, which is what's causing this issue. Your Seated "world center" and your Play Area "world center" are in two different locations (I believe this is just how it is).

I don't think anything I can do about this because SteamVR is physically shifting your world center.

It might be possible to grab the offset from SteamVR somewhere or calculate it though, I'll look into that.

Edit: Turns out there are ways to work around this limitation.

[Hotrian]

Actually it looks like GetSeatedZeroPoseToStandingAbsoluteTrackingPose might just return the offset between the two world centers. I'll look into taking it into account and if that doesn't work, calculating the shift (to negate it internally).

[bgr]

No problem, here's my chaperone info http://pastebin.com/pNe1bRrN

Does interacting with the overlay stay broken?

No, it sorts itself out after it shifts the position after 10 seconds.

[Hotrian]

Thanks! Unfortunately, it seems that GetSeatedZeroPoseToStandingAbsoluteTrackingPose doesn't return what I need it to; it seems to only return the Identity Matrix, plus the Y offset. It doesn't seem to include the X and Z offset for some reason. I'll keep messing with it, though; there might be another method that returns what I need. (GetRawZeroPoseToStandingAbsoluteTrackingPose?)

Edit: Seems I'm having issues because I'm using the Null driver :(. I'll try to work around them.

[Hotrian]

So, in testing with the Null driver, I can't actually reproduce this error. The Overlay is always where it should be, and only moves if I call ResetSeatedZeroPose(). Any chance you are calling that?

I don't doubt that you are having this issue, it just isn't present with the Null driver. Switching tracking spaces literally does nothing on the Null driver. Since I can't reproduce this, I can't fix it right now. I assume I can reproduce it later when I setup my Vive, but the Null driver's HMD is always at 0,0,0 and I can't properly switch tracking systems so I can't reproduce this right now.

Sorry for the inconvenience, but I was actually just getting ready to sleep when you posted the issue so I tried to quick fix it. I don't feel like setting up and breaking down my Vive right now (I always put my system away completely so my cats can't mess with it), but will work on it first thing when I wake up. Again, sorry for the delay. I understand you can't continue your in-VR-developing until I fix it.

[bgr]

Thanks for awesome dedication and no hurries! I just double-checked it with empty project and just SteamVR and CameraRig prefabs added, it's the same. I'm using Unity 5.4.2 and latest SteamVR from the Asset Store.

[Hotrian]

So I was able to reproduce this issue with an actual Vive. It will take a bit of work to calculate and compensate the shift, but I believe it is doable.

Compensating for the XYZ translation is easy, but I'll have to do some more testing to see if I can easily calculate the rotation and negate it.

If/When implemented, I'll attach a beta build here that has that behaviour as soon as it's working properly. For the repo/future releases, I'll add a setting under the Additional Settings panel that allows for negating the Seated offset, because I like that the Seated pose automatically rotates the Overlay coordinates so that forward is "seated forward", right is "seated right", etc., by default.

[Hotrian]

Seems like converting from one coordinate system to the other is a lot harder than I had anticipated. Still working on this..

I also can't seem to find anyone else who has converted between the two coordinate systems. This doesn't seem to be recommended.

[Hotrian]

Give this a little test, would you? I may have been over thinking the whole problem. Turns out OpenVR has a somewhat undocumented line of commands that can be used to grab the absolute positions and rotations regardless of tracking space. I switched to always using the absolutes and the Overlay should no longer move when switching tracking spaces, and everything else seems to be working now, though I may have missed something.

As I said earlier, I still like the idea of adding this as an optional setting, so that the original behaviour can be maintained.

• The old behaviour is: when switching to Seated tracking space, X always moves left to right, and Z always moves forwards/backwards, relative to the Seated Zero Position (set when you "Reset Seated Position").
• Under this new behaviour: X always moves left to right, and Z always moves forwards/backwards, relative to the Play Area, so when switching to Seated or recalibrating the Seated position, nothing changes.

Here's the Beta binary I promised :) OpenVRDesktopDisplayPortal-v1.0.6.1.zip

I only have limited time to test it out, but everything seems to be working correctly as far as I can tell. Let me know if you find any issues with it; I'll do some more testing later when I can, but I might miss something.

[bgr]

I gave it a try, seems to be working perfectly! I'll be using it a bit more later today and I'll report how it went.

[bgr]

I've been using this in the previous days and I can't find any fault with it, great job!

Initially I thought I saw some drift with the overlay position/rotation, so I gave it some time before confirming it works, but I never saw it again so I think I hallucinated it. In my opinion, the issue can be closed. 👍

[Hotrian]

Thanks for the feedback! Will work to implement an option for this in the next version :).

[Hotrian]

This is now in OVRdrop, which is the closed source Steam Release of OVRDDP. Since I will continue to incorporate feature requests from OVRDDP into OVRdrop, I am closing this issue now.

If you are interested, you can find OVRdrop on Steam here.