[maya] added euler filter for imports

[AlexSchwank]

Description of Change(s)

Added Euler filter to Maya import to fix potential Euler flips for animated rotations.
The filter is using Maya's MEulerRotation::setToClosestSolution().
Added useEulerFilter option to toggle the filter.

This helps with #410 but obviously only on the Maya side.

[jtran56]

Filed as internal issue #159381.

[pmolodo]

So, just as a note on what's going on here: part of the problem here is that your input xform stack is not identified as a maya compatible stack. In order to be judged maya-compatible, it must consist of these ops, or some subset:

[
    "xformOp:translate",
    "xformOp:translate:rotatePivotTranslate",
    "xformOp:translate:rotatePivot",
    "xformOp:rotateXYZ",
    "xformOp:rotateXYZ:rotateAxis",
    "!invert!xformOp:translate:rotatePivot",
    "xformOp:translate:scalePivotTranslate",
    "xformOp:translate:scalePivot",
    "xformOp:transform:shear",
    "xformOp:scale",
    "!invert!xformOp:translate:scalePivot"
]

The stack you have is:

[
    "xformOp:translate",
    "xformOp:translate:rotatePivotOffset",
    "xformOp:translate:rotatePivot",
    "xformOp:rotateXYZ:rotateOffset",
    "xformOp:rotateXYZ",
    "!invert!xformOp:translate:rotatePivot",
    "xformOp:translate:scalePivotOffset",
    "xformOp:translate:scalePivot",
    "xformOp:transform:shear",
    "xformOp:scale:scaleOffset",
    "xformOp:scale",
    "!invert!xformOp:translate:scalePivot",
]

The two stacks are close, but with a few differences... some of the names are different (rotatePivotTranslate vs rotatePivotOffset), the order of rotate/rotateAxis is different than the order of rotateOffset/rotate, and the maya stack has no "scaleOffset" slot.

So, since it couldn't conform the input stack to be maya compatible, it simply converts to a matrix, then decomposes... which explains the flips.

Having said that... it's not unreasonable to expect to be able to export a usd xform from one app, with it's own xform stack, then be able to import that xform stack into maya, and not have euler flips, even though the xform stacks are different. So I can still see the utility of this PR. Just wanted to offer an explanation of why it was happening...

[pmolodo]

These changes won't actually do anything, because rotateAxis is internally stored as a quaternion, so 360 flips change nothing. ie, try this in a python prompt:

cmds.setAttr('persp.rotateAxis', 720, 0, 0)
print cmds.getAttr('persp.rotateAxis')

[pmolodo]

A note: given that the changes in _pushUSDXformOpToMayaXform actually do nothing (see my note), the only changes are to _pushUSDXformToMayaXform... which should only get invoked for xform stacks that aren't compatible with the maya xform stack.

So the behavior currently is that if eulerFilter is on, then non-compatible xforms will be filtered, and compatible ones won't be. This is actually the behavior I would want by default, but might be somewhat confusing... there might be situations where someone passes in a compatible xform stack (ie, nothing but a rotate X of [350, 360, 10], and might actually want euler filtering on. Currently, they won't get it. I think the ideal behavior would be to make the option a tri-mode:

on: always filter, for both compatible and incompatible xform stacks
auto: filter incompatible stacks, don't filter compatible stacks (default)
off: never filter either

[AlexSchwank]

Thanks @elrond79 for your notes and for posting the explanation why we need the Euler filter.
I'm not sure how often one would want to filter compatible xform stacks but I can certainly add it. While doing that, I'll take another look at _pushUSDXformOpToMayaXform.

[AlexSchwank]

Closing this PR as it is replaced by #506