Re: SI Matrix3 and Maths
Haha, I'm trying. Been banging my head against my desk for the past few days not understanding what could be going wrong. My Matrix3 class method for multiplying is doing some really wonky stuff. Like reseting the matrix values to Identity if used in another multiply operation... makes no sense. Got some mean Python Gremlins crawling around in my code. Eric Thivierge === Character TD / RnD Hybride Technologies On August-28-13 9:03:10 AM, Ciaran Moloney wrote: Jeez, Eric! Sort it out! On Wed, Aug 28, 2013 at 1:55 PM, Eric Thivierge mailto:ethivie...@hybride.com>> wrote: The maths I was using were in fact correct but there is a bug in my Python classes that was causing the inconsistent results.
Re: SI Matrix3 and Maths
Jeez, Eric! Sort it out! On Wed, Aug 28, 2013 at 1:55 PM, Eric Thivierge wrote: > > The maths I was using were in fact correct but there is a bug in my Python > classes that was causing the inconsistent results. >
Re: SI Matrix3 and Maths
To report back...
The maths I was using were in fact correct but there is a bug in my
Python classes that was causing the inconsistent results.
Thanks for all the help and the good math lesson.
Eric Thivierge
===
Character TD / RnD
Hybride Technologies
On August-27-13 6:32:40 PM, Mitchell Lotierzo wrote:
So, yeah, silly question. :) Still haven't dived that deep into matrix
maths myself.
Thanks for the clarification Grahame! It's appreciated.
Mitch
On Tue, Aug 27, 2013 at 5:22 PM, Grahame Fuller
mailto:grahame.ful...@autodesk.com>> wrote:
T is not an exponent in that formula - rather MT is the transpose
of M.
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
Mitchell Lotierzo
Sent: Tuesday, August 27, 2013 6:15 PM
To: softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com>
Subject: Re: SI Matrix3 and Maths
So out of curiosity (and pardon me if this is a silly question),
what exactly is the exponent of 'T' in that equation? I don't seem
to see a definition.
On Tue, Aug 27, 2013 at 3:38 PM, Matt Lind
mailto:ml...@carbinestudios.com><mailto:ml...@carbinestudios.com
<mailto:ml...@carbinestudios.com>>> wrote:
Maggie hasn't been with Softimage for nearly 10 years. What's
everybody else's excuse?
Matt
-Original Message-
From: softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com><mailto:softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com>>
[mailto: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
Grahame Fuller
Sent: Tuesday, August 27, 2013 12:16 PM
To: softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com><mailto:softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com>>
Subject: RE: SI Matrix3 and Maths
Maggie.
gray
-Original Message-
From: softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com><mailto:softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com>>
[mailto: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
Matt Lind
Sent: Tuesday, August 27, 2013 3:04 PM
To: softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com><mailto:softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com>>
Subject: RE: SI Matrix3 and Maths
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><mailto:softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com>>
[mailto: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
Grahame Fuller
Sent: Tuesday, August 27, 2013 12:02 PM
To: softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com><mailto:softimage@listproc.autodesk.com
<mailto: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><mailto:softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com>>
[mailto: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: Tuesday, August 27, 2013 2:57 PM
To: softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com><mailto:softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com>>
Subject: Re: SI Matrix3 and Maths
For
Re: SI Matrix3 and Maths
So, yeah, silly question. :) Still haven't dived that deep into matrix maths myself. Thanks for the clarification Grahame! It's appreciated. Mitch On Tue, Aug 27, 2013 at 5:22 PM, Grahame Fuller wrote: > T is not an exponent in that formula - rather MT is the transpose of M. > > gray > > From: softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] On Behalf Of Mitchell Lotierzo > Sent: Tuesday, August 27, 2013 6:15 PM > To: softimage@listproc.autodesk.com > Subject: Re: SI Matrix3 and Maths > > So out of curiosity (and pardon me if this is a silly question), what > exactly is the exponent of 'T' in that equation? I don't seem to see a > definition. > > On Tue, Aug 27, 2013 at 3:38 PM, Matt Lind <mailto:ml...@carbinestudios.com>> wrote: > Maggie hasn't been with Softimage for nearly 10 years. What's everybody > else's excuse? > > > Matt > > > > > -Original Message- > From: softimage-boun...@listproc.autodesk.com softimage-boun...@listproc.autodesk.com> [mailto: > softimage-boun...@listproc.autodesk.com softimage-boun...@listproc.autodesk.com>] On Behalf Of Grahame Fuller > Sent: Tuesday, August 27, 2013 12:16 PM > To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com > > > Subject: RE: SI Matrix3 and Maths > > Maggie. > > gray > > -Original Message- > From: softimage-boun...@listproc.autodesk.com softimage-boun...@listproc.autodesk.com> [mailto: > softimage-boun...@listproc.autodesk.com softimage-boun...@listproc.autodesk.com>] On Behalf Of Matt Lind > Sent: Tuesday, August 27, 2013 3:04 PM > To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com > > > Subject: RE: SI Matrix3 and Maths > > 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 softimage-boun...@listproc.autodesk.com> [mailto: > softimage-boun...@listproc.autodesk.com softimage-boun...@listproc.autodesk.com>] On Behalf Of Grahame Fuller > Sent: Tuesday, August 27, 2013 12:02 PM > To: softimage@listproc.autodesk.com<mailto: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 softimage-boun...@listproc.autodesk.com> [mailto: > softimage-boun...@listproc.autodesk.com softimage-boun...@listproc.autodesk.com>] On Behalf Of Eric Thivierge > Sent: Tuesday, August 27, 2013 2:57 PM > To: softimage@listproc.autodesk.com<mailto: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 softimage-boun...@listproc.autodesk.com> > > [mailto:softimage-boun...@listproc.autodesk.com softimage-boun...@listproc.autodesk.com>] *On Behalf Of > > *Grahame Fuller > > *Sent:* Tuesday, August 27, 2013 11:52 AM > > *To:* softimage@listproc.autodesk.com 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 softimage-boun...@listproc.autodesk.com> > > <mailto:softimage-boun...@listproc.autodesk.com softimage-boun...@listproc.autodesk.com>> > > [mailto:softimage-boun...@listproc.autodesk.com softimage-boun...@listproc.autodesk.com>] *On
RE: SI Matrix3 and Maths
T is not an exponent in that formula - rather MT is the transpose of M. gray From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Mitchell Lotierzo Sent: Tuesday, August 27, 2013 6:15 PM To: softimage@listproc.autodesk.com Subject: Re: SI Matrix3 and Maths So out of curiosity (and pardon me if this is a silly question), what exactly is the exponent of 'T' in that equation? I don't seem to see a definition. On Tue, Aug 27, 2013 at 3:38 PM, Matt Lind mailto:ml...@carbinestudios.com>> wrote: Maggie hasn't been with Softimage for nearly 10 years. What's everybody else's excuse? Matt -Original Message- 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 Grahame Fuller Sent: Tuesday, August 27, 2013 12:16 PM To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> Subject: RE: SI Matrix3 and Maths Maggie. gray -Original Message- 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 Matt Lind Sent: Tuesday, August 27, 2013 3:04 PM To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> Subject: RE: SI Matrix3 and Maths 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> [mailto: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<mailto: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> [mailto: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<mailto: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> > [mailto: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<mailto: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<mailto: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> > <mailto: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
Re: SI Matrix3 and Maths
So out of curiosity (and pardon me if this is a silly question), what exactly is the exponent of 'T' in that equation? I don't seem to see a definition. On Tue, Aug 27, 2013 at 3:38 PM, Matt Lind wrote: > Maggie hasn't been with Softimage for nearly 10 years. What's everybody > else's excuse? > > > 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:16 PM > To: softimage@listproc.autodesk.com > Subject: RE: SI Matrix3 and Maths > > Maggie. > > gray > > -Original Message- > From: softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind > Sent: Tuesday, August 27, 2013 3:04 PM > To: softimage@listproc.autodesk.com > Subject: RE: SI Matrix3 and Maths > > 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 > > 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 > > 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 o
RE: SI Matrix3 and Maths
Maggie hasn't been with Softimage for nearly 10 years. What's everybody else's excuse? 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:16 PM To: softimage@listproc.autodesk.com Subject: RE: SI Matrix3 and Maths Maggie. gray -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Tuesday, August 27, 2013 3:04 PM To: softimage@listproc.autodesk.com Subject: RE: SI Matrix3 and Maths 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 > 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 > 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 mat
RE: SI Matrix3 and Maths
Maggie. gray -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Tuesday, August 27, 2013 3:04 PM To: softimage@listproc.autodesk.com Subject: RE: SI Matrix3 and Maths 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 > 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 > 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 ca
RE: SI Matrix3 and Maths
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 > 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 > 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..
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 > 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 > 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.a
RE: SI Matrix3 and Maths
See bottom of page. Matt -Original Message- From: Eric Thivierge [mailto:ethivie...@hybride.com] Sent: Tuesday, August 27, 2013 11:57 AM To: softimage@listproc.autodesk.com Cc: Matt Lind 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 > 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 > 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 > multipl
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 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 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 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!
RE: SI Matrix3 and Maths
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 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 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 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!
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] On Behalf Of Daniel Brassard Sent: Tuesday, August 27, 2013 2:29 PM To: 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 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 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 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! <>
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 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> 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] On Behalf Of Eric Thivierge >> Sent: Monday, August 26, 2013 8:21 PM >> To: 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>> 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! >> >> >> >
Re: SI Matrix3 and Maths
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 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] On Behalf Of Eric Thivierge > Sent: Monday, August 26, 2013 8:21 PM > To: 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>> 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! > > >
RE: SI Matrix3 and Maths
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] On Behalf Of Eric Thivierge Sent: Monday, August 26, 2013 8:21 PM To: 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 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! <>
Re: SI Matrix3 and Maths
I know! That is the raw math. Only wrapped through the API to better transport the idea. here it is python only until the latest part where we have to set the transform: import math x = -45.0 y = 45.0 z = 0.0 def degToRad(value): return value * (math.pi / 180) cx = math.cos(degToRad(x)) sx = math.sin(degToRad(x)) cy = math.cos(degToRad(y)) sy = math.sin(degToRad(y)) cz = math.cos(degToRad(z)) sz = math.sin(degToRad(z)) xAxisX = [1,0,0] xAxisY = [0,cx,sx] xAxisZ = [0,-sx,cx] matX = [xAxisX,xAxisY,xAxisZ] yAxisX = [cy,0,-sy] yAxisY = [0,1,0] yAxisZ = [sy,0,cy] matY = [yAxisX,yAxisY,yAxisZ] zAxisX = [cz,sz,0] zAxisY = [-sz,cz,0] zAxisZ = [0,0,1] matZ = [zAxisX,zAxisY,zAxisZ] matrixXY =[ [ matX[0][0] * matY[0][0] + matX[0][1] * matY[1][0] + matX[0][2] * matY[2][0], matX[0][0] * matY[0][1] + matX[0][1] * matY[1][1] + matX[0][2] * matY[2][1], matX[0][0] * matY[0][2] + matX[0][1] * matY[1][2] + matX[0][2] * matY[2][2]], [ matX[1][0] * matY[0][0] + matX[1][1] * matY[1][0] + matX[1][2] * matY[2][0], matX[1][0] * matY[0][1] + matX[1][1] * matY[1][1] + matX[1][2] * matY[2][1], matX[1][0] * matY[0][2] + matX[1][1] * matY[1][2] + matX[1][2] * matY[2][2]], [ matX[2][0] * matY[0][0] + matX[2][1] * matY[1][0] + matX[2][2] * matY[2][0], matX[2][0] * matY[0][1] + matX[2][1] * matY[1][1] + matX[2][2] * matY[2][1], matX[2][0] * matY[0][2] + matX[2][1] * matY[1][2] + matX[2][2] * matY[2][2]]] rotationXYZ =[ [ matrixXY[0][0] * matZ[0][0] + matrixXY[0][1] * matZ[1][0] + matrixXY[0][2] * matZ[2][0], matrixXY[0][0] * matZ[0][1] + matrixXY[0][1] * matZ[1][1] + matrixXY[0][2] * matZ[2][1], matrixXY[0][0] * matZ[0][2] + matrixXY[0][1] * matZ[1][2] + matrixXY[0][2] * matZ[2][2]], [ matrixXY[1][0] * matZ[0][0] + matrixXY[1][1] * matZ[1][0] + matrixXY[1][2] * matZ[2][0], matrixXY[1][0] * matZ[0][1] + matrixXY[1][1] * matZ[1][1] + matrixXY[1][2] * matZ[2][1], matrixXY[1][0] * matZ[0][2] + matrixXY[1][1] * matZ[1][2] + matrixXY[1][2] * matZ[2][2]], [ matrixXY[2][0] * matZ[0][0] + matrixXY[2][1] * matZ[1][0] + matrixXY[2][2] * matZ[2][0], matrixXY[2][0] * matZ[0][1] + matrixXY[2][1] * matZ[1][1] + matrixXY[2][2] * matZ[2][1], matrixXY[2][0] * matZ[0][2] + matrixXY[2][1] * matZ[1][2] + matrixXY[2][2] * matZ[2][2]]] siMatrix = XSIMath.CreateMatrix3( rotationXYZ[0][0],rotationXYZ[0][1],rotationXYZ[0][2], rotationXYZ[1][0],rotationXYZ[1][1],rotationXYZ[1][2], rotationXYZ[2][0],rotationXYZ[2][1],rotationXYZ[2][2]) xfo = XSIMath.CreateTransform() xfo.SetRotationFromMatrix3(siMatrix) Application.Selection(0).Kinematics.Global.PutTransform2(None, xfo) On Mon, Aug 26, 2013 at 7:09 PM, Matt Lind wrote: > I think he’s looking for the raw math sans Softimage API. > > ** ** > > As for working with texts and papers from online, you’ll need to pay > attention to what kind of vectors are used. Many use column vectors in > their matrices. Softimage uses row vectors. You cannot mix n’ match, you > must align all data to be consistently row vectors or consistently column > vectors. You can convert a matrix to/from row aligned via a transpose > (flip entries across main diagonal). > > ** ** > > I would also advise using more parenthesis to ensure order of operations > are enforced in your computations. You’d be surprised how often silly > mistakes result from this. > > ** ** > > As a learning exercise I would advise doing it all long hand by building a > matrix for the initial transformation of the null then multiply it in turn > by each rotation vector (euler angle) because a transformation is > essentially a series of matrix and vector multiplications performed in a > specific order (XYZ in this case). The algorithm you are using is an > abbreviated version because many terms simplify during the computations. > If you do it long hand you should get the correct result. From that you > can trace your steps backwards to find your error in your initial attempts. > > > ** ** > > Matt > > ** ** > > ** ** > > ** ** > > ** ** > > *From:* softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] *On Behalf Of *Vladimir > Jankijevic > > *Sent:* Monday, August 26, 2013 3:46 PM > *To:* softimage@listproc.autodesk.com > *Subject:* Re: SI Matrix3 and Maths > > ** ** > > if you want to do it the hard way you can do it like this: > > ** ** > > # Python > > import math > > x = -45.0 > > y = 45.0 > > z = 0.0 > > ** ** > > def degToRad(value): > > return value * (math.pi / 180) > > > > ** ** > > cx = math.cos(degToRad(x)) > > sx = math.sin(degToRad(x)) > > cy = math.cos(degToRad(y)) > > sy = math.sin(degToRad(y)) > > cz = math.cos(degToRa
Re: SI Matrix3 and Maths
Try one angle at a time, and multiply by the matrix first, then by its transposeInPlace. That should show you the order (whether it's direct or reversed), and whether you have a column/row discrepancy. Adjust accordingly. On Tue, Aug 27, 2013 at 10:21 AM, Eric Thivierge wrote: > 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> 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! >> >> > -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
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> 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! > >
Re: SI Matrix3 and Maths
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!
RE: SI Matrix3 and Maths
Thanks everyone. Will take a look and retry with expanded notation without short cuts. While i would bother Guillaume, he has some pressing work of his own and shouldn't be bothered to hold my hand through the math. Rather bother you guys who may have urgent work to be done that I'm oblivious to. :) Thanks for the generosity of replying. Will post results once I have the solution. On Aug 26, 2013 7:09 PM, "Matt Lind" wrote: > I think he’s looking for the raw math sans Softimage API. > > ** ** > > As for working with texts and papers from online, you’ll need to pay > attention to what kind of vectors are used. Many use column vectors in > their matrices. Softimage uses row vectors. You cannot mix n’ match, you > must align all data to be consistently row vectors or consistently column > vectors. You can convert a matrix to/from row aligned via a transpose > (flip entries across main diagonal). > > ** ** > > I would also advise using more parenthesis to ensure order of operations > are enforced in your computations. You’d be surprised how often silly > mistakes result from this. > > ** ** > > As a learning exercise I would advise doing it all long hand by building a > matrix for the initial transformation of the null then multiply it in turn > by each rotation vector (euler angle) because a transformation is > essentially a series of matrix and vector multiplications performed in a > specific order (XYZ in this case). The algorithm you are using is an > abbreviated version because many terms simplify during the computations. > If you do it long hand you should get the correct result. From that you > can trace your steps backwards to find your error in your initial attempts. > > > ** ** > > Matt > > ** ** > > ** ** > > ** ** > > ** ** > > *From:* softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] *On Behalf Of *Vladimir > Jankijevic > *Sent:* Monday, August 26, 2013 3:46 PM > *To:* softimage@listproc.autodesk.com > *Subject:* Re: SI Matrix3 and Maths > > ** ** > > if you want to do it the hard way you can do it like this: > > ** ** > > # Python > > import math > > x = -45.0 > > y = 45.0 > > z = 0.0 > > ** ** > > def degToRad(value): > > return value * (math.pi / 180) > > > > ** ** > > cx = math.cos(degToRad(x)) > > sx = math.sin(degToRad(x)) > > cy = math.cos(degToRad(y)) > > sy = math.sin(degToRad(y)) > > cz = math.cos(degToRad(z)) > > sz = math.sin(degToRad(z)) > > ** ** > > ** ** > > rotationX = XSIMath.CreateMatrix3( 1,0,0, > > > 0,cx,sx, > > > 0,-sx,cx) > > > > > rotationY = XSIMath.CreateMatrix3( cy,0,-sy, > > > 0,1,0, > > > sy,0,cy) > > > ** > ** > > rotationZ = XSIMath.CreateMatrix3( cz,sz,0, > > > -sz,cz,0, > > > 0,0,1) > > > > > > > > rotationXY = XSIMath.CreateMatrix3(rotationX.Value(0,0) * > rotationY.Value(0,0) + rotationX.Value(0,1) * rotationY.Value(1,0) + > rotationX.Value(0,2) * rotationY.Value(2,0), > > > rotationX.Value(0,0) * rotationY.Value(0,1) + rotationX.Value(0,1) * > rotationY.Value(1,1) + rotationX.Value(0,2) * rotationY.Value(2,1), > > > rotationX.Value(0,0) * rotationY.Value(0,2) + rotationX.Value(0,1) * > rotationY.Value(1,2) + rotationX.Value(0,2) * rotationY.Value(2,2), > > > > > > rotationX.Value(1,0) * rotationY.Value(0,0) + rotationX.Value(1,1) * > rotationY.Value(1,0) + rotationX.Value(1,2) * rotationY.Value(2,0), > > > rotationX.Value(1,0) * rotationY.Value(0,1) + rotationX.Value(1,1) * > rotationY.Value(1,1) + rotationX.Value(1,2) * rotationY.Value(2,1), > > > rotationX.Value(1,0) * rotationY.Value(0,2) + rotationX.Value(1,1) * > rotationY.Value(1,2) + rotationX.Value(1,2) * rotationY.Value(2,2), > > > > > > rotationX.Value(2,0) * rotationY.Value(0,0) + rotationX.Value(2,1) * > rotationY.Value(1,0) + rotationX.Value(2,2) * rotationY.Value(2,0), > > > rotationX.Value(2,0) * rotationY.Value(0,1) + rotationX.Value(2,1) * > rotationY.Value(1,1) + rotationX.Value(2,2) * rotationY.Value(2,1), > > > rotationX.Value(2,0) * rotationY.Value(0,2) + rotationX.Value(2,1) * > rotationY.Value(1,2) + rotationX.Value(2,2) * rotationY.Value(2,2)) > > > > > rotationXYZ = XSIMath.CreateMatrix3(rotationXY.Value(0,0)
RE: SI Matrix3 and Maths
I think he's looking for the raw math sans Softimage API. As for working with texts and papers from online, you'll need to pay attention to what kind of vectors are used. Many use column vectors in their matrices. Softimage uses row vectors. You cannot mix n' match, you must align all data to be consistently row vectors or consistently column vectors. You can convert a matrix to/from row aligned via a transpose (flip entries across main diagonal). I would also advise using more parenthesis to ensure order of operations are enforced in your computations. You'd be surprised how often silly mistakes result from this. As a learning exercise I would advise doing it all long hand by building a matrix for the initial transformation of the null then multiply it in turn by each rotation vector (euler angle) because a transformation is essentially a series of matrix and vector multiplications performed in a specific order (XYZ in this case). The algorithm you are using is an abbreviated version because many terms simplify during the computations. If you do it long hand you should get the correct result. From that you can trace your steps backwards to find your error in your initial attempts. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Vladimir Jankijevic Sent: Monday, August 26, 2013 3:46 PM To: softimage@listproc.autodesk.com Subject: Re: SI Matrix3 and Maths if you want to do it the hard way you can do it like this: # Python import math x = -45.0 y = 45.0 z = 0.0 def degToRad(value): return value * (math.pi / 180) cx = math.cos(degToRad(x)) sx = math.sin(degToRad(x)) cy = math.cos(degToRad(y)) sy = math.sin(degToRad(y)) cz = math.cos(degToRad(z)) sz = math.sin(degToRad(z)) rotationX = XSIMath.CreateMatrix3( 1,0,0, 0,cx,sx, 0,-sx,cx) rotationY = XSIMath.CreateMatrix3( cy,0,-sy, 0,1,0, sy,0,cy) rotationZ = XSIMath.CreateMatrix3( cz,sz,0, -sz,cz,0, 0,0,1) rotationXY = XSIMath.CreateMatrix3(rotationX.Value(0,0) * rotationY.Value(0,0) + rotationX.Value(0,1) * rotationY.Value(1,0) + rotationX.Value(0,2) * rotationY.Value(2,0), rotationX.Value(0,0) * rotationY.Value(0,1) + rotationX.Value(0,1) * rotationY.Value(1,1) + rotationX.Value(0,2) * rotationY.Value(2,1), rotationX.Value(0,0) * rotationY.Value(0,2) + rotationX.Value(0,1) * rotationY.Value(1,2) + rotationX.Value(0,2) * rotationY.Value(2,2), rotationX.Value(1,0) * rotationY.Value(0,0) + rotationX.Value(1,1) * rotationY.Value(1,0) + rotationX.Value(1,2) * rotationY.Value(2,0), rotationX.Value(1,0) * rotationY.Value(0,1) + rotationX.Value(1,1) * rotationY.Value(1,1) + rotationX.Value(1,2) * rotationY.Value(2,1), rotationX.Value(1,0) * rotationY.Value(0,2) + rotationX.Value(1,1) * rotationY.Value(1,2) + rotationX.Value(1,2) * rotationY.Value(2,2), rotationX.Value(2,0) * rotationY.Value(0,0) + rotationX.Value(2,1) * rotationY.Value(1,0) + rotationX.Value(2,2) * rotationY.Value(2,0), rotationX.Value(2,0) * rotationY.Value(0,1) + rotationX.Value(2,1) * rotationY.Value(1,1) + rotationX.Value(2,2) * rotationY.Value(2,1), rotationX.Value(2,0) * rotationY.Value(0,2) + rotationX.Value(2,1) * rotationY.Value(1,2) + rotationX.Value(2,2) * rotationY.Value(2,2)) rotationXYZ = XSIMath.CreateMatrix3(rotationXY.Value(0,0) * rotationZ.Value(0,0) + rotationXY.Value(0,1) * rotationZ.Value(1,0) + rotationXY.Value(0,
Re: SI Matrix3 and Maths
oh and by the way. I have expanded the matrix multiplication for you to better understand how it works but as we are dealing with known matrix values it can be shortened to the line you have from the book. So no need to multiply all that stuff with all the zeros and ones :) Cheers On Mon, Aug 26, 2013 at 6:57 PM, Vladimir Jankijevic < vladi...@elefantstudios.ch> wrote: > oh, and you have a typo in 'matX.Set(0,1,0,0,cx,sx,0,-sx,**cx)' > it should be 'matX.Set(1,0,0,0,cx,sx,0,-sx,**cx)' > > > On Mon, Aug 26, 2013 at 6:45 PM, Vladimir Jankijevic < > vladi...@elefantstudios.ch> wrote: > >> if you want to do it the hard way you can do it like this: >> >> # Python >> import math >> x = -45.0 >> y = 45.0 >> z = 0.0 >> >> def degToRad(value): >> return value * (math.pi / 180) >> >> cx = math.cos(degToRad(x)) >> sx = math.sin(degToRad(x)) >> cy = math.cos(degToRad(y)) >> sy = math.sin(degToRad(y)) >> cz = math.cos(degToRad(z)) >> sz = math.sin(degToRad(z)) >> >> >> rotationX = XSIMath.CreateMatrix3( 1,0,0, >> 0,cx,sx, >> 0,-sx,cx) >> rotationY = XSIMath.CreateMatrix3( cy,0,-sy, >> 0,1,0, >> sy,0,cy) >> rotationZ = XSIMath.CreateMatrix3( cz,sz,0, >> -sz,cz,0, >> 0,0,1) >> rotationXY = XSIMath.CreateMatrix3( rotationX.Value(0,0) * >> rotationY.Value(0,0) + rotationX.Value(0,1) * rotationY.Value(1,0) + >> rotationX.Value(0,2) * rotationY.Value(2,0), >> rotationX.Value(0,0) * rotationY.Value(0,1) + rotationX.Value(0,1) * >> rotationY.Value(1,1) + rotationX.Value(0,2) * rotationY.Value(2,1), >> rotationX.Value(0,0) * rotationY.Value(0,2) + rotationX.Value(0,1) * >> rotationY.Value(1,2) + rotationX.Value(0,2) * rotationY.Value(2,2), >> rotationX.Value(1,0) * rotationY.Value(0,0) + rotationX.Value(1,1) * >> rotationY.Value(1,0) + rotationX.Value(1,2) * rotationY.Value(2,0), >> rotationX.Value(1,0) * rotationY.Value(0,1) + rotationX.Value(1,1) * >> rotationY.Value(1,1) + rotationX.Value(1,2) * rotationY.Value(2,1), >> rotationX.Value(1,0) * rotationY.Value(0,2) + rotationX.Value(1,1) * >> rotationY.Value(1,2) + rotationX.Value(1,2) * rotationY.Value(2,2), >> rotationX.Value(2,0) * rotationY.Value(0,0) + rotationX.Value(2,1) * >> rotationY.Value(1,0) + rotationX.Value(2,2) * rotationY.Value(2,0), >> rotationX.Value(2,0) * rotationY.Value(0,1) + rotationX.Value(2,1) * >> rotationY.Value(1,1) + rotationX.Value(2,2) * rotationY.Value(2,1), >> rotationX.Value(2,0) * rotationY.Value(0,2) + rotationX.Value(2,1) * >> rotationY.Value(1,2) + rotationX.Value(2,2) * rotationY.Value(2,2)) >> rotationXYZ = XSIMath.CreateMatrix3(rotationXY.Value(0,0) * >> rotationZ.Value(0,0) + rotationXY.Value(0,1) * rotationZ.Value(1,0) + >> rotationXY.Value(0,2) * rotationZ.Value(2,0), >> rotationXY.Value(0,0) * rotationZ.Value(0,1) + rotationXY.Value(0,1) * >> rotationZ.Value(1,1) + rotationXY.Value(0,2) * rotationZ.Value(2,1), >> rotationXY.Value(0,0) * rotationZ.Value(0,2) + rotationXY.Value(0,1) * >> rotationZ.Value(1,2) + rotationXY.Value(0,2) * rotationZ.Value(2,2), >> rotationXY.Value(1,0) * rotationZ.Value(0,0) + rotationXY.Value(1,1) * >> rotationZ.Value(1,0) + rotationXY.Value(1,2) * rotationZ.Value(2,0), >> rotationXY.Value(1,0) * rotationZ.Value(0,1) + rotationXY.Value(1,1) * >> rotationZ.Value(1,1) + rotationXY.Value(1,2) * rotationZ.Value(2,1), >> rotationXY.Value(1,0) * rotationZ.Value(0,2) + rotationXY.Value(1,1) * >> rotationZ.Value(1,2) + rotationXY.Value(1,2) * rotationZ.Value(2,2), >> rotationXY.Value(2,0) * rotationZ.Value(0,0) + rotationXY.Value(2,1) * >> rotationZ.Value(1,0) + rotationXY.Value(2,2) * rotationZ.Value(2,0), >> rotationXY.Value(2,0) * rotationZ.Value(0,1) + rotationXY.Value(2,1) * >> rotationZ.Value(1,1) + rotationXY.Value(2,2) * rotationZ.Value(2,1), >> rotationXY.Value(2,0) * rotationZ.Value(0,2) + rotationXY.Value(2,1) * >> rotationZ.Value(1,2) + rotationXY.Value(2,2) * rotationZ.Value(2,2)) >> xfo = XSIMath.CreateTransform() >> xfo.SetRotationFromMatrix3(rotationXYZ) >> >> Application.Selection(0).Kinematics.Global.PutTransform2(None, xfo) >> >> >> >> On Mon, Aug 26, 2013 at 6:05 PM, Matt Lind wrote: >> >>> Don't you have Mr LaForge and Mr. LeClaire at your disposal? I would >>> think they could answer in a heartbeat. >>> >>> >>> Anyway, an alternate way of dealing with this problem is to export the >>> axis vectors instead of computing the rotations. This ensures you get a >>> match and you don't have to deal with math. >>> >>> >>> Matt >>> >>> >>> >>> >>> -Original Message- >>> From: softimage-boun...@listproc.autodesk.com [mailto: >>> softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge >>> Sent: Monday, August 26, 2013 2:46 PM >>> To: softimage@listproc.autodesk.com >>> Subject: SI Matrix3 and Maths >>> >>> Hey all, >>> >>> Plunging ever further into the depths of matrices and the fun math >>> issues one may need to solve while building some tools for the studio. >>> >>> I'm trying to figure out how the SI Matrix3's are derived / set and am >>> hitting some w
Re: SI Matrix3 and Maths
oh, and you have a typo in 'matX.Set(0,1,0,0,cx,sx,0,-sx,**cx)' it should be 'matX.Set(1,0,0,0,cx,sx,0,-sx,**cx)' On Mon, Aug 26, 2013 at 6:45 PM, Vladimir Jankijevic < vladi...@elefantstudios.ch> wrote: > if you want to do it the hard way you can do it like this: > > # Python > import math > x = -45.0 > y = 45.0 > z = 0.0 > > def degToRad(value): > return value * (math.pi / 180) > > cx = math.cos(degToRad(x)) > sx = math.sin(degToRad(x)) > cy = math.cos(degToRad(y)) > sy = math.sin(degToRad(y)) > cz = math.cos(degToRad(z)) > sz = math.sin(degToRad(z)) > > > rotationX = XSIMath.CreateMatrix3( 1,0,0, > 0,cx,sx, > 0,-sx,cx) > rotationY = XSIMath.CreateMatrix3( cy,0,-sy, > 0,1,0, > sy,0,cy) > rotationZ = XSIMath.CreateMatrix3( cz,sz,0, > -sz,cz,0, > 0,0,1) > rotationXY = XSIMath.CreateMatrix3( rotationX.Value(0,0) * > rotationY.Value(0,0) + rotationX.Value(0,1) * rotationY.Value(1,0) + > rotationX.Value(0,2) * rotationY.Value(2,0), > rotationX.Value(0,0) * rotationY.Value(0,1) + rotationX.Value(0,1) * > rotationY.Value(1,1) + rotationX.Value(0,2) * rotationY.Value(2,1), > rotationX.Value(0,0) * rotationY.Value(0,2) + rotationX.Value(0,1) * > rotationY.Value(1,2) + rotationX.Value(0,2) * rotationY.Value(2,2), > rotationX.Value(1,0) * rotationY.Value(0,0) + rotationX.Value(1,1) * > rotationY.Value(1,0) + rotationX.Value(1,2) * rotationY.Value(2,0), > rotationX.Value(1,0) * rotationY.Value(0,1) + rotationX.Value(1,1) * > rotationY.Value(1,1) + rotationX.Value(1,2) * rotationY.Value(2,1), > rotationX.Value(1,0) * rotationY.Value(0,2) + rotationX.Value(1,1) * > rotationY.Value(1,2) + rotationX.Value(1,2) * rotationY.Value(2,2), > rotationX.Value(2,0) * rotationY.Value(0,0) + rotationX.Value(2,1) * > rotationY.Value(1,0) + rotationX.Value(2,2) * rotationY.Value(2,0), > rotationX.Value(2,0) * rotationY.Value(0,1) + rotationX.Value(2,1) * > rotationY.Value(1,1) + rotationX.Value(2,2) * rotationY.Value(2,1), > rotationX.Value(2,0) * rotationY.Value(0,2) + rotationX.Value(2,1) * > rotationY.Value(1,2) + rotationX.Value(2,2) * rotationY.Value(2,2)) > rotationXYZ = XSIMath.CreateMatrix3(rotationXY.Value(0,0) * > rotationZ.Value(0,0) + rotationXY.Value(0,1) * rotationZ.Value(1,0) + > rotationXY.Value(0,2) * rotationZ.Value(2,0), > rotationXY.Value(0,0) * rotationZ.Value(0,1) + rotationXY.Value(0,1) * > rotationZ.Value(1,1) + rotationXY.Value(0,2) * rotationZ.Value(2,1), > rotationXY.Value(0,0) * rotationZ.Value(0,2) + rotationXY.Value(0,1) * > rotationZ.Value(1,2) + rotationXY.Value(0,2) * rotationZ.Value(2,2), > rotationXY.Value(1,0) * rotationZ.Value(0,0) + rotationXY.Value(1,1) * > rotationZ.Value(1,0) + rotationXY.Value(1,2) * rotationZ.Value(2,0), > rotationXY.Value(1,0) * rotationZ.Value(0,1) + rotationXY.Value(1,1) * > rotationZ.Value(1,1) + rotationXY.Value(1,2) * rotationZ.Value(2,1), > rotationXY.Value(1,0) * rotationZ.Value(0,2) + rotationXY.Value(1,1) * > rotationZ.Value(1,2) + rotationXY.Value(1,2) * rotationZ.Value(2,2), > rotationXY.Value(2,0) * rotationZ.Value(0,0) + rotationXY.Value(2,1) * > rotationZ.Value(1,0) + rotationXY.Value(2,2) * rotationZ.Value(2,0), > rotationXY.Value(2,0) * rotationZ.Value(0,1) + rotationXY.Value(2,1) * > rotationZ.Value(1,1) + rotationXY.Value(2,2) * rotationZ.Value(2,1), > rotationXY.Value(2,0) * rotationZ.Value(0,2) + rotationXY.Value(2,1) * > rotationZ.Value(1,2) + rotationXY.Value(2,2) * rotationZ.Value(2,2)) > xfo = XSIMath.CreateTransform() > xfo.SetRotationFromMatrix3(rotationXYZ) > > Application.Selection(0).Kinematics.Global.PutTransform2(None, xfo) > > > > On Mon, Aug 26, 2013 at 6:05 PM, Matt Lind wrote: > >> Don't you have Mr LaForge and Mr. LeClaire at your disposal? I would >> think they could answer in a heartbeat. >> >> >> Anyway, an alternate way of dealing with this problem is to export the >> axis vectors instead of computing the rotations. This ensures you get a >> match and you don't have to deal with math. >> >> >> Matt >> >> >> >> >> -Original Message- >> From: softimage-boun...@listproc.autodesk.com [mailto: >> softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge >> Sent: Monday, August 26, 2013 2:46 PM >> To: softimage@listproc.autodesk.com >> Subject: SI Matrix3 and Maths >> >> Hey all, >> >> Plunging ever further into the depths of matrices and the fun math issues >> one may need to solve while building some tools for the studio. >> >> I'm trying to figure out how the SI Matrix3's are derived / set and am >> hitting some walls. I have some Euler angles that I need to convert to >> Matrix3's then set a Transform from the result. >> >> Basically a Euler angle to Matrix3 operation. I need to solve this >> without the built in methods as I need to convert data from external >> sources to align with Softimage without the SDK available. >> >> I've referenced many of web sites (wikipedia, educational institutions, >> etc.) and all of the equations for multiplying the 3 matrices (x,y,z) end >> up with results t
Re: SI Matrix3 and Maths
if you want to do it the hard way you can do it like this: # Python import math x = -45.0 y = 45.0 z = 0.0 def degToRad(value): return value * (math.pi / 180) cx = math.cos(degToRad(x)) sx = math.sin(degToRad(x)) cy = math.cos(degToRad(y)) sy = math.sin(degToRad(y)) cz = math.cos(degToRad(z)) sz = math.sin(degToRad(z)) rotationX = XSIMath.CreateMatrix3( 1,0,0, 0,cx,sx, 0,-sx,cx) rotationY = XSIMath.CreateMatrix3( cy,0,-sy, 0,1,0, sy,0,cy) rotationZ = XSIMath.CreateMatrix3( cz,sz,0, -sz,cz,0, 0,0,1) rotationXY = XSIMath.CreateMatrix3( rotationX.Value(0,0) * rotationY.Value(0,0) + rotationX.Value(0,1) * rotationY.Value(1,0) + rotationX.Value(0,2) * rotationY.Value(2,0), rotationX.Value(0,0) * rotationY.Value(0,1) + rotationX.Value(0,1) * rotationY.Value(1,1) + rotationX.Value(0,2) * rotationY.Value(2,1), rotationX.Value(0,0) * rotationY.Value(0,2) + rotationX.Value(0,1) * rotationY.Value(1,2) + rotationX.Value(0,2) * rotationY.Value(2,2), rotationX.Value(1,0) * rotationY.Value(0,0) + rotationX.Value(1,1) * rotationY.Value(1,0) + rotationX.Value(1,2) * rotationY.Value(2,0), rotationX.Value(1,0) * rotationY.Value(0,1) + rotationX.Value(1,1) * rotationY.Value(1,1) + rotationX.Value(1,2) * rotationY.Value(2,1), rotationX.Value(1,0) * rotationY.Value(0,2) + rotationX.Value(1,1) * rotationY.Value(1,2) + rotationX.Value(1,2) * rotationY.Value(2,2), rotationX.Value(2,0) * rotationY.Value(0,0) + rotationX.Value(2,1) * rotationY.Value(1,0) + rotationX.Value(2,2) * rotationY.Value(2,0), rotationX.Value(2,0) * rotationY.Value(0,1) + rotationX.Value(2,1) * rotationY.Value(1,1) + rotationX.Value(2,2) * rotationY.Value(2,1), rotationX.Value(2,0) * rotationY.Value(0,2) + rotationX.Value(2,1) * rotationY.Value(1,2) + rotationX.Value(2,2) * rotationY.Value(2,2)) rotationXYZ = XSIMath.CreateMatrix3(rotationXY.Value(0,0) * rotationZ.Value(0,0) + rotationXY.Value(0,1) * rotationZ.Value(1,0) + rotationXY.Value(0,2) * rotationZ.Value(2,0), rotationXY.Value(0,0) * rotationZ.Value(0,1) + rotationXY.Value(0,1) * rotationZ.Value(1,1) + rotationXY.Value(0,2) * rotationZ.Value(2,1), rotationXY.Value(0,0) * rotationZ.Value(0,2) + rotationXY.Value(0,1) * rotationZ.Value(1,2) + rotationXY.Value(0,2) * rotationZ.Value(2,2), rotationXY.Value(1,0) * rotationZ.Value(0,0) + rotationXY.Value(1,1) * rotationZ.Value(1,0) + rotationXY.Value(1,2) * rotationZ.Value(2,0), rotationXY.Value(1,0) * rotationZ.Value(0,1) + rotationXY.Value(1,1) * rotationZ.Value(1,1) + rotationXY.Value(1,2) * rotationZ.Value(2,1), rotationXY.Value(1,0) * rotationZ.Value(0,2) + rotationXY.Value(1,1) * rotationZ.Value(1,2) + rotationXY.Value(1,2) * rotationZ.Value(2,2), rotationXY.Value(2,0) * rotationZ.Value(0,0) + rotationXY.Value(2,1) * rotationZ.Value(1,0) + rotationXY.Value(2,2) * rotationZ.Value(2,0), rotationXY.Value(2,0) * rotationZ.Value(0,1) + rotationXY.Value(2,1) * rotationZ.Value(1,1) + rotationXY.Value(2,2) * rotationZ.Value(2,1), rotationXY.Value(2,0) * rotationZ.Value(0,2) + rotationXY.Value(2,1) * rotationZ.Value(1,2) + rotationXY.Value(2,2) * rotationZ.Value(2,2)) xfo = XSIMath.CreateTransform() xfo.SetRotationFromMatrix3(rotationXYZ) Application.Selection(0).Kinematics.Global.PutTransform2(None, xfo) On Mon, Aug 26, 2013 at 6:05 PM, Matt Lind wrote: > Don't you have Mr LaForge and Mr. LeClaire at your disposal? I would > think they could answer in a heartbeat. > > > Anyway, an alternate way of dealing with this problem is to export the > axis vectors instead of computing the rotations. This ensures you get a > match and you don't have to deal with math. > > > Matt > > > > > -Original Message- > From: softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge > Sent: Monday, August 26, 2013 2:46 PM > To: softimage@listproc.autodesk.com > Subject: SI Matrix3 and Maths > > Hey all, > > Plunging ever further into the depths of matrices and the fun math issues > one may need to solve while building some tools for the studio. > > I'm trying to figure out how the SI Matrix3's are derived / set and am > hitting some walls. I have some Euler angles that I need to convert to > Matrix3's then set a Transform from the result. > > Basically a Euler angle to Matrix3 operation. I need to solve this without > the built in methods as I need to convert data from external sources to > align with Softimage without the SDK available. > > I've referenced many of web sites (wikipedia, educational institutions, > etc.) and all of the equations for multiplying the 3 matrices (x,y,z) end > up with results that are not consistent with Softimage's methods. > The only source that has proven to give me valid results is the 3D Math > Primer for Graphics and Game Dev book (Chapter 8.7). However it only shows > the solution for XYZ rotation order and even that I'm unsure how they got > the order in which they multiply the rows / columns. > > If any of you smart people out there (Raf, Matt?
RE: SI Matrix3 and Maths
Don't you have Mr LaForge and Mr. LeClaire at your disposal? I would think they could answer in a heartbeat. Anyway, an alternate way of dealing with this problem is to export the axis vectors instead of computing the rotations. This ensures you get a match and you don't have to deal with math. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge Sent: Monday, August 26, 2013 2:46 PM To: softimage@listproc.autodesk.com Subject: SI Matrix3 and Maths Hey all, Plunging ever further into the depths of matrices and the fun math issues one may need to solve while building some tools for the studio. I'm trying to figure out how the SI Matrix3's are derived / set and am hitting some walls. I have some Euler angles that I need to convert to Matrix3's then set a Transform from the result. Basically a Euler angle to Matrix3 operation. I need to solve this without the built in methods as I need to convert data from external sources to align with Softimage without the SDK available. I've referenced many of web sites (wikipedia, educational institutions, etc.) and all of the equations for multiplying the 3 matrices (x,y,z) end up with results that are not consistent with Softimage's methods. The only source that has proven to give me valid results is the 3D Math Primer for Graphics and Game Dev book (Chapter 8.7). However it only shows the solution for XYZ rotation order and even that I'm unsure how they got the order in which they multiply the rows / columns. If any of you smart people out there (Raf, Matt?) have a few free minutes to review my below code and show me the error of my ways I'd appreciate it. Maybe others could benefit too. Create 2 nulls. Set one rotation to x = -45, y=45 Select 2nd null and run script. Swap the commented "result" line and run again. # Python import math si = Application log = si.LogMessage sel = si.Selection def degToRad(value): return value * (math.pi / 180) x = -45 y = 45 z = 0 cx = math.cos(degToRad(x)) sx = math.sin(degToRad(x)) cy = math.cos(degToRad(y)) sy = math.sin(degToRad(y)) cz = math.cos(degToRad(z)) sz = math.sin(degToRad(z)) matX = XSIMath.CreateMatrix3() matX.Set(0,1,0,0,cx,sx,0,-sx,cx) matY = XSIMath.CreateMatrix3() matY.Set(cy,0,-sy,0,1,0,sy,0,cy) matZ = XSIMath.CreateMatrix3() matZ.Set(cz,sz,0,-sz,cz,0,0,0,1) result = XSIMath.CreateMatrix3() # From most sites I referenced-ish #result.Set(cz*cy, sz*cx + cz*sy*sx, sz*sx - cz*sy*cx, -sz*cy, cz*cx - sz*sy*sx, cz*sx + sz*sy*cx, sy, -cy*sx, cy*cx) result.Set(cy*cz + sy*sx*sz, sz*cx, -sy*cz + cy*sx*sz, -cy*sz + sy*sx*cz, cz*cx, sz*sy + cy*sx*cz, sy*cx, -sx, cy*cx) # From Book log(result.Get2()) xfo = XSIMath.CreateTransform() xfo.SetRotationFromMatrix3(result) sel(0).Kinematics.Global.PutTransform2(None, xfo) # End Python -- Eric Thivierge === Character TD / RnD Hybride Technologies
