You can match transformations with different rotation orders,
because internally the rotation order is irrelevant, it is only used
when calculating the input and the output ( given it is rotation ).
Internally the 4x4 matrix is just a bunch of vectors, that dont
know anything about rotation
My current mel script that I'd like to turn into a scripted plugin:
for ($obj in $hir){
string $type = `nodeType $obj`;
if (`gmatch joint $type`){
float $jo[] ={};
$jo[0] = `getAttr ($obj + .jointOrientX)`;
$jo[1] = `getAttr ($obj + .jointOrientY)`;
$jo[2] = `getAttr
The example in the blog just spits out what has
been put into the TransformationMatrix.
The question is whether when you add a rotation
this will be kept track of as well, right?
If I were you I would take the code from the blog
and add some rotation either with rotateBy
or addRotation and
OK! Due to further research, it seems that matching rotations of
different rotation orders is a mathmatical imposibility;
http://en.wikipedia.org/wiki/Rotation_(mathematics)
So, the question now is;
What would be the scripted plugin code to do 'relative' additive
rotations on one transform from