# Continuous rotation?

I am attempting to write a game which involves a ball which rolls around the playing area. To do this I set up a display list to store the ball, then in my drawing routine I call glCallList (ball); after some transformations to get the ball in the right place, I then reload the Identity matrix and get on with drawing the rest of the scene.

``````glTranslatef (ballX, -0.5, ballZ);
glCallList (ball);
``````

I am now trying to make it rotate so the following code must be used:

``````glTranslatef (ballX, -0.5, ballZ);
glRotatef (some rotation);
glCallList (ball);
``````

to find ‘some rotation’ I must somehow accumulate all of the previous rotations and then add the one for the current motion. How can I do this?

Ok first you are going to have to split the translation into 2 translations. First one being (0, -0.5, 0). Then apply the rotation. For that, I’d just use quaternions. I’d create a quaternion for the increment and just add it to the previous total quaternion. Then to do the rotation, you just convert the total quaternion into a rotation matrix and multiply your view matrix by that rotation matrix. Then finally complete the translation, using (ballX, 0, ballZ). I might have the translations wrong, I’m just guessing where your balls object origin is, and where the floor is.

[This message has been edited by DFrey (edited 09-20-2000).]

> Ok first you are going to have to split the
> translation into 2 translations.
Why? - The translation appears to work if I just do one rotation (without the sumation of them all).
> First one being (0, -0.5, 0). Then apply
> the rotation. For that, I’d just use
> quaternions.
QuŽ
> I’d create a quaternion for the increment
> and just add it to the previous total
> quaternion.
I am guessing that what you mean is create a 4x4 matrix and keep on pre multiplying it with the rotation matricies that I generate from the ball moving, the problem that I found with this was that there was no way of getting hold of the rotation matrix in the first place.
> Then to do the rotation, you just convert
> the total quaternion into a rotation matrix
> and multiply your view matrix by that
> rotation matrix. Then finally complete
> the translation, using (ballX, 0, ballZ). I
> might have the translations wrong, I’m
> just guessing where your balls object
> origin is, and where the floor is.
The floor is a quadrilatiral defined as:

glTexCoord …
glNormal …
glVertex3f (-1.0, -0.5, -1.0);

glVertex3f (1.0, -0.5, -1.0);

glVertex3f (1.0, -0.5, 1.0);

glVertex3f (-1.0, -0.5, 1.0);

Any more explanation would be much appreciated.

Originally posted by tdavie:
> Ok first you are going to have to split the
> translation into 2 translations.
Why? - The translation appears to work if I just do one rotation (without the sumation of them all).

Because I was assuming your floor was at 0 on the y axis and that your ball’s center was not coincident with the origin in its object space. So the first translation was to move the ball’s center to the origin. So since the ball’s center is at the origin of object space, you’ll only need to translate it once. And then rotate it.

I am guessing that what you mean is create a 4x4 matrix and keep on pre multiplying it with the rotation matricies that I generate from the ball moving, the problem that I found with this was that there was no way of getting hold of the rotation matrix in the first place.

Not quite, I literally mean use quaternion math to keep track of the ball’s rotational orientation. Do a search of the board for quaternion’s and you should find a good deal of information about them. You would use the total quaternion to create the rotation matrix.
You could do it with Euler angles too, but I feel the quaternion approach would in the end be more elegant and useful.

[This message has been edited by DFrey (edited 09-21-2000).]

I don’t know about using quaternions over euler angles, cause euler angles are easy to understand, whereas most people have a hard time understanding quaternions

Quaternions may be a bit harder to understand and are virtually impossible to visualize. But that doesn’t preclude it from being the best way. With Euler angles you have to deal with the possibility of gimbal lock, usually with a hack. Not so with quaternions, as they do not have that problem.