FEATURE REQUEST: A way for an HMD driver to request a SeatedZeroPoseReset

[TheDeveloperGuy]

There are numerous scenarios in the case of self-tracked HMDs where it would be useful for the driver to do the equivalent of recentering the seated position. As per https://github.com/ValveSoftware/openvr/issues/403 it is not possible right now. It is possible to do transformations on the pose to achieve this within the driver (or HMD), but a better solution would be triggering the equivalent of resetting the seated view in the SteamVR dashboard.

[HelenXR]

I very much agree with this approach, the function of steamVR direct support is the best In addition, according to my test, not all the applications' forward are in the yaw direction of 0 degrees, which will cause trouble for the reset function.

[TheDeveloperGuy]

I have managed to get this working in my driver for most scenarios. Biggest issue for HMDs that are not using fixed spatial positioning, either with external sensors (eg. Lighthouse or constellation), or with a magnetic compass, is that the HMD driver has no concept of 'forward', meaning that the user has to manually recenter.

[TheDeveloperGuy]

Have this working completely now where user can reset center via dashboard, room setup or headset. It does require the Chaperone yaw offset to be known in the driver, and for the driver to be made aware when it changes. I'm doing this by spying on the Chaperone's JSON config. It's not the "right" way, but it works.

[HelenXR]

That's what I think about this:

• on the need for reset function, #403, the above has been said, I think the reset is necessary
• on the realization of the reset, according to my test on steamVR, I found that the direction of the application is not uniform, the following is my test of the 10 games, there are about three types: Positive direction of 0 degrees (yaw direction): "The lab"(Official application) "The body VR" "AltspaceVR" "InCell VR" "Waltz of the Wizard" "Surge" "Acan's Call" Positive direction for application startup: "Gunjack" Positive direction for other fixed angles (yaw direction): "The Price of Freedom" 90 "Skeet:VR Target Shooting" 180 Because of the different direction, resulting in reduction method will be different (most reset to 0 degrees in yaw direction, but as shown above, there are two other types of situation will also #403 treatment, I verified this method).
• reset action on the steamVR to do, or in the application to do, or in the driver to do, these 3 places can do, where to do is the most suitable? I think by the steamVR platform trigger (whether it already exists? I do not know), the driver receives this event, the implementation of reset, because:
  • it is possible that there are multiple devices (HMD, handle controller, etc.) that need to be reset, the driver is more aware of how many devices are available, and reset for each device
  • in the driver to deal with the reset, the data will be restored to the steamVR, so that the steamVR and the application does not need to consider the issue of reset, it only needs to deal with the direction of the data reported by the device, so as to ensure the smallest reduction

[TheDeveloperGuy]

@HelenXR Your solution in the other post will work if you edit the Chaperone config file and set the yaw offset to 0 (for testing, as you cannot prevent the user from changing this). Your HMD driver will need to report yaw as zero when it is centered. Once you have this working, you can figure out how to apply the Chaperone offset, and what to do when it changes. Whatever will happen with this feature request will (maybe) be some time in the future. It is possible to have this working with the current SteamVR API today.

Whatever solution you implement has to work for all 3 use cases: you cannot change existing apps, you cannot disable the SteamVR room setup or recenter functions, and for some use cases (as discussed) the driver needs to do this itself.

Seems to me, some fairly big changes to the SteamVR architecture would be needed for this feature as originally requested:

• Driver events, an event mechanism whereby the driver can receive events needs to be implemented
• The driver needs access to Chaperone configuration
• The driver needs to be able to send events to app level processes, which it currently can't do

It seems the easiest way to do this would be to add a method to the tracked device class that receives Chaperone info. With the Chaperone info, it's possible for the driver to do all of the offset calculations for recentering.

[LoSealL]

@TheDeveloperGuy I'm guided here by you in #403 , now I'm using VRServerDriverHost()->PollNextEvent on VREvent_ChaperoneDataHasChanged, and once it has changed, I trigger my driver to record the current YAW data and recenter the HMD by this.

[TheDeveloperGuy]

@LoSealL That works? I'm doing file system spying on the Chaperone config file, which works, but is a bit "not really how you should be doing this".

[LoSealL]

@TheDeveloperGuy Oh, sorry. seems not every room-setup triggers VREvent_ChaperoneDataHasChanged. In fact there are 5 related events, but seems none of them can be polled when user runs room-setup.

Sometimes I can poll VREvent_ChaperoneDataHasChanged event and the chaperone data DOES changed, but most times I can't.

[TheDeveloperGuy]

The lack of detailed useful information on developing HMD drivers is very frustrating. You'd think that Valve would realise that every new HMD working properly on SteamVR would be bringing them additional customers and that they would at least dedicate 1 developer to dealing with device developers. As it stands everything to do with driver development is top secret with occasional clues given by Valve developers, which then obviously leads to sub-standard HMD implementations which then affect the overall quality perception of their product... Sheesh :/

[Balderick]

The documentation appearing to be scant is probably the most neutral way to describe the current openvr capabilities though

[TheDeveloperGuy]

Saying "the documentation appearing to be scant" is an understatement on the level of "the universe is biggish"... :D

[HelenXR]

Steam currently has two ways to reset the application:

1. running steamVR "Run Room Setup", this is too much trouble
2. steamVR--->Display Mirror, at this interface, keyboard input'z'.

How do I map the second styles of keys to other keys or trigger them without starting Display Mirror? @TheDeveloperGuy

[TheDeveloperGuy]

@HelenXR I have no idea, as discussed earlier in this thread, there is no way (that I know of) for a driver to trigger the "normal" re-center action. I track the Chaperone yaw offset in my driver and offset accordingly when it changes.

[HelenXR]

I see , thank you!

[TheDeveloperGuy]

The "correct" (Valve) way to do this seems to be to spawn a monitor app (dashboard app with no UI) from your driver, which you communicate with with VendorSpecificEvent() and (if necessary) DebugRequest(). Your driver tells the monitor to do a re-center and the monitor resets the seated position.

However this method means that you have to bundle an extra app with your driver, as well as openvr_api.dll for both 32 & 64 bit.

Would be awesome if Valve devs took a bit more time to address issues here rather than us having to waste large amounts of time discovering things that could be revealed with a single sentence from a dev that knows what's going on behind the scenes... ☹️

[TheDeveloperGuy]

"Monitor" app seems to be the way to work around most OpenVR design issues, including this one.