I’ve read through other teleportation discussions, but none of them quite cover this. I’m finding that the rotation while teleporting feature does not produce expected results in some browser device combos. These are reproducible in the basic teleportation example playground.
Oculus Quest 2 + Firefox Reality, Valve Index + Firefox desktop with experimental WebXR api enabled: when the rotation angle has been changed from default, you move to a different location than what the marker shows. To reproduce: teleport ahead while changing the rotation to be 180 degrees to turn yourself around. Try to teleport forwards again - you will instead move backwards the same distance and can continue to do this to teleport entirely off the map
Oculus Quest 2 + Oculus Browser: works great. No issues.
Valve Index + Desktop Chrome: After performing a teleportation with rotation change, the next teleportation will occasionally begin with the same rotation offset as the last teleport (as opposed to resetting to forwards as it does most of the time). In this case, the final teleportation will match what the marker showed, but it may not be a surprise to end up turning again when you did not alter the rotation the second time.
Edit: The issue persists in the Quest2/FFxR combo even with teleportation.rotationEnabled = false;. If you change your orientation with the rotation-in-place functionality and then try to teleport, you will not land where the marker predicts.
I don’t have a value index, but I will run a few tests in my MR device and an oculus rift I have lying around. Seems to be an issue with the rotation reset after teleporting was done, but I will have a better answer after testing. Seems odd that it seems to mainly happen in firefox. Might also be an issue with the way they deal with reference-space changes (which we are using to teleport).
Just an update - reproducible with my quest and firefox reality, I will still need to jump into a very interesting debug session Wil keep you updated here.
Re the Index, my best guess based on the experience would be that it’s caused by a deadzone on the index controller joystick that is preventing it from sending some bit of joystick data you are counting on to reset the teleport orientation
I had those kind of issues with the oculus controller as well (this is why i don’t use the “touched” flag to do the actual teleportation). Once I understand the issue on the quest, I will ask you to check on the index and see if it partly solves the issue.
-1 on z (one unit backwards, irrelevant to the current rotation),
rotate the camera 180 degrees,
+1 on z (technically - going back to my initial position)
rotate back 180 degrees on the y axis.
Expected results (4 steps, position .z):
-1
-1
0
0
The expected result is that I will return to my initial position. Firefox, however, goes completely crazy:
initial z value - 0. Afterwards (in those 4 steps):
-0.844
-0.844
0.217
-3.782
The only thing I understand from this is that firefox doesn’t take the previous reference point as the base for future transformations, but the initial reference point, so we are rotating here around a different axis. I will continue investigating, but if even mozilla’s webXR emulator works correctly, it feels like a bug in firefox’s webxr implementation itself…
Thanks for looking into this, @RaananW! I know FFxR can be hard to justify as a development target as it stands. FWIW I also checked out your example in FF Desktop with experimental WebXR enabled:
Using WebXR emulator extension: works perfectly
Using SteamVR with valve index: gets the same messed up results as Quest/FFxR
Since it’s behind an experimental flag I understand it’s also not really your problem, but just pointing out that it may be a bigger firefox bug than just FFxR
It is not my issue, but certainly is my problem
We want to support as many browsers as we can, but if a browser doesn’t fully support a basic functionality of the standard, it is very hard for us to solve this. I guess there might be a way around it (finding the point around which the browser rotates and calculate the new transformation), but I am not sure we want to do that. FF WebXR doesn’t even support antialiasing, so I won’t recommend anyone to target firefox users ATM.
Wil keep you updated here.