====== Rotation Matrix Problem ======

>Hi there,

>We're using the Arcball code in a project and are having problems with the rotation matrix. After some amount clicking and dragging, a translation or scaling element would appear to work its way into the matrix. Though we have not been able to verify that. The result is that the object being rotated around will disappear into the distance during a short drag, after the problem has occurred. We cant seem to work out why this happens, or the exact circumstance for when it happens, it would appear to be slightly random.

>Could you offer any insight into this? Have you heard of this problem before?

>Is it possible to force some of the elements of the transform to zero to make sure this doesn't happen?

>Thanks for any help, James

Hello,

Here's one possibility... in "Update" you'll find:

<code cpp>//Set our final transform's rotation from this one</code>

At this point we've just multiplied the "current drag rotation"(LastRot) against the "accumulated rotations,"(ThisRot) and come up with a new "accumulated"(ThisRot).

Now when this happens, every element in the new matrix(3x3) is modified, meaning your "scale" (or "S") values are altered- this doesn't mean that they're wrong per se, but that they're in a form you can't simply use with an matrix of type (4x4) without modification, so the next step is to get this into a (4x4) form, namely into the Matrix4f "Transform" variable.

What happens then is that the Matrix4fSetRotationFromMatrix3f function sets the 4x4 with the 3x3 rotation data, but normalizes it first by applying the scale value to it. By definition normalization *should* get all your ".S_" members into "unity." Which doesn't mean that it'll appear to be close to "identity", but that the "distance" has been "divided out," in a manner of speaking.

Now this may explain the "scale" data you see(again, if by "scale" you mean the "S" components of the matrix.) However, the class and related code never touches the translation data "T" or the "W" (the other scale) values of the matrix at all. So you either have two situations going on.

Either you have code that intentionally touches:

<code cpp>
.TX .TY .TZ .TW
.XW .YW .ZW .TW
</code>

of the matrix data, or you have a memory leak that's corrupting part of your matrices and you're seeing this result accidentally.

I would assume the second as I think there's little reason to touch the W's in everyday life.

My first suggestion would be to set your matrices' translation members as watch variables, which will help you track down where this is happening. If this becomes too tedious then breakpoint anywhere where you modify your final transform.

You're the first person so far that's had some malfunction with the class, so I'll almost have to assume its something within your code.

Its also possible that you're simply not doing a "glLoadIdentity" before you do your matrix pushing and popping, which can also cause problems. (But you indicated that the original matrix gets changed, so this is probably not it.)

The only other thing I can think of, if you're using a math library with some loss of precision in Sin and Cos (in other words, you're using sin and cos lookup tables), you can get this kind of effect where your object shrinks into nothingness due to the accumulation matrix's scale approaching zero. Its a longshot that you'd be doing something like that, but I thought I'd mention it just in case.

Hope I didn't overcomplicate my answer there, if you need anymore help or explanation feel free to let me know.

--Terence J. Grant

> Hi again, Sorry for taking so long to reply... we've been very busy.

> You might be interested to know the project is now complete and the arcball is used to help position an object before a potentially lengthy render is carried out.

> Thanks for your help, James

Cool beans, yeah ArcBall's helped alot of people so far, glad I wrote it up.