Documentation of Euler angles conversions

[patrikhuber]

Hi!

Please correct me if I'm wrong. In general, glm seems to adhere to the XYZ convention for Euler angles, meaning you'd left-multiply a column vector to get the rotated vector, like so: [u_n, v_n, w_n]' = X*Y*Z*[u, v, w]'. But in general it doesn't say very often in the documentation which convention exactly glm follows. Sometimes one can guess from the function name.

But take for example glm::eulerAngles(glm::quat q):

float pitch = glm::radians(10.0f); // x axis
float yaw = glm::radians(30.0f); // y axis
float roll = glm::radians(20.0f); // z axis
auto xyz_mat = eulerAngleXYZ(pitch, yaw, roll);
quat q(xyz_mat);	
auto angles = glm::eulerAngles(q); // Quat to angles. pitch yaw roll.
float t1_x, t2_y, t3_z;
glm::extractEulerAngleXYZ(xyz_mat, t1_x, t2_y, t3_z);

The angles in angles are very different from the original angles. glm::extractEulerAngleXYZ however works correctly and returns the same angles. But in what convention are the angles that glm::eulerAngles(q) returns? I can't find it in the documentation. Or maybe I'm having a misconception about the topic at hand?

Apart from that, isn't the documentation ambiguous - if you only say it follows the convention X*Y*Z, it would be either row_vec*X*Y*Z or X*Y*Z*col-vec, which would result in a completely different rotation?

Additionally I have another small question: Is the XYZ (and YXZ) kind of the standard in OpenGL? I have seen the convention ZXY (which would be R*P*Y (roll-pitch-yaw)) applied much more - in fact I think I even remember hearing that RPY is some kind of MPEG or ISO standard convention. In any case I think it would be nice to have a function eulerAngleZXY here.

[Groovounet]

I totally expect that most of the euler angles stuff is inconsistent / broken. All the stuff in GTX area is basically not tested, potentially broken over time. So for most of it I would say: I don't know / don't remember, \o/

Using standard conversions would be great but my recollection is that what I added was what I needed following the coordinate system I was using. My assumption is that people who needed features did sort of the same. I am not sure how convenient it can be to convert from a convention to another.

Well, it sounds like a lot of work so I labeled it enhancement. PR welcome! :D

[CuriousRubick]

I use the following to extract euler angles from matrices. The angles match those returned from glm::eulerAngles(QuatToConvert).

glm::vec3 ConvertMatToEulerAnglesXYZ(const glm::mat3& mat)
{
	const float xEuler = std::atan2(mat[1].z, mat[2].z);
	const float cosYangle = glm::sqrt(glm::pow(mat[0].x, 2) + glm::pow(mat[0].y, 2));
	const float yEuler = std::atan2(-mat[0].z, cosYangle);
	const float sinXangle = glm::sin(xEuler);
	const float cosXangle = glm::cos(xEuler);
	const float zEuler = std::atan2(
		sinXangle * mat[2].x - cosXangle * mat[1].x,
		cosXangle * mat[1].y - sinXangle * mat[2].y);

	return glm::vec3(xEuler, yEuler, zEuler);
}

I found the function here: https://d3cw3dd2w32x2b.cloudfront.net/wp-content/uploads/2012/07/euler-angles1.pdf (Mike Day, Insomniac Games)

[cofenberg]

I'am using for over a decade the following: Matrix <-> Euler Angles <-> Quaternion by Ken Shoemake, 1993: http://www.realtimerendering.com/resources/GraphicsGems/gemsiv/euler_angle/

Pretty stable and one can use the conversion one needs.

Switched to GLM years ago for math functionality, but sadly still having to use my own Euler angles class basing on the reference above.

[PymZoR]

Any updates on this ?

[doublerebel]

As mentioned on stackoverflow, Mike Day's method

is also now implemented in glm, as of version 0.9.7.0, 02/08/2015

in commit jzrake/glm@d3313421 . We can see that this is the same method as @CuriousRubick . Mike Day's method has less edge cases than Shoemake's, I do not expect that it is "broken".

I arrived here looking for an open-source implementation of Day's method, as OpenCV is still using Shoemake's. OpenEXR has a separate variant that is functionally the same but appears to predate Day's, the blame goes back to at least 2006. The OpenEXR implementation claims to be based on Shoemake's GemsIV but clearly has been updated to use rotation instead of testing for minimal value.

Both OpenEXR and Shoemake's code provide good examples of supporting varied axis ordering. Also, I think OpenEXR's header commentary is a good example of documenting the axis ordering.

Thanks all for your work and discussion which lead me to these implementations.

EDIT 19-Dec: Through related research, I discovered this relevant discussion in KhronosGroup/glTF#144 (repo for GL Transmission Format) regarding the origin of the ILM OpenEXR implementation:

In Imath, https://github.com/openexr/openexr/blob/master/IlmBase/Imath/ImathEuler.h , we provided all 24 valid Euler representations because we found over the years that artists would choose the right one for their task at hand. Autodesk made a similar choice. http://download.autodesk.com/us/maya/2010help/API/class_m_euler_rotation.html

[passerby007]

when using euler angles, it does not certainly have the correspondence: (pitch, yaw, roll) == (x, y, z);

seems glm follows the z-y-x convention.

so in short, you can try this:
auto xyz_mat = eulerAngleZYX(roll, yaw, pitch);

then:
glm::eulerAngles(q)

should return the correct results;