We were getting an incorrect pose when starting WebXR experiences. The front was rotated 90 or 180 degrees on the Y axis. The position was also a bit ankward, not definitely at the origin of coordinates. The problem was that mojo_from_floor was computed as the location of the stage space from the local space. In order to do that
we were basically inverting the sittingToStandingiTransform which is precisely the opposite, the location of the local space from the stage space. That should be fine but it looks like it is not what the Chromium WebXR code expects.
That's why we decided to switch that to what ARCore backend does which is to only use the Y coordinate. In theory that should be actually the only difference between local and stage at least before moving.
We were getting an incorrect pose when starting WebXR experiences. The front was rotated 90 or 180 degrees on the Y axis. The position was also a bit ankward, not definitely at the origin of coordinates. The problem was that mojo_from_floor was computed as the location of the stage space from the local space. In order to do that we were basically inverting the sittingToStandingiTransform which is precisely the opposite, the location of the local space from the stage space. That should be fine but it looks like it is not what the Chromium WebXR code expects.
That's why we decided to switch that to what ARCore backend does which is to only use the Y coordinate. In theory that should be actually the only difference between local and stage at least before moving.