ValveSoftware
HMD driver stuck at lighthouse position
Hi, I have made a HMD driver that takes it's pose from open track.
I can use this driver with other open track trackers and it works fine.
However, if I try to just use the vive tracker through open track and perform room setup, it sticks the custom driver at the position of the second lighthouse.
I know the pose is coming through to the driver because I can rotate the view and preview it in the vr view.
The tracker is tracking, I can see it moving around from the position of the lighthouse.
I can read back the pose I'm providing to the driver and move a transform in unity that matches.
Just the hmd is stuck at the lighthouse.
I guess there's some issue with the pose of the second lighthouse being at 0,0,0 in my lighthousedb.json (attached)
I'm using forceDriver and activateMultipleDrivers with my driver the same as the null method; NOT using tracking overrides.
Any ideas? Thanks!
Does it fully lock the position of the HMD to the lighthouse, or does it make the HMD move relative to it?
If it's the latter, it is probably because SteamVR does not have any system for correlating tracking spaces from different drivers, so the tracking space origin from your driver aligns with the origin of the lighthouse driver, which is on one of the lighthouses. Guessing it should be possible to fix by either using a third-party utility like OpenVR SpaceCalibrator to align the tracking spaces, or finding out the relative pose between the spaces and offsetting all the poses in your driver with it.
Does it fully lock the position of the HMD to the lighthouse, or does it make the HMD move relative to it?
If it's the latter, it is probably because SteamVR does not have any system for correlating tracking spaces from different drivers, so the tracking space origin from your driver aligns with the origin of the lighthouse driver, which is on one of the lighthouses. Guessing it should be possible to fix by either using a third-party utility like OpenVR SpaceCalibrator to align the tracking spaces, or finding out the relative pose between the spaces and offsetting all the poses in your driver with it.
Yes, this is what I have just come to realise only moments ago after trying TrackingOverrides..
It appears to fully lock it but it could also just be that it's multiplying the position by 0.001 or something.
WOW OpenVR SpaceCalibrator looks like it will save my sanity.
Since I'm using the same transform as the tracker just delayed a frame hopefully it lines up perfect!
Thankyou for the reply, it's appreciated! 👍
I'll report my findings.
Thinking out loud here..
OpenVR SpaceCalibrator might be ok as a last resort, but it uses hooks and I think I will need to modify it anyway.
What I really want is just some programmatic way to put my HMD driver into the correct coordinate space.
Or even just a config file way to say 'This device's raw pose is relative to the center defined during room setup'.
Is there a way to get a transformation matrix for some other device's calibrated world space?
I'm not totally clear on the order of transforms, I assume it's something like
raw driver pose * seated/standing calibration = absolute pose delivered to the app?
so if I can output the raw pose from the driver as (raw driver pose * inverse seated/standing calibration) then is should end up in the right place?
But how to get that seated/standing calibration transform..? no idea atm :)
I wonder if all I need to do is multiply my raw pose by the inverse of the tracker's TrackedDevicePose_t.mDeviceToAbsoluteTracking
But even that would be a hack in this use case because the raw pose can come from any OpenTrack source, so source coordinate space would be identity for anything else and then the user is back to using OVR Space Calibrator.. lol
It's probably less confusing to just use OVR Space Calibrator.
Soo, the rabbit hole goes deeper.
Open space calibrator overrides the raw pose, but I need the raw pose relative to the room setup origin AND the space calibrator pose, so I have a bunch more work todo.
I need to find some docs on how all the transforms work together, wonder where that is hiding.