search

Igalia / wolvic

A fast and secure browser for standalone virtual-reality and augmented-reality headsets.
https://wolvic.org
Mozilla Public License 2.0
813 stars 105 forks source link

HVR uses the local space for determining aim's pose #1330

Closed javifernandez closed 7 months ago

javifernandez commented 7 months ago

The Chromium backend expects the aim's pose to be determined based on the grip space. However, the pose returned by HVR OpenXR runtime has an invalid orientation bit, so our code assume there is no controller available. This problem causes that there is no way of dismissing the interstitial screen an entering the webxr session, as described in the issue #1329.

This PR tries to workaround the issue by forcing the use of the local space in HVR devices, even that we know Chromium expects to be based on the grip space.

Fixes #1329

svillar commented 7 months ago

If we know that the orientation bit is invalid why don't we change it instead of this change?

javifernandez commented 7 months ago

If we know that the orientation bit is invalid why don't we change it instead of this change?

The position bit is also invalid. I think the XrSpaceLocation we get, when using the grip as base space for the pointer, is invalid.

This is what we are getting with the 6DoF controllers while in presenting the interstitial screen:

position -> {valid: 0 - 0.000000, -307459761398165274624.000000, 0.000000} / orientation-> {valid: 0 -  0.000000, -1582238776387376632561664.000000, -705138368.000000, 0.000000}

And this using just the mobile accelerometer, which I guess emulates the 3DoF controller:

position -> {valid: 0 - 18886460541891018886655680446464.000000, 0.000000, 4527483342094348582912.000000} / orientation-> {valid: 0 -  4544201040203939239073677312000.000000, 297585212968491507143692779520.000000, 77764917387829018108613185503232.000000, 4096288358400.000000}