SetTrackingOrigin is not implemented

[Jumbli]

SetTrackingOrigin is not implemented. This is used to set the tracking origin to floor or eye-level.

Currently the OSVR implementation defaults to eye-level. This is great for seated experiences, but most standing / moving (and room-scale) experiences will want to use the floor level origin.

Advantages include, consistency with Vive and Oculus implementations, the player is their actual height in the game and the floor is at the expected level so you could reach down and touch it. This helps with immersion and safety when reaching down low.

Implementing this with OSVR would probably require changing the re-center routine in osvr_central.exe to ask if the player is currently sitting or standing when setting the default position and then use a configured seated-eye-height or standing-eye-height to calculate the height of the camera.

Probably related to the above, I noticed that positional tracking does not affect the camera position in the game (i.e. physically moving doesn't work) unless a certain function is called “GetOrientationAnPosition”. This had me confused for a long time as it's not necessary to call this function every frame with the Vive or Rift.

Also, if I physically walk 30cm in the real world I seem to move 60cm or more in the game. Is this a bug or could I have something configured incorrectly?

I hope these are things you can progress. Thanks :)

[JeroMiya]

Hello Brett,
Thanks for reporting the missing Get/SetTrackingOrigin. What's interesting about this is that the current default (eye) is actually incorrect per the OSVR-Server tracker interface conventions. By convention, tracking interfaces on semantic paths (such as /me/head or /me/hands/left) that support positional tracking should have position state that is relative to the floor. Although it isn't elegant right now in terms of manual json configuration (hoping to have a better UI for this at some point), the idea is that the user sets up sitting/standing vertical offset on the server level and the tracker reports are adjusted accordingly by the time they get to the client.

So technically we should be implementing GetTrackingOrigin to return EHMDTrackingOrigin::Floor if the /me/head interface supports positional tracking, and EHMDTrackingOrigin::Eye if it does not.

As for implementing SetTrackingOrigin as a way to override this on the client side? That's an interesting proposition. What would you expect to happen when the tracking origin is set to Eye and the position reports from OSVR are relative to the floor? Is the position set explicitly to 0,0,0, or do you just offset the position vertically until the position is 0,0,0 when the user is sitting/standing straight up? If the former, we can do that easily, but for the latter we don't currently have that metadata available from the server side - we'd have to guess.

[JeroMiya]

OK, so this is in progress, and here's the plan for V1 of this feature.

Critical missing information: Standing floor height.
Solution for V1: Hard code the average adult height.
Solution for VNext: Implement a config setting and read it in dynamically at runtime.
Solution for VFuture(?): Get standing floor height from OSVR-Core.

So, assuming you have a standing floor height from above:

If the tracking origin is Floor and...
-> The HMD supports positional tracking, then use the raw positional values.
-> The HMD does not support positional tracking, then offset positional values (always 0,0,0) by standing floor height.
Else if the tracking origin is Eye and...
-> The HMD supports positional tracking, then offset positional values by the negative of floor height.
-> The HMD does not support positional tracking, then use the raw position values (always 0,0,0)

For the purposes of the above, if the user has taken an orientation-only HMD tracker and added an explicit offset for standing height (as is suggested per conventions) in the aliases section of the server configuration, then the OSVR-Core interface will for all intents and purposes "support positional tracking" (even if the position is static).

The test for "supports positional tracking" is to attempt to get the position state. Getting the Pose state will always return success for a tracker, even if it's orientation only. However, getting the positional state will fail if the tracker is orientation only.