Right handed camera is flipped when parented

[CrashMaster]

Hey there,

I upgraded my dependencies recently and came accross this breaking change which makes right handed target cameras rotation flipped on the Y axis when using a right handed system:

Breaking change in target camera rotations when using right-handed system

Starting with version 8.10.1, any code that modifies the rotation or rotationQuaternion property of a target camera when the scene is in right-handed system (i.e., scene.useRightHandedSystem = true) will behave exactly 180° flipped on the Y axis than before. This is due to a bug with the target camera code that fails to take the handedness of the scene into account. See RH camera fixes by bghgary · Pull Request #16691 · BabylonJS/Babylon.js for details. For additional back story, we ran into th…

This creates 2 issues for my setup of a camera parented to a TransformNode:

• Camera rotation with mouse is inverted on the Y axis => I fixed it by inverting the camera quaternion x component
• Camera is not pointing in the same direction as its parent

For the second issue, I made the following PG. The idea is to transfer the rotation quaternion of the camera to its parent every frame to ensure the transform and camera forward direction are aligned. It works in left handed, but in right handed, the camera forward is the opposite of the transform forward

Babylon.js Playground

Any idea what I could be missing to flip it around?

I have tried adding an additional PI around the Y axis to turn it around, but it did not work:

Babylon.js Playground

[bghgary]

I will investigate soon. Thanks for the report!

[bghgary]

@CrashMaster

Camera rotation with mouse is inverted on the Y axis => I fixed it by inverting the camera quaternion x component

This is a bug. I have a PR out to fix it, but I need to test it a bunch and maybe add some tests before it can be merged.

@CrashMaster

For the second issue, I made the following PG. The idea is to transfer the rotation quaternion of the camera to its parent every frame to ensure the transform and camera forward direction are aligned. It works in left handed, but in right handed, the camera forward is the opposite of the transform forward

This one is trickier. In RH, the camera at identity rotation faces -Z. In order to make everything work, we have to move all the objects to the other side of Z. In addition, the transform node’s lookAt function assumes +Z is forward. We can maybe add a parameter for this, but for now, it needs to be updated by hand to match what an RH camera would do. Here is a PG with the bug fix from the PR that works in both LH and RH:
https://playground.babylonjs.com/?snapshot=refs/pull/16849/merge#6XB1RH#12. Let me know if you have any questions.

[bghgary]

I also want to point out that transferring rotations from a child to parent will cumulate errors in the long run due to floating point imprecision. If the goal is to put the camera rotation on a transform node instead of the camera itself, it might be better to introduce custom camera input code.

[CrashMaster]

Thanks for investigating! So the transform lookAt working in RH in previous versions was a bug if I understand correctly?

I don’t mind the additional quaternion multiplication, it works for me

@bghgary

In addition, the transform node’s lookAt function assumes +Z is forward. We can maybe add a parameter for this, but for now, it needs to be updated by hand to match what an RH camera would do

As the transform has a reference to the scene, it can get the scene handedness without the need for an additional parameter maybe

@bghgary

transferring rotations from a child to parent will cumulate errors in the long run due to floating point imprecision. If the goal is to put the camera rotation on a transform node instead of the camera itself, it might be better to introduce custom camera input code.

My goal is to have a camera that can move with 6 degrees of freedom while retaining the nice controls of the BJS camera so I ended up with this ^^ If you know a better way of implementing this kind of movement I am interested

[bghgary]

@CrashMaster

So the transform lookAt working in RH in previous versions was a bug if I understand correctly?

lookAt assumes a convention of +Z forward. I’m not sure I would consider this a bug. It’s just a convention that doesn’t match the camera.

@CrashMaster

As the transform has a reference to the scene, it can get the scene handedness without the need for an additional parameter maybe

I’m not sure that’s the right thing to do. It will be another breaking change if we do it, so we have to be careful.

@CrashMaster

My goal is to have a camera that can move with 6 degrees of freedom while retaining the nice controls of the BJS camera so I ended up with this ^^ If you know a better way of implementing this kind of movement I am interested

Maybe you can use the upVector for the Z rotation? Babylon.js Playground

[CrashMaster]

@bghgary

lookAt assumes a convention of +Z forward. I’m not sure I would consider this a bug. It’s just a convention that doesn’t match the camera.

I find it a bit weird that in RH, lookAt does not “look at” the given position and instead “looks away” Maybe we could have a lookAtRightHanded function instead that works for RH?

@bghgary

I’m not sure that’s the right thing to do. It will be another breaking change if we do it, so we have to be careful.

I was just thinking out loud, let me know if you change something

@bghgary

Maybe you can use the upVector for the Z rotation? Babylon.js Playground

As you can see in your PG, rotating the up vector does not update the rotation axis of the camera for mouse inputs, which is another reason why I use the parent transform:

[bghgary]

@CrashMaster

I find it a bit weird that in RH, lookAt does not “look at” the given position and instead “looks away” Maybe we could have a lookAtRightHanded function instead that works for RH?

It doesn’t look away, it changes the node such that +Z points at the target in both LH and RH. It appears to look away for this scenario this because the camera faces -Z. It’s a conventions issue. I agree it’s not super consistent though.

@CrashMaster

As you can see in your PG, rotating the up vector does not update the rotation axis of the camera for mouse inputs, which is another reason why I use the parent transform:

I see. We can maybe alter the camera input math in core with a flag or use custom inputs.

[CrashMaster]

@bghgary

It doesn’t look away, it changes the node such that +Z points at the target in both LH and RH. It appears to look away for this scenario this because the camera faces -Z

Thanks for the clarification, it makes sense ^^

@bghgary

I see. We can maybe alter the camera input math in core with a flag or use custom inputs.

Probably yes, but that seems like a lot of effort for a use case that is not often used, hence using a parent transform to take care of this complexity

[bghgary]

@CrashMaster

Probably yes, but that seems like a lot of effort for a use case that is not often used, hence using a parent transform to take care of this complexity

Sure, it just has problems. Try moving the camera in the playground of the OP back and forth a bunch of times. It will eventually start drifting.

[CrashMaster]

@bghgary

It will eventually start drifting.

True, but you could also say I accidentally implemented a trackball camera