BTW, the order of operation on the matrices is important. For Softimage you scale, rotate then translate (SRT like the order in the MCP, easy way to remember). Any other way and you will have unpredictable results.
On Tue, Aug 27, 2013 at 2:12 PM, Daniel Brassard <[email protected]>wrote: > A pretty good explanation of row vector and transform Matrix here. > > > http://msdn.microsoft.com/en-us/library/windows/desktop/bb206269(v=vs.85).aspx > > > On Tue, Aug 27, 2013 at 1:39 PM, Grahame Fuller < > [email protected]> wrote: > >> I'm pretty sure it's the row versus column vector issue. In a nutshell, >> most of the CG world, including Softimage, treats vectors as rows, i.e., >> 1x3 matrices. The rest of the world, including most references you'll find >> for math, physics, robotics, etc., treats vectors as columns, i.e., 3x1 >> matrices. >> >> In a row-vector world, you construct your transform by inserting your >> X,Y,Z basis vectors into a matrix as rows. The order of multiplication for >> transforms is Mchild x Mparent, and when multiplying a vector and matrix >> the vector goes on the left and the matrix on the right. >> >> In a column-vector world, it's the opposite. You construct your transform >> by inserting your X,Y,Z basis vectors into a matrix as columns. The order >> of multiplication for transforms is Mparent x Mchild, and when multiplying >> a vector and matrix the vector goes on the right and the matrix on the left. >> >> In particular, note that the row-vector transform is transposed (mirrored >> across the diagonal) from the column-vector transform. So if the formulas >> for your individual rotation matrices matX, matY, and matZ came from a >> reference that uses column-vectors, you need to transpose the matrices. >> >> To calculate the various rotation orders, you just need to multiply the >> matrices in different orders. In a row-vector world, you use reverse order, >> for example, if you want XYZ order then you calculate matZ x matY x matX. >> Luckily matrix multiplication is the same in both row-vector and >> column-vector worlds, so you can save some processor time by figuring it >> out long-hand and stuffing the final values into the full transform matrix >> directly, like in the code sample you showed, but of course it's easy to >> make a typo or other mistake. >> >> gray >> >> From: [email protected] [mailto: >> [email protected]] On Behalf Of Eric Thivierge >> Sent: Monday, August 26, 2013 8:21 PM >> To: [email protected] >> Subject: Re: SI Matrix3 and Maths >> >> Thanks Raf I saw that today. It's a problem somewhere with my matrix >> multiplication I think. Tried a bunch of different combos but I'm thinking >> it's what Matt touched on either the row / column mixing or a mistake in >> the shorthand somewhere. >> >> -------------------------------------------- >> Eric Thivierge >> http://www.ethivierge.com >> >> On Mon, Aug 26, 2013 at 8:15 PM, Raffaele Fragapane < >> [email protected]<mailto:[email protected]>> wrote: >> The rotation order matters. >> It's as simple as each rotation pushing a gimbal along by a linear >> distance of trigonometric functions of that angle in turns, in the rotation >> order... order. >> Wikipedia has the matricial forms: >> http://en.wikipedia.org/wiki/Rotation_matrix#Basic_rotations >> What's not working from that? Or if you haven't looked at it, shame on >> you! >> >> >> >
