Xform after freeze transforms to get ROTATION of object

[gangie81]

Hi everbody,

I hope someone can shine some light on my following issue:

I want to get the rotation of an object after the transforms have been frozen. I thought I could use

xform -q -ws -a -ro $obj

but that does not seem to work for me. I seem to remember that it worked on joints as they are different nodes I guess, but it doesn't seem to work on a simple polyCube.

It works fine on any object before the transforms are frozen. After that I can only get the objects TRANSLATION transforms by using the rotate pivot. (xform -q -ws -a -rp $obj)

Also using orientConstraint doesn't seem to work when I am trying to orientconstrain an object  to another (with frozen transformations)...i thought it might be a work around.

I guess it makes sense, as the freezing aligns the localspace with the worldspace. But is there no way of getting this information still? Am I missing something here?

Thanks very much for any help or tips.

[thnkr]

Freeze transforms pushed the transform to the shape level. The vertices are in a different location after freeze transforms, so the rotation has effectively disappeared.

[joojaa]

It hasnt strictly speaking dissapeared, its now just 0. But that would be exactly the purpose of freeze, to declare you want to reset the transformation node.

See roatation and translation are arbitrary concepts, freeze is there so you can redefine the arbitrary measurement point. If that wasint your intention then for gods sake dong go around freezing things. Joints on the odtherhand dont really freeze, because it would be pointless to freeze a joint as that would just change your entire intent, after all you dont want to move the joint.

So my rule of thumb number one is:

If you are a artist dont freeze anything.  It doesent do any favors to you, the only reason you would need to freeze is if you need to get a easier reference for calculating something, even so freeze is not the tool for the job 50% of the time because its destructive in nature sand frankly you can allways matrix multply your calculation target. The only other valid reasons for doing freeze is if your importing data that has a mangled hierarchy, or if your fixing a freeze happy artists mess.

Rule of thumb number 2:

If you are a TD dont freeze anything unless you really know better.

Also using orientConstraint doesn't seem to work when I am trying to orientconstrain an object  to
another (with frozen transformations)...i thought it might be a work around.

Because trasfroms are arbitrary it seems to magically work when things are the way you thinkthey ought to be. This is more of a coincidence than anything else, because values of the contraint must have some defaults (likewise were anybody to change the defaults then youd be as confused). Now each constraint provides you with a up and along vecotor to redefine any arbitrary orientation. Change the vector directions to match your thinking.

Eg a to orient a gun you need to know the along vector wich is following teh barrel form chamber towards the business end. Likewise, unless your not a street punk who think hoding gun upside down is cool (and most likely dont hit anything) up is a vector perpendicular to the along in the drection of the sight.

[gangie81]

Hi Joojaa and Michiel,

Thank you for your insights. I am trying to build a tool at the moment where an artist can come in and build a few things, and for that I wanted to create some proxy geometry in place of the geometry that is already in the scene. And I wanted this proxy geometry to have the same position in worldspace and ideally also the same rotation. I was trying to take into account that the objects already in the scene have frozen transformations, that was why I was wondering. But I guess then the rotation values are just gone...
Thank you Joojaa for your comprehensive explanation...just out of interest...you mentioned that you could avoid freezing transforms and that a matrix multiply would usually do the same thing in a nondestructive way...if you don't mind...could you perhaps explain this a little more...I am intrigued

Thank you again...I am starting to get a better idea of how things are working but I fear I am still very much at the beginning.

[joojaa]

And I wanted this proxy geometry to have the same position in worldspace and ideally also the same rotation. I was trying to take into account that the objects already in the scene have frozen transformations, that was why I was wondering. But I guess then the rotation values are just gone...

The rotation values arent gone, the freezing redefined the rotations to 0 so the value you get by querrying is correct, the object is now nolonger in the same rest state.

...just out of interest...you mentioned that you could avoid freezing
transforms and that a matrix multiply would usually do the same thing
in a nondestructive way...if you don't mind...could you perhaps explain
this a little more...I am intrigued

ok, do you have any idea what the matrixes do and how they work? I mane a matrix is just a packed coordinate system so you can do computation on them. Refeer to your maths textbook.

Suppose you have a coordinate system A and B and a point P in A:s space. And you want to get the P in B:s space (Pb) then

Pb = P Inverese(B)A

(didnt chek miight be the other way around  depends bit on how the notation of matrixes is made)

[rgkovach]

JooJaa, what is your opinion on video game engines that have very primitive ideas of where an object is and where it's origin is?
Unless we Freeze the transforms and carefully re-align the pivot of the object to match the world origin, we cannot export geometry that comes in correctly.

Basically, our local space rotate and scale pivots must be zero - or in other words the World Space position of both rotate and scale pivots much match the translation of the transform node.

[joojaa]

Well its easy to implement. Basically each node is just one matrix or a different compound.

To be totally honest tough you can still have separate pivots if you wished, you'd just end up with more matrices in between. See the thing is one Mayas transform is actually:

matrix = inv(SP) * S * SH * SP * ST * inv(RP) * RA * R * RP * RT * T

Now you can probably explode this into 3 to 5 different elementary transforms that accomplish the same thing. So unless your system has some limit to depth of the transformation stack you almost certainly can get the same thing as Mayas transforms if you wished (whitout resetting anything)