addManipToPlugConversionCallback appears to break AttributeChangedCallback

[Sebastian_Wiendl]

Hi everyone,

I have been experiencing something that appears to be a bug, but maybe I am just missing something?

What I want to do is to add a MPxManipContainer to a MPxLocatorNode that allows to set a rotation and a translation.

It is important here that I do not want to set the rotation and translation of the actual locator, but set attributes on the locator that represent rotation and translation, if that makes sense, i.e. modiying values with the manipulators sets attributes on the locator, but does not rotate or translate it.

I am using a MFnRotateManip and a MFnFreePointTriadManip and am using the addManipToPlugConversionCallback for the MFnRotateManip to set the rotation of the MFnFreePointTriadManip. This way, translation and rotation manipulators are in local space.

But unfortunately, this seems to break the attribute changed callback that I have on my MPxLocatorNode.

Please find attached a simple reproducible that is based on the devkit swissArmyManip plugin.

Note, I had to rename it to .text because it wouldn't let me attach a .cpp. So please change the extension after downloading.

To test:

Replace the code in the swissArmyManip.cpp in the devkit with the one attached to this post and compile and load up plugin as you would normally.

Then create a node (mel: createNode swissArmyLocator;)

If you select the swissArmyLocator1 node and go to its Attribute Editor, please open up the frame layout for the Extra Attributes.

You'll see Test Rot, Test Pos, and a Test Bool.

Now, if you check and uncheck the Test Bool several times, you will see the following output in the Script Editor:

// SwissArmyAttributeChangedCallback: swissArmyLocator1.testBool // 
setAttr "swissArmyLocator1.testBool" 0;
// SwissArmyAttributeChangedCallback: swissArmyLocator1.testBool // 
setAttr "swissArmyLocator1.testBool" 1;
// SwissArmyAttributeChangedCallback: swissArmyLocator1.testBool // 
setAttr "swissArmyLocator1.testBool" 0;
// SwissArmyAttributeChangedCallback: swissArmyLocator1.testBool // 
setAttr "swissArmyLocator1.testBool" 1;
// SwissArmyAttributeChangedCallback: swissArmyLocator1.testBool // 
setAttr "swissArmyLocator1.testBool" 0;
// SwissArmyAttributeChangedCallback: swissArmyLocator1.testBool // 
setAttr "swissArmyLocator1.testBool" 1;

The // SwissArmyAttributeChangedCallback: swissArmyLocator1.testBool // message is printed from within my attribute changed callback function to prove that it is being called.

Now, if I prress T on the keyboard to bring up the Manipulator tool, you will see the translation and rotation manipulators appear.

If you now uncheck and check the Test Bool, the output looks like this:

setAttr "swissArmyLocator1.testBool" 1;
setAttr "swissArmyLocator1.testBool" 0;
setAttr "swissArmyLocator1.testBool" 1;
setAttr "swissArmyLocator1.testBool" 0;
setAttr "swissArmyLocator1.testBool" 1;
setAttr "swissArmyLocator1.testBool" 0;
setAttr "swissArmyLocator1.testBool" 1;

So, for some reason, the attribute changed callback is not called anymore.

If I comment out line 217 in the attached reproducible, which adds the addManipToPlugConversionCallback, I do receive attribute changed callbacks even when the manipulator tool is activated.

Obviously, this is not a solution, because, now, the translation manipulator does not get rotated with the rotation manipulator.

Any help would be much appreciated.

Cheers,

Sebastian

[jmreinhart]

I will take a look at the callback issue when I have time. But I did some testing with the freePointTriadManip and in my testing it seemed like "setDirection" is not a functional method for that manipulator and it actually won't rotate the manipulator, it seems like it's just a leftover from however the initially implimented the lineManip and freePointTriadManip. I'd love to find out that I was wrong but I just wanted to warn you.

[Sebastian_Wiendl]

Thank you very much @jmreinhart 

This is really a peculiar one.

I specifically tested for this post in Windows Maya 2020 (no updates), but I am sure I also had the same behavior in 2018 when I tested it a while back.

Regarding the setDirection, it appears to do what it is supposed to do in my tests.

Anyways, looking forward to your feedback once you have had time to run my file.

Cheers,

Sebastian

[jmreinhart]

Very strange. I went back to a plugin I did several months ago where setDirection was having no affect, and now it's working. Not sure if it was in issue with the version I was compiling for, or more likely user error on my part. I'm very happy to know that it works.