xrLocateSpace implementation issues

[MortimerGoro]

SDK: hvrsdk-openxr-3.0.0.33.zip

• [x] xrLocateSpace(m.viewSpace, m.localSpace, m.predictedDisplayTime, &location)) (Fixed)
• [ ] xrLocateSpace(m.stageSpace, m.localSpace, m.predictedDisplayTime, &location)): Returns empty pose (0, 0, 0) instead of the difference between local space and floor space (I want to use it to calculate height position)
• [ ] xrLocateSpace(m.gripSpace, m.localSpace, m.predictedDisplayTime, &location)): Returns the pose of the controller related to floor position instead of relative to the localSpace. On a localSpace if the controller is next to the headset the position should be very close to 0,0,0.

[fwei-io]

VR Team - delivery date: 11/12/2021

[MortimerGoro]

It seems that 'xrLocateSpace(m.viewSpace, m.localSpace' is working as expected using the latest SDK.

But there are other scenarios of xrLocateSpace not working well for me (and working fine on the Oculus OpenXR with the same code). I created a list of checkboxes, I'll check them each time a issue is fixed

[MortimerGoro]

I added instructions to build Firefox Reality here: https://github.com/hms-ecosystem/OpenXR-SDK/issues/16

Let me know if you have any questions

[fwei-io]

VR Team: Delivery date：11/19/2021 - Fix the bug of 6dof controller posture transmission Delivery date：11/26/2021 - Fix the bug of 6dof helmet posture transmission

[Lixming]

1. xrLocateSpace(m.stageSpace, m.localSpace, m.predictedDisplayTime, &location)) In the latest SDK version, stageSpace is the same as localSpace.
   In more detail, during the safe fence drawing, the SDK will calculate the approximate height of the hemet from the ground, such as mPlaneHeight. If the safe fence drawing is skipped or the calculation fails, mPlaneHeight will be set to 1.5m by default. Then, this value will be added as an offset value to the Y axis in the localSpace. It means that localSpace->pose.position.y += mPlaneHeight;

2. xrLocateSpace(m.gripSpace, m.localSpace, m.predictedDisplayTime, &location)) Refer to the explanation above.

It is a temporary setting. In the future, we will standardize the implementation of openXR interfaces. Finally, I want to confirm whether the current setting can meet your development needs. If not, please clarify your needs and feed back to us. I hope it can help you fix bugs. @MortimerGoro

[MortimerGoro]

Thanks for the workaround, now I can get both head and controller transforms from the same reference space. Thanks to that I can compute a localSpace pose locally and expose it correctly in WebXR and the Browser UI.

Check out this demo with all the fixes: https://github.com/hms-ecosystem/OpenXR-SDK/tree/main/demos/demo_november9

Let me know if you find any issue with the 6DOF or controller positions.

[Lixming]

I have checked out your demo and the screen effect is nice. It seemed that the posture of both controller and helmet has been taken into effect. Great. But I found a bug that you may need to check. Once I exit the safe zone and enter the safe zone again, your demo will crash and return to the launcher. In other 6DOF apps, when I approach the boundary of the safe zone, the safety fence will be displayed in the app, and when I return to the safe zone, the app will continue to run normally.

[fwei-io]

@Lixming we are still waiting on both fixes:

• xrLocateSpace(m.stageSpace, m.localSpace, m.predictedDisplayTime, &location))
• xrLocateSpace(m.gripSpace, m.localSpace, m.predictedDisplayTime, &location))

Are these still in progress and on schedule? Delivery date：11/19/2021 - Fix the bug of 6dof controller posture transmission Delivery date：11/26/2021 - Fix the bug of 6dof helmet posture transmission

[lzhangcs]

Issue cannot be reproduced.