Archive

Welcome to my series of blogs about Eulers and Quaternions! This is part 2/2 of the series. See part 1 here. This series aims to talk about some of the difficulties that I’ve had in dealing with Euler <-> Quaternion transformations. In part 1, I talked about the difficulties around finding a transformation from Quaternion to Euler given a non-standard order of operations in the Euler and what it takes to actually derive the equations required to perform that transformation. We left off with equations that were useable; they did not however take into account the rotational singularities at the poles. For the unfamiliar, Euler rotations introduce two singularities into the space of rotations at the north and south poles of the rotation globe. As the Pitch approaches +90 or -90 degrees, the Yaw and Roll components degenerate further and further into a single rotational axis. This is known as gimbal lock.

As can be seen, the quickest way to detect for a singularity is to check if the Pitch component is +/-90. As detailed here (section Singularities), we can efficiently detect this by reusing our equation for pitch:

Θ, pitch: asin(-RPY12) = asin(2(q0q3 – q1q2))

Given the fact that at +/-90 degrees, sin(Θ) = 1/-1:

1 = 2(q0q3 – q1q2), -1 = 2(q0q3 – q1q2)

0.5 = q0q3 – q1q2, -0.5 = q0q3 – q1q2

So test = q0q3 – q1q2

If test is less than -0. 4999999 then we can assume a pitch of -90; if test is greater than 0.4999999 then we can assume a pitch of 90. We have a choice for what we could do with the degenerated yaw/roll rotational axis when a singularity is detected. Following in the footsteps of euclideanspace, I chose to put all rotation into the yaw. This means that we can assume an angle of 0 for roll. Applying all of this through our previous equations, we get:

When test > 0.4999999:

Φ, roll: 0

Θ, pitch: 90

Ψ, yaw: 2 * Math.atan2(q3, q1)

When test < -0.4999999:

Φ, roll: 0

Θ, pitch: -90

Ψ, yaw: -2 * Math.atan2(q3, q1)

You can get a better feel for this by following the derivation on the euclideanspace page. We now have a complete chain to convert a quaternion into a Y-Up Euler rotation! What’s nice about this is that we can now transform any order-of-operations Euler rotation into any other order-of-operations Euler rotation by transforming the first Euler representation into a quaternion then deriving the equations for getting an Euler rotation back from a quaternion with the second Euler representation. ie Roll, Pitch, Yaw into Yaw, Roll, Pitch, etc…

Hopefully this helps somebody out there because it sure as hell stumped me when I initially ran into this problem. Thank you for reading.

In part one of this series, I talked about scaling objects in the local reference frame and why that process is relatively simple. In this post, I will be introducing scaling in the world reference frame as well as detailing some of the differences between the two types of scaling. I will also be detailing some of the complexities as well as a possible implementation.

World reference frame scaling is somewhat more complex when compared to scaling in the local reference frame. As the name implies, this method scales an object against the world reference frame. This is not as simple as it sounds as there are some subtle complexities.

As an operation, scaling in the world reference frame is lossy if other operations such as move and rotate are performed between the scale operations. This is somewhat similar to rotating an object in 3D. In 3D rotation, rotating an object about a set of axes in some order produces a certain result where changing that order would change the final result. When scaling against the world reference frame, one needs to keep in mind that the object may rotate or scale imbetween operations while the world reference frame remains fixed. When scaling groups of objects against the world reference frame, it is also expected that the difference between their positions and the position of the centroid of the group will also scale in the same way as the objects themselves. This does not map very well to the independent transform controls typically offered by most 3D engines today; instead, we will most likely have to create and maintain our own transformation matrix, feeding that to the rendering engine on render time.

We would like to allow the user to scale an object or groups of objects in local and in world reference frames. A relatively simple way to implement this is by storing all transformations in a single transformation matrix. To retrieve the axes for scaling in local reference frame, the transformation matrix is decomposed and the rotation component is used to compute the three axial vectors. In world reference frame, decomposition is not required as the axial vectors are simply the unit vectors of the world’s reference frame ([1,0,0], [0,1,0], [0,0,1] respectively). In either case, the scale is applied by calculating a scale matrix from the axial vectors and some specified scale amount. The scale matrix is then applied to the current transform matrix thereby giving us the object’s new transformation matrix.

This is how an object is scaled in the world reference frame.

This implementation requires that scale and rotation be stored as a combined transform matrix. A side-effect is that scaling in the world reference frame may change rotation. I was against this idea initially as it felt like the “purity” of independent scale and rotation values is being lost, not to mention the performance hit of the frequent matrix compositions and decompositions. Having said that, I don’t think that there is another way for this to be done. Not to mention that scaling in the world reference frame against an arbitrarily rotated object is essentially a skew operation. Comments from more experienced hands on this subject would certainly be appreciated.