Regression introduced in r144, re: WebXRManager.updateCamera

[tom-adsfund]

Description

My app scales up changes in the position of the XR camera to apply to a "user's head" object that operates in a much larger world. It's a simple .multiplyScalar(10000) on the delta of the position of the camera after it's been updated via updateCamera.

I was upgrading from an older release, and noticed that the movement of this scaled position was broken: it would kind of shrink and grow. I used a bisection search on the releases, and narrowed the bug down to release 144.

The change I think is causing the problem is from #22362 which moved to using camera.matrix.decompose( camera.position, camera.quaternion, camera.scale ) instead of simply copying it from the cameraVR, as it did before. This presumably introduces error, unlike the straight copy, and hence the bug I've outlined above introduced to my app. This have shuffled around since then in WebXRManager, but the use of decompose has remained, and so has the bug.

Reproduction steps

The logic above should explain the issue.

Code

Issue created via this change: #22362

Live example

No.

Screenshots

No response

Version

r144-165

Device

No response

Browser

No response

OS

No response

[tom-adsfund]

Actually it might be that: camera.matrixWorld.copy( cameraVR.matrixWorld ); was removed in that same commit, without adding any corresponding action. See r143...r144 WebXRManager.js

[Mugen87]

The previous approach was definitely wrong since it prevented to correctly add the XR camera to another object. The result was all getWorld*() methods executed with a camera were broken.

It's a simple .multiplyScalar(10000) on the delta of the position of the camera after it's been updated via updateCamera.

Can you try to add the XR camera to an instance of THREE.Group and then modify the group instead?

[tom-adsfund]

Yes, the camera has always been part of a Group.

My assumption is the following:

The XR camera gets updated using the updateCamera method. This alters the local position within the Group (and also the world position taking into account the Group's state).

But I'm only interested in the local position, because that's effectively an unaltered positioning of the camera in whatever is normalized XR space.

So I take the xrcamera.position before and after updateCamera, and use the delta between them to alter the position of the userHead.

The userHead is attached to the Scene without any other alteration, so any multiplied delta applied to its local position should just move it around as if just a multiplied normalized XR space.

But now that you've confirmed there should be nothing wrong on your side, I'll check more on my side because there might be an issue due to a rotation on userHead.

[tom-adsfund]

Yep, the previous way allowed me to do it incorrectly. With the correct setup, I need to rotate the delta.

Thanks so much for this amazing platform!