PyMEL compatibility difference in pymaya.datatypes.EulerRotation angle units

[yamahigashi]

🐞 Bug Report

Description

mgear.pymaya.datatypes.EulerRotation behaves differently from pymel.core.datatypes.EulerRotation when constructing Euler rotations from numeric angle values.

PyMEL's EulerRotation supports angular unit handling via the unit keyword, and when unit is omitted it interprets numeric values using the current Maya angle UI unit, usually degrees. mgear.pymaya.datatypes.EulerRotation directly inherits from maya.OpenMaya.MEulerRotation, so numeric values are interpreted as radians and unit="radians" / unit="degrees" is not supported. This makes cross-compatible code behave differently depending on whether datatypes comes from mgear.pymaya or pymel.core.

Steps to Reproduce

1. Run the following code with datatypes imported from mgear.pymaya:

   import math
   from mgear.pymaya import datatypes
   
   rot_x = datatypes.EulerRotation(
       math.radians(-90),
       0,
       0,
   ).asMatrix()
   
   rot_y = datatypes.EulerRotation(
       0,
       math.radians(90),
       0,
   ).asMatrix()
   
   print(rot_x)
   print(rot_y)

2. Run the same code with datatypes imported from PyMEL:

   import math
   from pymel.core import datatypes
   
   rot_x = datatypes.EulerRotation(
       math.radians(-90),
       0,
       0,
   ).asMatrix()
   
   rot_y = datatypes.EulerRotation(
       0,
       math.radians(90),
       0,
   ).asMatrix()
   
   print(rot_x)
   print(rot_y)

3. Compare the resulting matrices.

Expected Behavior

For PyMEL compatibility, mgear.pymaya.datatypes.EulerRotation should support explicit angle units, for example:

datatypes.EulerRotation(
    math.radians(-90),
    0,
    0,
    unit="radians",
)

Ideally, this should produce the same matrix as PyMEL's EulerRotation(..., unit="radians").

To avoid breaking existing pymaya behavior, the default behavior could remain unchanged, but accepting unit="radians" and unit="degrees" would make compatibility code possible.

Actual Behavior

With mgear.pymaya, numeric values are interpreted as radians because the class directly inherits from maya.OpenMaya.MEulerRotation.

Example result:

(((1, 0, -0, 0), (-0, 0, -1, 0), (0, 1, 0, 0), (0, 0, 0, 1)))
(((0, 0, -1, 0), (0, 1, 0, 0), (1, 0, 0, 0), (0, 0, 0, 1)))

With PyMEL, the same numeric values are interpreted using the current Maya angle UI unit, usually degrees, unless unit="radians" is specified.

Example result:

[[1.0, 0.0, -0.0, 0.0], [-0.0, 0.9996242168594817, -0.027412133592044294, 0.0], [0.0, 0.027412133592044294, 0.9996242168594817, 0.0], [0.0, 0.0, 0.0, 1.0]]
[[0.9996242168594817, 0.0, -0.027412133592044294, 0.0], [0.0, 1.0, 0.0, 0.0], [0.027412133592044294, 0.0, 0.9996242168594817, 0.0], [0.0, 0.0, 0.0, 1.0]]

Maya Version

• Maya Version: 2023-2027
• OS: Windows 11

mGear Version

• mGear Version: 5.3.2

Error Log Formatting

No exception is raised.

Additional Context

PyMEL's implementation converts numeric Euler angle inputs according to its unit handling:

dt.EulerRotation([math.pi, 0, 0], unit="radians")
dt.EulerRotation([180, 0, 0], unit="degrees")

A possible backward-compatible fix would be to support the unit keyword without changing the current default behavior.
If this direction sounds reasonable, I can prepare a small PR for it.

[miquelcampos]

Hello @yamahigashi Thanks for the feedback and sorry for the late reply. I will add this to the current project and check it ASAP