# Matrix / transformation questions

## Recommended Posts

clashie    632
Ok, I'm new to the idea of matricies, but after skimming over some of the D3D documentation, I figured out a rough enough idea to implement the basic stuff. I think I have most stuff right, but I seem to be having a couple problems that I'm not entirely sure on. The projection seems correct for the most part, and I plugged in the numbers for a cube which seems to look right. I initially make a matrix for the 'world' and then translate it back 10z. I want to give the cube the illusion of rotating so I figured I could just rotate the world matrix. Just before I rotate it, I translate it back to 0, 0, 0. Then it gets rotated, and put back to 0, 0, 10. Looks fine... but after a while of rotating the cube seems to get squashed into nothing. Does anything look wrong here? http://www.mediafire.com/?mothhdzzf1r Sorry, I should have sped up the rotation. If you let it sit for a minute, you'll see what I mean. It starts to get skewed / squashed. What am I missing? I've been going off this page for the most part http://msdn.microsoft.com/en-us/library/bb206269(VS.85).aspx

##### Share on other sites
KulSeran    3267
Didn't even bother to look at the code. but the problem sounds familiar.
Constantly rotating a matrix is likely to screw it up. Floating point isn't perfect, and errors will build up fairly quickly in your matrix.

You can orthonormalize the matrix every frame (every few frames).
You can rotate with a quaternion (have to normalize that too, but it is cheaper).
You can store the rotation in axis+angle format, and wrap the angle so it stays in the range [-PI,PI).
You can risk gimble-lock, and store your rotation in euler angles. Again, wrapping the angles in the range [-PI,PI).

##### Share on other sites
clashie    632
Ahh, I figured it out.
It was a pretty durrr mistake with the way I was doing the multiplication.

##### Share on other sites
For floating-point drift, you can also use Doubles. Granted, depending on language it may be a little slower, but it's also a lot more precise.

You'll still need to orthonormalize, but a lot less often.