In a bit of irony, I actually don't know who was in charge of the SDK guide.
Matt -----Original Message----- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Grahame Fuller Sent: Tuesday, August 27, 2013 12:02 PM To: softimage@listproc.autodesk.com Subject: RE: SI Matrix3 and Maths It's been long enough that I can say this. Do you remember who was in charge of the SDK guide? That's why. gray -----Original Message----- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge Sent: Tuesday, August 27, 2013 2:57 PM To: softimage@listproc.autodesk.com Subject: Re: SI Matrix3 and Maths Formula? What you talkin' 'bout Willis? Eric Thivierge =============== Character TD / RnD Hybride Technologies On August-27-13 2:54:24 PM, Matt Lind wrote: > 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.co > m <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! >
