Camera Rotation by PI / 2

In an instance where I rotate the camera by PI/2 about the x-axis via a keyframe animation (x-y plane is the screen plane), it inadvertently appears to be also snap-rotate by PI/2 about the y-axis (y axis now out of the screen) once the animation completes. When making it rotate ever so slightly less than PI/2 (say - 0.0001), it behaves as expected.

camera.rotation starts at 0, pi, 0

I couldnt get it to do the strange behavior in the playground so I’m doubly confused.
I know that this isn’t a great deal to go on, but if anyone has any ideas as to what might be causing it I would love to hear them.

From my project code (there’s a lot more to it than this just to be clear–but these are the parts directly concerned with the rotation animation in question):

var  targetViewRot = new BABYLON.Vector3( ( Math.PI / 2 - 0.0001), Math.PI, 0); //look down
var viewChangeRot_keys = []; 
                frame: 0,
                value: camera.rotation
                frame: animFrameRate,
                value: targetViewRot

 scene.beginDirectAnimation(camera, [viewChangeRot], 0, 1*animFrameRate, false);

Playground test:

@Floppykittenear first of all apologies for an answer taking too long. Possibly so many questions being asked yours got pushed down.

You are able to see the effect your are talking about in a playground, eg Babylon.js Playground

Image on left is rotation about X axis of PI/2 and on the right a rotation of Math.PI / 2 - 0.000001


This is a technical issue see the line just below the arcRotateCamera image here Cameras - Babylon.js Documentation

It is to do with the target direction being in line with the camera’s upvector. When rotation about x axis is PI / 2 the camera’s direction is in line with (0, 1, 0) the default upvector.

The simplest solution for you is not to allow the x rotation to be exactly PI / 2.

In the following playground the camera’s up vector is set in line with the z axis and you can see that the rotation does not flip around at the end as camera direction and upvector are not in line. However if in this PG you use the mouse to move around the scene the image flips around with the mouse movements. This is because the upvector is no longer in line with our expectation of what up should be.

1 Like

That’s all right-- there’s a lot to be worked on in the project. Thanks for the reply!

So in that playground, I believe I get the same result when the rotation is PI/2 and slightly less (upVector being different seems not to matter):
image image
and both do a small snap when you use the mouse to move around (upVector present or not appears to not make a difference)

I wonder if perhaps correcting the upVector after the animation finishes will fix the issue in our project…

(This is on our MacOS Google Chrome workstation.)

I may be saying something stupid, but isn’t a Gimbal Lock problem?
It might worth trying to animate the quaternionRotation property rather than the rotation property.

Check this page out: Euler Angles and Quaternions - Babylon.js Documentation

You will be mostly interested in the paragraph Euler Angles to Quaternions.

@Nodragem is correct. Remember that in Euler angles (pitch, roll, yaw) -180 degrees is the same orientation as 180 degrees on a single axis. So once you pass 180 degrees in either direction, the camera will flip. However, if you work in Quaternions, you can rotate endlessly on any axis.

Here’s a topic from the old forum that covers many aspects of working in Cartesian space. If you’re not familiar with this, I recommend spending some time reviewing this topic. However, I just saw an error I made where I wrote the limits in Euler angles was -90 to 90 degrees. I used to write posts in the middle of the night (like tonight), and I can’t believe no one caught it.

Here’s the topic:


1 Like

So are there any downsides to using Quaternions to do the rotations instead using say
var abcQuaternion = BABYLON.Quaternion.RotationAlphaBetaGamma(alpha, beta, gamma); ?
I was doing some reading on the topic and it was suggested that it may also be computationally more efficient to be dealing with Quaternions rather than the Euler angles as well, which if true would make a pretty compelling case for using Quaternions instead.

I’ll probably test out changing the rotation to be Quaternion based once I revisit this aspect of the project (its in a brainstorming phase and familiarity phase so everything can change still).

I personally find only advantages using Quaternions as opposed to Euler angles.


1 Like

The only disadvantage is that most human beings find them less intuitive ^^