-
-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebXR experiences appear rotated 90 degress to the left #1522
Labels
Comments
Vision Glass only right? |
right |
svillar
added a commit
that referenced
this issue
Sep 3, 2024
Controller orientation was suffering from gimbal lock. This means that rotations higher than 90º started to exhibit weird behaviours like inverted or swapped axis. We tried to fix that in the past without much success, but now we do now the actual culprit of that gimbal lock and can fix that once for all. The quaternion returned by the phone sensor is using Android axis. If the phone is on a table in horizontal position and portrait orientation with respect to the user, X goes right, Y goes forward and Z goes up. However in our world coordinates, X goes right (same) but Y goes up and Z goes backward (-Z is forward direction). So we have to transform the quaternion to follow that coordinate system. Once that was fixed gimbal lock dissappeared. The only missing thing was to fix the calibration code removing some workarounds we had to add to get it "working" with the previous incorrect version of the orientation code. Last but not least, we changed the sensor delay from NORMAL to GAME to get a little bit more accuracy in tracking. As nice side effect this also fixes orientation issues when entering WebXR experiences. Fixes #1522
svillar
added a commit
that referenced
this issue
Sep 3, 2024
Controller orientation was suffering from gimbal lock. This means that rotations higher than 90º started to exhibit weird behaviours like inverted or swapped axis. We tried to fix that in the past without much success, but now we do now the actual culprit of that gimbal lock and can fix that once for all. The quaternion returned by the phone sensor is using Android axis. If the phone is on a table in horizontal position and portrait orientation with respect to the user, X goes right, Y goes forward and Z goes up. However in our world coordinates, X goes right (same) but Y goes up and Z goes backward (-Z is forward direction). So we have to transform the quaternion to follow that coordinate system. Once that was fixed gimbal lock dissappeared. The only missing thing was to fix the calibration code removing some workarounds we had to add to get it "working" with the previous incorrect version of the orientation code. Last but not least, we changed the sensor delay from NORMAL to GAME to get a little bit more accuracy in tracking. As nice side effect this also fixes orientation issues when entering WebXR experiences. Fixes #1522
svillar
added a commit
that referenced
this issue
Sep 5, 2024
Controller orientation was suffering from gimbal lock. This means that rotations higher than 90º started to exhibit weird behaviours like inverted or swapped axis. We tried to fix that in the past without much success, but now we do now the actual culprit of that gimbal lock and can fix that once for all. The quaternion returned by the phone sensor is using Android axis. If the phone is on a table in horizontal position and portrait orientation with respect to the user, X goes right, Y goes forward and Z goes up. However in our world coordinates, X goes right (same) but Y goes up and Z goes backward (-Z is forward direction). So we have to transform the quaternion to follow that coordinate system. Once that was fixed gimbal lock dissappeared. The only missing thing was to fix the calibration code removing some workarounds we had to add to get it "working" with the previous incorrect version of the orientation code. Last but not least, we changed the sensor delay from NORMAL to GAME to get a little bit more accuracy in tracking. As nice side effect this also fixes orientation issues when entering WebXR experiences. Fixes #1522
felipeerias
pushed a commit
that referenced
this issue
Sep 10, 2024
Controller orientation was suffering from gimbal lock. This means that rotations higher than 90º started to exhibit weird behaviours like inverted or swapped axis. We tried to fix that in the past without much success, but now we do now the actual culprit of that gimbal lock and can fix that once for all. The quaternion returned by the phone sensor is using Android axis. If the phone is on a table in horizontal position and portrait orientation with respect to the user, X goes right, Y goes forward and Z goes up. However in our world coordinates, X goes right (same) but Y goes up and Z goes backward (-Z is forward direction). So we have to transform the quaternion to follow that coordinate system. Once that was fixed gimbal lock dissappeared. The only missing thing was to fix the calibration code removing some workarounds we had to add to get it "working" with the previous incorrect version of the orientation code. Last but not least, we changed the sensor delay from NORMAL to GAME to get a little bit more accuracy in tracking. As nice side effect this also fixes orientation issues when entering WebXR experiences. Fixes #1522
felipeerias
pushed a commit
that referenced
this issue
Sep 10, 2024
Controller orientation was suffering from gimbal lock. This means that rotations higher than 90º started to exhibit weird behaviours like inverted or swapped axis. We tried to fix that in the past without much success, but now we do now the actual culprit of that gimbal lock and can fix that once for all. The quaternion returned by the phone sensor is using Android axis. If the phone is on a table in horizontal position and portrait orientation with respect to the user, X goes right, Y goes forward and Z goes up. However in our world coordinates, X goes right (same) but Y goes up and Z goes backward (-Z is forward direction). So we have to transform the quaternion to follow that coordinate system. Once that was fixed gimbal lock dissappeared. The only missing thing was to fix the calibration code removing some workarounds we had to add to get it "working" with the previous incorrect version of the orientation code. Last but not least, we changed the sensor delay from NORMAL to GAME to get a little bit more accuracy in tracking. As nice side effect this also fixes orientation issues when entering WebXR experiences. Fixes #1522
felipeerias
pushed a commit
that referenced
this issue
Oct 21, 2024
Controller orientation was suffering from gimbal lock. This means that rotations higher than 90º started to exhibit weird behaviours like inverted or swapped axis. We tried to fix that in the past without much success, but now we do now the actual culprit of that gimbal lock and can fix that once for all. The quaternion returned by the phone sensor is using Android axis. If the phone is on a table in horizontal position and portrait orientation with respect to the user, X goes right, Y goes forward and Z goes up. However in our world coordinates, X goes right (same) but Y goes up and Z goes backward (-Z is forward direction). So we have to transform the quaternion to follow that coordinate system. Once that was fixed gimbal lock dissappeared. The only missing thing was to fix the calibration code removing some workarounds we had to add to get it "working" with the previous incorrect version of the orientation code. Last but not least, we changed the sensor delay from NORMAL to GAME to get a little bit more accuracy in tracking. As nice side effect this also fixes orientation issues when entering WebXR experiences. Fixes #1522
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Configuration
Wolvic version: 1.7.0
Wolvic build ID:
Hardware: VisionGlass
Steps to Reproduce
Current Behavior
The users's view is not centered with the experience's world
Expected Behavior
The game or experience world appears rotated 90 degrees to the left, based on the user's view
Possible Solution
Context
Error Logs and Stack Traces
The text was updated successfully, but these errors were encountered: