I notice it said that the walking thing first examples work ok on a plane, but I had to strip out the y coordinate for even a plane. This was(I assume) because even though it might have been on the plane it was still above the plane to some extent. That confused me for a little while.
Sterra

# Rotations in three dimensions don't commute!

As a simple example take your right hand, point rightwards with your thumb and upwards with your forefinger. Thumb and forefinger now forms an "L". This is the initial position.

Rotation A: Rotate your hand 90 degrees around the axis from right to left. Applied to the initial position, your thumb still points rightwards, but your forefinger points away from you. In any representation this would be "A*L".

Rotation B: Rotate your hand 90 degrees around the axis from top to buttom. Applied after you applied rotation A to the initial position, your forefinger points rightwards and your thumb points at the person that will soon understand that rotation order matters in three dimensions. In any representation this would be "B*A*L".

Of course now we do the rotations the other way round. "B*L" results in the forefinger still pointing upwards and the thumb pointing at you. "A*B*L" results in the thumb pointing upwards and the forefinger pointing away from you. This is the symbolic gun used to shoot at any claim like:
"Quaternions avoid the problem of rotation ordering."
or
"With quaternions we can apply multiple rotations simultaneously allowing them to transform the same coordinate space. Thus the order does not matter."
as in the article.

reimpell 05:05, 13 Jun 2005 (CDT)

Agreed. Your quotes were from a prerelease draft of the article, before I had all of my facts straight. I hope it is correct now.

discipline 17:16, 16 Jun 2005 (PDT)

Great Tutorial!! But when you say:
Vector3 src = mNode->getOrientation() * Vector3::UNIT_X; // Orientation from initial direction

I think to get the orientation we must to use Vector3::-UNIT_Z, if you use Vector3::UNIT_X the mesh
is allways walk rigth sided!! i think that the mesh that you test it's not aligned to world
when been exported, all my test have been done with ninja.mesh

- Liaven

Perhaps it should be UNIT_Z which is the facing direction of the camera. However as it is, UNIT_X is the facing direction of the Robot.mesh. At the beginning of that section I have a note, "See (1)" in the code that references this just below it:

``` (1) ...Multiplying it by UNIT_X, which is the objects initial facing position in this case,
provides a vector describing its current facing direction.```
- discipline

45 online users