Headset IPD

[Beyley]

I've been using this repository as a loose guide to implementing a native Vive Pro 2 driver for Monado (to be able to use with both libsurvive and the official Valve tracking blob), one thing which has caught me up is the IPD reading. It reports 15mm over the Lighthouse protocol, but over it's own protocol, reports 4 integers. An earlier version of this repo did have mfg-r-ipdadc read out, but never properly parsed it out into a millimeter or meter reading. I've found 3 more values, mfg-r-ipdmin, mfg-r-ipdmax, and mfg-r-ipdlap, which seem roughly related to the IPD slider, but I've been unable to figure out the algorithm to convert this into a real world measurement.

Have you happened to make progress on this? Or are you also stuck on the same issue.

Here are some values my code is reading out from the HMD:

DEBUG [vp2_hid_open] IPD: 309 (min: 499, max: 3581, lap: 3922)

[CertainLach]

I didn't do anything about it, since those values are only used by vive calibration software, which I was unable to get running on Linux.

You can find conversion to meters in the calibrator itself, included in Vive Console.

[Beyley]

You can find conversion to meters in the calibrator itself, included in Vive Console.

Ahh, I see, I will take a look next chance I get, thank you.

ftr in case it helps, I reverse engineered the display distortion, at least the strengthen high order model, which I have working 1:1 with LibLensDistortion, you can find it here

[CertainLach]

ftr in case it helps, I reverse engineered the display distortion, at least the strengthen high order model, which I have working 1:1 with LibLensDistortion, you can find it here

Is your headset using this model? LibLensDistorion has much scarier code paths, and one used for me is opencv-based

[CertainLach]

For basic code path I got my wine replacement to work, but I don't have enough patience to make it run opencv, thus wine.
https://github.com/CertainLach/chimera

[Beyley]

ftr in case it helps, I reverse engineered the display distortion, at least the strengthen high order model, which I have working 1:1 with LibLensDistortion, you can find it here

Is your headset using this model? LibLensDistorion has much scarier code paths, and one used for me is opencv-based

They actually pretty much all use OpenCV, most just for matrix multiplication though. Which distortion algorithm does your HMD use? Me and all the testers that have used my driver have had strengthen_high_order, so it's been no issue.

[CertainLach]

I don't remember the model name according to the LibLensDistortion, but it was using cv::ml stuff after I have got it from repair

[CertainLach]

Just noticed that I did reverse it at some point for my unfinished configurator.

Adc is converted to not-millimeters as not_millimeters = (70 - adc / 400)

Not-millimeters because the final value then needs to be processed somehow to get the actual millimeters, but I didn't bother with that, because not_millimeters are roughly the same range (Physical IPD - 57-72, not_millimeters - 60-70), and also I don't see any difference with software IPD adjucement, is it even used by SteamVR itself?

[Beyley]

I don't see any difference with software IPD adjucement, is it even used by SteamVR itself?

It's used to adjust the distance between the virtual cameras. If this doesn't match the user's physical IOD (distance between centers of eyeballs) then there will be a slight mismatch in the "scale" of the world, without effecting the movement speed, which can cause disorientation or nausea for some people.

It being off by ~2mm isn't awful, and will strongly delay the issue, but it's still better for it to be exact to the user's actual IOD.

[CertainLach]

I don't understand how it should affect the virtual cameras? They have fixed ipd

[CertainLach]

Oh, nvm, you meant the inside game cameras

[CertainLach]

Ok, makes sense then. I have expected some difference in how the optics should work, but now I see the issue.

[Beyley]

I have expected some difference in how the optics should work.

VR optics are a bit special, where the position of the lenses relative to the user's eyes doesn't actually effect anything but clarity, distortion correction, and FOV. It doesn't change the user's actual view "feel" at all, given it makes everything parallel.

You can see this effect by putting a static image on the HMD displays and moving the HMD laterally while keeping your face stationary.

[CertainLach]

When adjusting SteamVR IPD on the fly without touching the physical IPD I see how it works now, doesn't seem like that affected anything for me before though. Will add this change.

It is also possible to get readings from this adc (and also from the side button) without polling the mfg-X commands, using SteamDevice, if I remember it correctly, but it isn't feasible for my openvr driver because the device connection is owned by SteamVR itself.

[Beyley]

It is also possible to get readings from this adc (and also from the side button) without polling the mfg-X commands, using SteamDevice, if I remember it correctly, but it isn't feasible for my openvr driver because the device connection is owned by SteamVR itself.

Is there anything written on how that's done? At the very least for my own uses I can probably wire it up using libsurvive (which fully owns the connection). The Vive Pro 2 sends 15mm for the lens distance over the normal lighthouse protocol.

[CertainLach]

I don't remember that much, I just have huge pile of broken code and wireshark usb pcaps stored on my nas.