Report and consume positions in standing space instead of raw space

[Eirenliel]

Floor level is not always 0, this can screw up many functions that rely on it, including auto skeleton calibration. Need to find it in the driver, record it, and use as a base.

[Erimelowo]

HMD pos when using base stations is wrong

[Erimelowo]

As @kitlith said,

for floor level: if you pass an argument to the feeder app (--universe=standing), y=0 in that space is floor height. This would transform the problem from "how to get floor height" to "how to use standing universe measurements in slimevr server/preferring the feeder app over the driver"

We should use standing universe for the hmd and controllers. This gives us the positions relative to floor level. Then, if we need to send back the positions in raw universe, we can easily offset the positions by the difference between the driver HMD and the feeder HMD

[Eirenliel]

or we make driver/feeder send the difference between standing and raw to the server, and server applying this transformation to all data it recieves/sends. unless we can make driver fully work in standing universe too

[Erimelowo]

So we either

1. Make the driver work in standing universe
2. Or offset all our data with help of the feeder app.

1 is better IMO but it might not be possible. Also need to make sure this doesn’t break Quest standalone support!!

[kitlith]

or we make driver/feeder send the difference between standing and raw to the server, and server applying this transformation to all data it recieves/sends. unless we can make driver fully work in standing universe too

there is a file that stores the difference between raw and standing universe, if you want to handle this in the driver. It's C:\Program Files (x86)\Steam\config\chaperone_info.vrchap on my machine. I don't know what the reliable way to get that path is (i.e. steam installed in custom location, on a another drive, idk) or how to detect if it refreshes, but it does exist. i also don't know how it'll interact with, say, users of oculus headsets, though i suppose i am in the position to be able to test that if motivated to do so at some point.

[kitlith]

Had a productive conversation with @Louka3000 and @Eirenliel in discord today, where we decided exactly where and how this should be implemented in the slimevr ecosystem.

Specifically, we decided this is a driver issue, and that the driver should be sending/receiving positions in standing universe by reading the json file I mentioned in my previous post, and using it to translate the raw universe positions. (I'll look into transferring this issue to the correct repository once I finish writing this post)

An initial/proof of concept implementation shouldn't be too difficult. The main concern is making sure that we find chaperone_info.vrchap, no matter what system we're running on. Likely, we should rely on a registry key, or some way of querying steam itself, to point us in the correct direction. Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Valve\Steam\InstallPath looks promising, granted the likely difference between 64 bit machines and 32 bit machines. I welcome someone who is more familiar with this type of problem to chip in.

I'll be available to help anyone who picks this issue up.

[ButterscotchV]

Reading from the registry would limit our cross-platform capability, is there no definite path?

[kitlith]

It's in the steam config directory, which varies depending on where steam is installed. (C:\Program Files (x86)\Steam\config\chaperone_info.vrchap on my system, and many other systems, but not guaranteed to be there.) I say registry because I'm thinking of windows, but the problem exists will require solutions across platforms. If there's a way to query steam for its config location, that'd be nice.

[TheDevMinerTV]

My suggestion is: try to find the file you're looking for in the default path for the platform (Windows: C:\Program Files (x86)\Steam\config\chaperone_info.vrchap, Linux: ~/.steam/..., macOS: lol idk) and provide a config option somewhere.

[ButterscotchV]

It seems you can actually find the location through OpenVR at %LocalAppData%\openvr\openvrpaths.vrpath under the key config

[kitlith]

@TheDevMinerTV Given that the driver doesn't currently have a way to have config options, I'm tentatively labeling that as out of scope, but useful for the future. Instead, I just want to take that one step further -- instead of just default paths, try to autodetect the path as best as our current knowledge allows. On windows, that means querying the installation path registry key. I don't know what it means on mac or linux yet, which means they can get default paths until we figure out what it means.

@ButterscotchV aw heck yeah!

[TheDevMinerTV]

@ButterscotchV still doesn't really help as %LocalAppData% isn't a thing under Linux.

[ButterscotchV]

@ButterscotchV still doesn't really help as %LocalAppData% isn't a thing under Linux.

On Linux it can be found under either ~/.config/openvr/openvrpaths.vrpath or ~/.openvr/openvrpaths.vrpath

[kitlith]

So it turns out that Valve already wrote the code for us, and put it in the openvr sdk: https://github.com/ValveSoftware/openvr/blob/master/src/vrcommon/vrpathregistry_public.cpp

[kitlith]

Gonna try and write out the whole flow to get the translation between raw and standing universe:

• Call CVRPathRegistry_Public::GetPaths, or CVRPathRegistry_Public::GetVRPathRegistryFilename and parse the json ourselves
  • We may need to manually include vrcommon into our driver, or maybe we just need the include file.
  • Can probably do this once, at startup. -Open and parse the chaperone_info.vrchap file in the configuration directory we just found, if present.
  • This can contain multiple universes, so let's read them into a map<int, UniverseTransform>
• Query Prop_DriverProvidedChaperonePath_String on the HMD, and parse the file if present for driver-specific universes.
  • ditto.
• (Alternatively we can recurse through the config directory to parse all chaperone files.)
• Query Prop_CurrentUniverseId_Uint64 on the HMD to match the universeId and find the correct chaperone.
• Driver can now translate from raw universe to standing universe when reporting, and visa versa when slimevr server sends positions back.

Am I missing anything?

EDIT: I suppose it's worth considering how to refresh when a chaperone changes, but I don't think it's necessary for a first implementation. This shouldn't be changing that often, anyway.

Edited to update based off of later discussion in discord, chaperone_info.vrchap is no longer present in some cases when using steamvr beta and an oculus headset.