I’m actually looking for a rational explanation for something I discovered, but I hope this doesn’t come off like a rant…

Our rig has changed since I took over an export script.  A tracker node that was once un-parented is now parented, so doing
float $x = `getAttr -time $startFrame ($trckrNode + “.translateX")`;
no longer works because, as I discovered, despite what the on-line help’s section on transform node attributes says, the translateX attribute is NOT in world space.

Fine.  So Goggling (not the MEL and Expressions guide, unfortunately) led me to discover the xform command.  And fortunately, xform has a -worldSpace flag, so I know what I’m getting.  Unfortunately, it does not have -time flag.  Then I found the currentTime command, which I could use to first set the time with.  But to get xform to provide the right values for that time, currentTime must use the -update 1 flag—which unfortunately causes a visual jump when I am simply querying position values.

I then thought I had discovered the best of both worlds when I stumbled into the hidden worldMatrix attribute on a transform node.  And indeed, I was able to get the world space translation at the right time…

...but in centimeters!  What is going on here?  The currentUnit is set to meters, and xform was returning meters.  Why is the worldMatrix attribute—which in my test case is unscaled and unrotated and perfectly affine—returning translation values that are 100 times greater than what xform returns?  I would perhaps just shrug this off but it so happens that my next step involves converting the Maya translation to Unreal3 coordinates—which are in centimeters.

Is this just another MEL-ism I have to live with?  Some kind of undocumented, Autodesk tribal knowledge?

I’m hoping someone can give me an explanation for this, preferably involving a command query I can use so I don’t have to simply rely on comments in my script to explain another MEL-gotcha to the next guy who has to support this.

Anyone?