Which begs the question - why is that formula in the user's guide and not the 
sdk guide?

I've wondered about that for years.


Matt


From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Grahame Fuller
Sent: Tuesday, August 27, 2013 11:52 AM
To: softimage@listproc.autodesk.com
Subject: RE: SI Matrix3 and Maths

Just to clarify, that's the order of the matrices in the multiplication, which 
in a row-vector world corresponds to performing the transformations 
interactively in the opposite order.

If there's non-uniform scaling involved and hierarchical scaling is on, it's 
more complicated. For the gruesome details, scroll to the bottom of this page: 
http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/index.html?url=files/transforms_ScalingObjects.htm,topicNumber=d30e51306.

If there's no non-uniform scaling then everything works out the same as for 
classic scaling.

gray

From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Daniel Brassard
Sent: Tuesday, August 27, 2013 2:29 PM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: SI Matrix3 and Maths

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 
<dbrassar...@gmail.com<mailto:dbrassar...@gmail.com>> 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 
<grahame.ful...@autodesk.com<mailto:grahame.ful...@autodesk.com>> 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: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 
[mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>]
 On Behalf Of Eric Thivierge
Sent: Monday, August 26, 2013 8:21 PM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
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 
<raffsxsil...@googlemail.com<mailto:raffsxsil...@googlemail.com><mailto:raffsxsil...@googlemail.com<mailto:raffsxsil...@googlemail.com>>>
 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!


Reply via email to