Rotation - translation (inverting order)

[lanjoe9]

Hello!
I've seen from the tutorials that you normally perform rotation and translation in this order:

rotate(variable angle, someAxis)
translate( some distance away from camera)
drawObject

Which, in the tutorials, shows an object rotating on its center (I'll call this "Effect A").
However, if we try this in "ye olde GL" (not on the wii, of course), the effect would be an object rotating around the camera (I'll call this "Effect B"), and inverting the order (i.e. first translate, then rotate) would achieve "Effect A".
Why is this? (Does this have to do with the modelview matrix being divided into model and view?)

How can I achieve "Effect B" on the Wii? I tried inverting rotation and translation but it only made the object appear extremely big and cover the whole screen ("Effect C").

Thank you very much in advance.

[lanjoe9]

After some testing (re-implementing both the rotation and translation functions) I was able to determine there's something funny going on with the translation transformation.

So here's the code for a correct translation matrix, feel free to use it:

Code: Select all

void mjWiiTrnMtx(Vector &trans, Mtx44 T)
{
	// Ye olde Translation matrix
	T[0][3] = trans.x;
	T[1][3] = trans.y;
	T[2][3] = trans.z;
	T[0][0] = T[1][1] = T[2][2] = T[3][3] = 1.0;
	T[0][1] = T[0][2] = T[1][0] = T[1][2] = T[2][0] = T[2][1] = T[3][0] = T[3][1] = T[3][2] = 0.0;
	
}
void guTranslatef(Vector &t, Mtx44 currentMtx)
{
	Mtx44 translateMtx;

	mjWiiTrnMtx(t, translateMtx);
	guMtxConcat(currentMtx, translateMtx, currentMtx);
	
}

I'm going to take a look at the libogc source, maybe I'll be able to submit a patch.

[lanjoe9]

Math reference:

http://inside.mines.edu/~gmurray/Arbitr ... ation.html

[lanjoe9]

I found the implementation for the gamecube version of libogc in the libogc/gu.c source code file.

This is IMO the correct way to implement the TransApply function:

Code: Select all

void c_guMtxTransApply(Mtx src,Mtx dst,f32 xT,f32 yT,f32 zT)
{
    if ( src != dst )
    {
        dst[0][0] = src[0][0];    dst[0][1] = src[0][1];    dst[0][2] = src[0][2];
        dst[1][0] = src[1][0];    dst[1][1] = src[1][1];    dst[1][2] = src[1][2];
        dst[2][0] = src[2][0];    dst[2][1] = src[2][1];    dst[2][2] = src[2][2];
    }
    
    dst[0][3] = src[0][0]*xT + src[0][1]*yT + src[0][2]*zT + src[0][3];
    dst[1][3] = src[1][0]*xT + src[1][1]*yT + src[1][2]*zT + src[1][3];
    dst[2][3] = src[2][0]*xT + src[2][1]*yT + src[2][2]*zT + src[2][3];
}

If you perform the matrix multiplication M x T, expressing M as
M = {
{m00, m01, m02, m03},
{m10, m11, m12, m13},
{m20, m21, m22, m23},
{zero, zero, zero, 1.0},
}

and T as
T = {
{1.0, zero, zero, xT},
{zero, 1.0, zero, yT},
{zero, zero, 1.0, zT},
{zero, zero, zero, 1.0},
}

We get the resultant matrix M'
M' = {
{m00, m01, m02, m03 + (m00*xT + m01*yT + m02*zT)},
{m10, m11, m12, m13 + (m10*xT + m11*yT + m12*zT)},
{m20, m21, m22, m23 + (m20*xT + m21*yT + m22*zT)},
{zero, zero, zero, 1.0},
}

I'll try my hand at Gekko ASM later, as for now my time's run out!

[shagkur]

Hi,

first of all both, your version aswell as the current one, are mathematically correct.
while matrix multiplications aren't commutativ (AxB!=BxA) it's leading to different results.
so the current TransApply function does TxM, the same applies to ScaleApply.
Although this isn't always the way one wants to go with. Therefor i've added now
your version of TransApply and ScaleApply - called ApplyTrans and ApplyScale.
It's done for both variants, the C and the PS Asm.

Hope this helps?

regards
shagkur

[lanjoe9]

Hi! Thanks a lot for the fix!

I don't entirely agree on the "mathematical validity" of TransApply (it won't respect scaling or rotation applied beforehand). I'm not talking about commutativity (I know matrix multiplication isn't commutative - that's what I was talking about in my first post ), but rather on the TransApply function not complying with the usual rules of a linear vectorial space -- but if you see there's usefulness for that function to exist, then fine with me, no problem

I'll download it right away, since I'm an absolute newbie to wii ASM stuff, I'm very interested in seeing how you implemented it (I'm actually a bit disappointed I couldn't figure it out before you fixed it ).

[lanjoe9]

Ah! Now I understood what you wanted to say - that it does TxM and not MxT . Ok.

This holds mathematically correct if M does not have any rotation beforehand, however, if M does, then it doesn't.

Well never mind, the point is that there's a new function which does MxT and thus works for all the math (or OpenGL obsessed) freaks out there

[shagkur]

Hi again,

so the "new" Apply* functions work well for you - especially the asm variants?

Also i dont really get why it wont hold correct if a rotation is applied to M beforehand!?
While the 3x3 submatrix of that implicit Translation matrix is an identity matrix the 3x3 submatrix of M will remain as it is.
So only the 4th (the tranlsation) column is affected. And while we do TxM we just have to add the scalars of the translation to the
corresponding entries of the M matrix.
But again this only applies if we do TxM. Doing MxT indeed has to take the 3x3submatrix of M for translation into account.

regards
shagkur

[lanjoe9]

You're right on the TxM being valid, my mistake (must remember to do proof before posting ).
Indeed the TxM operation is correct.

The new ApplyTrans is much more "in line" with OpenGL addicts (like me), where you pile up transform after transform..

I've tested the new functions (ApplyScale as well) and can confirm they work perfectly. Thank you very much again!