Euler angle rotations

Started by
16 comments, last by rumblesushi 10 years, 5 months ago
First, rotate alpha around the z axis, then rotate beta around the new y', finally rotate gamma around the new z''.

How would you accomplish this? I know how to do rotations around the X, Y, Z axis, but those are not applicable in this case other than the inital rotation right? It's the rotations around the "new" axis that are throwing me off.

Advertisement

Bit difficult to say when you don't provide a link for the quote or any context...

Normally you pick a rotation axis order (e.g. XYZ or ZYX) and write a function which converts Euler angles into a matrix, by directly multiplying the X Y and Z rotation matrices and doing the algebra.

Euler angles are pretty bad except for certain situations though (gun turrets that can rotate and look up and down, or characters rotating and looking up/down in an FPS). Otherwise use quaternions.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

"You will eventually regret any use of Euler angles." -John Carmack

Part of my assignment:

Parameters of the rotation have been pre-calculated and stored in an attached data file (el1_sh.txt). In the file, the 1st column is timestamp and the rest three columns specify Euler angles of rotations: the 2nd column is alpha, 3th column is beta, 4th column is gamma. There are several definitions of Euler angles. The Euler angle definition used in the file is: First, rotate alpha around the z axis, then rotate beta around the new y', finally rotate gamma around the new z''.

In this assignment, you are asked to animate this series of rotation.

So I need to produce a transformation matrix for these rotations

These kinds of rotation matrices can't give me rotations around the "new" y' and z'' can they? aren't they only relative to the x, y and z of my coordinate system?

2851c9dc2031127e6dacfb84b96446d8.png

You pick the order in which to rotate and then always multiply in that order. You can simplify it by doing the multiplication by hand and then do it in a function. You only need 1 function since you always use the same rotation order.

Carmack is right though.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

http://wolfr.am/1cjQWiv

Does that look right?

I would just go ahead and try it but I have no idea how my end result is supposed to look. All I can do is make sure I'm right on a theory level.

No, you used XYX so used the X rotation twice. Also you only need 3x3 matrices for rotations so don't bother with 4x4 for now (you need that for translations and perspective matrices though).

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley
z axis, then rotate beta around the new y', finally rotate gamma around the new z''

I used ZYZ, doesn't that match up to what that says?

Thanks for your input

ZYZ is possibly correct. I believe Proper Euler angles are like that, with the same first and last axis. Convert from that format to a sane one (matrices or quaternions) as soon as possible in your program and forget about angles.

I have no problem with Euler angles at all. I keep track of yaw, pitch and roll via simple euler variables and handle rotations in one of 2 ways.

Either incrementing an orientation matrix each time one of the rotations changes (matrix.arbitraryRotation(yaw-oldYaw) for example), or construct a new quaternion from scratch using my 3 euler angles each frame. For 6dof objects, that have constantly changing pitch, yaw, and roll - I've found the quaternion from scratch method to be the best and fastest.

For my car rotations, my euler angles for pitch and roll are simply the angles calculated from road raycasts of the front and back wheels, and left and right wheels respectively.

To be honest I'm not really sure how you could get away with not using euler angles at all. Maybe for something like a plane game for example, where the player just manually increments all axis rotations, and you don't need to calculate euler angles between points?

In all the games I've developed euler angles have seemed essential.

Normal car attitudes are very far from the region where Euler angles behave poorly (see gimbal lock). A car is essentially on a horizontal plane, which means that yaw captures most of what's going on. For instance, cars don't usually roll over. Interpolating between attitudes by interpolating Euler angles, for instance, behaves very poorly in general, but for a car you can just interpolate the yaw (making sure you go the short way) and then roll and pitch are small angles anyway, so interpolating them works just fine.

What operation is it that you have a hard time imagining without Euler angles?

This topic is closed to new replies.

Advertisement