I never clicked the 90 degree buttons. Just the 45 degree ones. The default is the same (Well not quite, but seems to be quite simmiler) as the 90 Degree Y button. But in every case its rotating Localy. It only rotates globaly when you flip the rotation matrix's in the Multiply Matrix function.

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

If you did not use the 90 degree buttons then my effort to show you how it works was quite useless. You cannot expect a horse going forward if you ride it upside down.

The application is ment to setup the cube's rotation status by clicking one of the 90 degree buttons FIRST and AFTERWARDS one of the 45 deg buttons.

First it applys the 90 deg rotation and afterwards the 45 deg rotation and the only thing I wanted to show is that the outcome is as expected: two global rotations carried out one after the other.

For definition of local/global rotations see my explanations above.

With just the multiply matrix command you can only get one of the matrix's that you are adding together to rotate Globaly, the other one will always rotate Localy when you add to it. So i don't see how it would work for global rotation of objects.

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

This is not quite right. If you have Matrix1 and Matrix2 then you can choose:

Result1 = Matrix1 X Matrix2 or
Result2 = Matrix2 X Matrix1

And Result1 <> Result2

The only way i could see it working would be with 1 matrix which you continualy add rotation's to just like if you were applying directly to the vertex's each rotation but id imagine that it would still have noticabe errors. If thats what you intended for me to "get" then your implementation of building both matrix's with Angle's each time the app requests the matrix confused me.

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

Sorry, I did not want to confuse you. As you can see in the program, I do not always add rotations. There is a "reset"-method which comes back to the initial values (that are angle=0 and axis=Y-Axis) and so avoid the problem of instability.

At the moment I am reading a book about game physics, and concerning the problem of mathematical instability it reads:
"There is no definitive solution to this problem, but you can increase the accuracy of the mathematics being performed. In C++ you can switch from floats to doubles, which take up twice the amount of memory, take a little less then twice the amount of time to process, but have millions of times the accuracy."

In Delphi, this would mean switching from single to double.

Are you talking about instability caused by iterated rotations? For the absolute values of fields in rotation matrices are in range [-1,1] you actually won't have too much trouble, but the simple structure of rotation matrices allows easy "reconstruction". The columns (the same applies for the rows, so you choose) of the upper left 3x3 matrix of an rotation matrix build an orthonormal system; if you have, through successive rotation, created a matrix that is just roughly a rotation, then you can apply schmidt's orthonormalization on the three columns and put these orthonormalized ones back into a matrix, you will get a brand new rotation matrix. There is no need to do that often, once every couple of millions of iterations should do fine for graphic apps, even using single precision arithmetics; this would also ensure this trick to be performing fast.

And for usual physics simulations in games, most arithmetic errors won't hurt too much as the simulations (depending of course on that you choose suitable integration methods) are on single precision usually accurate enough to create a convincing view of the past events. Behaviour that feels wrong in longer terms is more a problem in scientific calculations.

I am actualy using Doubles(Both with Vertex's and Matrix's). When applying 45 Degree rotations(Only tested applying a rotation matrix to the actual vertex's each time a 45 degree rotation is required) to each axis(Multiple times) you eventualy get to a stage where you can't keep rotating the object to get back to its original rotation. Doubles don't change this.

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

It looks like this has nothing to do with mathematical instability. Maybe Gimbal lock? Do you use Euler Angles?

Assuming im interpreting the wiki page correctly(I assume that they are the angles between the default orientation of the world and the orientation of the world you wish to have) then im not. Currently im just making a rotation matrix using DEG2RAD(Angle) as the input (With Angle at 45 Degrees) and applying the rotation directly to the vertex's.

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

Hallo Stucuk,
Euler angles are one of several ways to define an object's orienation: You have three angles (one per axis) and you can get this orientation by applying three matrices, one after the other. I am sure you know that.

And I found a very short and good explanation of "Gimbal Lock" at this really excellent website: http://www.euclideanspace.com/maths/geometry/rotations/index.htm:

For exampe the poles of a sphere are such "certain points", and rotations take ALWAYS place on the surface of a unit sphere.

If you are rotating around some axis and run into Gimbal Lock your rotation practically "crashes". This is caused by the underlying mathematics. Remember the skydome with the singularity at the northpole.

So if you rotate only around the usual axes and furthermore use 45 degrees, the probability of Gimbal Lock is imho very high.

BTW, the above mentioned website contains very good info for someone who is interested in rotations.
Traude