OpenMaya.MPxNode.isPassiveOutput Challenges

[Matin Falahmanesh]

Hi everyone,

I'm currently facing some challenges while writing a custom Noise node in Maya. Here's what I'm aiming to achieve:

I want to create a custom noise node that sits between an animCurve connection and a transform attribute (e.g., tx). This node should take the animCurve output, perform some noise algorithms, and then output it back to the transform attribute (e.g., tx). I've managed to write the node to a certain extent, and everything seems to work as expected.

However, I'm encountering an issue. I want animators to still be able to set/move/rotate values on the attribute and see attribute keyframes in their timeline. I've tried using om.MPxNode.isPassiveOutput, and it seems to "unlock" my attribute successfully. Now, I can move/rotate my object around while the noise is connected. However, the values don't pass through to my animCurve node. If I move the timeline or perform any action, the values reset.

I'm unsure if my approach is correct, or if I'm missing something. Could you please share your thoughts and ideas on this matter?

-I've managed to achieve something similar with the pairBlend node, but I ran into this issue and I'm exploring alternative ways to achieve it without pairBlend. I've attached a picture of my pairBlend workaround for reference:

Regards, Matin F

[Marcus Ottosson]

Hello again, it's me from that Autodesk forum thread. :)

Indeed I was also unable to tackle this challenge, which is ultimately an issue of cyclic dependency.

1. User manipulates transform

2. Transform feeds into custom noise node

3. Noise node feeds into transform

The pairBlend does a good job at providing users with what is effectively a translate/rotate gizmo for your noise node. But, this was the issue I also ran into and spent all of my strength to try and resolve. (For context, here's where I gave up and found a better method: https://learn.ragdolldynamics.com/releases/2021.09.27/#demo-1-basics)

It seems like such a simple thing too; so close to working! But alas, the issue was consistent across platforms and versions of Maya, so I have little faith that this will ever be addressed. Odds are the behaviour is necessary for normal evaluation of some other feature/node/plug.

Instead, I would suggest you do what I ultimately did; which is to implement your own gizmo. Then the user can select your noise node and gain access to the same translate/rotate gizmo to animate it. It won't be as transparent, as they would have to select a different node (although there are workarounds for this too!) and even implementing a manipulator is *hard*. The API is (in my opinion) not very well thought out, which I expect explains why we don't see many custom manipulators in Maya developer land.

Luckily, in your case, the gizmos are the normal translate/rotate gizmos and which have default implementations and are mostly available for copy/paste amongst the devkit samples.

- https://github.com/sonictk/Maya-devkit/blob/master/win/devkit/plug-ins/moveManip/moveManip.cpp

- https://github.com/sonictk/Maya-devkit/blob/master/win/devkit/plug-ins/rotateManip/rotateManip.cpp

As for the workaround; Maya has another quick which can work to your advantage here; when you activate the manipulator (T key, by default) Maya will query the currently selected node for its custom manipulator, like the ones above. If none is found, it will then query the *first shape of the currently selected transform*.

And that's key right there; if you make your noise a shape node and let it be the first *and only* shape of a transform, then your users will be able to select the node (which you can also draw yourself) and press T to start manipulating it. Now, the quirk is that it cannot be a sibling to another shape, no matter the type, or Maya will refuse to show the manipulator, So if you use it on an animation control which already has a NURBS shape, then you are out of luck.. But, maybe this is enough!

Hope it helps.

Best,

Marcus

[Matin Falahmanesh]

Hi Marcus! Thanks for your reply!

Unfortunately, writing a manipulator is not an option for me as I want animators to still be able to use Maya's native manipulator. However, I did take a look at your implementation of a custom gizmo/manipulator in the Ragdoll and well... it's genius!

For those who come across this post in the future: I ended up using a custom MPxTransform for my auto-rig controllers, and MPxTransformationMatrix did the trick for adding my noise to the node's matrix itself (I can't add an offset group for controllers for a lot of reasons). Regards, Matin F

[Marcus Ottosson]

For those who come across this post in the future: I ended up using a custom MPxTransform for my auto-rig controllers

Please no! :O Defcon 2!

This will come back to bite you, I can guarantee it. Everything in Maya is built around the vanilla MPxTransform, especially constraints. Any change or alteration - especially with regards to how it is evaluated - can and will break native things your animators take for granted. Parent constraints will have subtle differences or be non-deterministic. Orient constraints will struggle to resolve rotation when X and Z are locked. Commands like Match Transforms will fail. Tons and tons of subtle assumptions both Autodesk and everyone else (including Ragdoll) have made will no longer be true. You are effectively writing your own Maya inside of Maya, replacing the most fundamental building block upon which everything is built.

To provide some anecdata, I only know of 1 studio that does this for their rigs, and have spent countless hours - internally and externally - trying to work around it. But even they are unable to use Maya’s native constraints, and are forced to now carry on writing their own Maya inside of Maya with their own point and orient constraints. Where does it end?

So, for those who do come across this post in the future, please please do not implement your own MPxTransform. 😅

as I want animators to still be able to use Maya’s native manipulator

About this, not to forget that custom manipulators are equally native as the Translate, Rotate and Scale manipulators. On your keyboard right now, you have W, E and R and next to it the T key. That’s the one that activates your manipulator. If you inherit from the example I provided, it will look and act just like Maya’s manipulator.

You can try a few, by selecting e.g. the Bend deformer and pressing T. Or making a Spot Light and pressing T. Those are custom, and equally native. It is a truly underappreciated and underused aspect of Maya, that is much much preferable to making your own MPxTransform (even though that’s a low bar 😊)

EDIT: Before posting this, I re-read what you said and noticed you said “auto-rig controllers”. If you mean nodes only used during use of your auto-rigger, and not in the actual final animation rig, then this is probably fine and damage will have been contained. But it also sounds like you expect animators to interact with your controller, in which case no no no no.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/bfa4380c-13f5-471c-9f07-a6ba50fe7a0fn%40googlegroups.com.

[Matin Falahmanesh]

Hi Marcus,

Thank you so much for your detailed response and the valuable insights you provided :) . I appreciate your concern and expertise on the matter. It's clear that using a custom MPxTransform can introduce complexities and potential issues with native functionalities like constraints.

I genuinely want to avoid any pitfalls that may arise from such an approach. Your warning about the impact on native things, especially constraints, is duly noted. I'll reconsider my strategy and explore alternative solutions.

Regarding custom manipulators, I appreciate the clarification. I'll take a closer look at the example you provided and explore integrating custom manipulators to maintain compatibility with Maya's native functionalities.

Thanks again for taking the time to share your knowledge and experience. Your input is immensely valuable.

Best regards,
Matin F