How would i get a callback from an attr that is changing due to an incom

[markth]

... an incoming connection? .. not changing due to direct user input... so that as the attr is changing due to the incoming connection i can capture this fact and use it as a trigger in my node.... (and a bonus would be to get that value as well.. but not totally necessary).

i wrote a python plugin in maya 2008 that makes a custom node where i attatch:

MNodeMessage.addAttributeChangedCallback

then, as a user directly scrubs the attrs on this node, or uses setAttr it triggers all the message i am looking for.

but if i connect another attr into an attr on this node.. and scrub that attr, i get nothing.

the "attributeChanged" set of messages does not seem to have anything in it that will trigger the callback when the attribute is changing due to an incoming connection. only when the user scrubs the attr directly  (and various other messages about connections incoming and out going as they are made or broken... i have tested all the enums (messages) involved in
MNodeMessage::AttributeMessage to no avail yet....

i have also tried:

MNodeMessage::addNodeDirtyPlugCallback

( now that this is supposedly fixed in 2009m )

to try and capture the fact that the attribute is not changing directly, but due to it having an incoming connection from another node.
but this trigger only happens once.. (is triggered once) when i change the incoming attr.. not over and over again as the attr is changed due to the incoming connection from the other attr. i have to deselect the driving node, select plugin node, then select driver again and change its attr to get the one dirty callback over again.

question:
how do i add a callback for the case where an attr is changing, but not because of direct user input, but because it has a direct incoming connection and the incoming attr is what is making the attribute change?

JooJaa.. ?

an ideas?

[joojaa]

Your not supposed to.

Attributes and nodes don't update when their value changes. So your connected node does not pass a updated value. What it does pass is dirty bits so you shod react on dirty bits. Or actually you should not.

What you should do is derive your node out of something thats last in line type wich then automatically propagates the update. So you could inherit your node form a locator and it would trigger a update cycle automatically.

[markth]

ok, that sounds good.. about the deriving my node out of somthing that is "last in line type"..

( my current plugin node is MPxTransform)

so how do i find out what node types are last in line type?
you mentioned a locator, where did you find this out? is there a list and a description of what last in line means?

if i register a nodeDirty callback for my node that is derived from this type of object, when one of its attrs has an incoming connection, and that attr is changing..errr... being dirtied... due to this incoming connection, will i get a triggering for every value change? if i add a dirty callback to this node? and is that because it is a node of this specific last in line type?

(forgive me because i did not know there was a speacial type of node 'last in line' that would allow its attrs to behave like this being changed by an incoming connection.)

thanks Joojaa,
you always set people on the straight and narrow to do it right instead of do it wrong!

[markth]

(ps. my current plugin node is MPxTransform)

[markth]

ps, ps...

so i understand the whole push-pull of maya's dependency graph evaluation. (at least in principle)
and thinking it through, it makes sense that my connected attr on my pluginNode, being changed by the output of a regular old maya tran node, would not be dirtied (and thus trip the dirty callback) unless the value of the attribute with the connected input was being requested (pulled on) some how. thus redirtying the attr.

but i would still like very much to have the change of this attribute trip a callback. is there any API way of asking, "ok, specific attr on my pluginNode, have you changed?.. reguardless of wheather by user input, or by another attr?..

it just seems like there has got to be a way!

thnks.
-mt

[joojaa]

What does your compute look like? And your attribute affects init look
like. (i dont really need to see the node just what the idea is) Since the transfrom is a next last node in line  it will update
as long as it has somethuing thet displays underneath it.

Thing is maya does not change the attributes, untill you evaluate
the compute function of your node. It works in opposite backwards than
you think. Your attributes never change untill you gop to processing
them for whatever wopuld happen when you are changing

r old maya tran node, would not be dirtied (and thus trip the dirty callback) unless the value of the attribute with the connected input was being requested (pulled on) some how. thus redirtying the attr.

No maya does not trigger based on the input, it triggers based on output of your node. If your node has no output then maya never ever triggers it. Your desciption actually demonstrates why it does not work.

So internally a node has  2 plug port arrays: Inputs and Outputs. theese are connected by a attribute affects network. Where you tell this input affects this output, the input gets updated when the output gets requested. Not at any other time.

it just seems like there has got to be a way!

There is but first one has to explore the possible fact that it would work had you just done it right. YOu jsut dont ask for callbacks in mayas design no matter how familliar that would be to you. You learn the api first. Because IF you subvert mayas behaviour you may drop your ah so comfortable 30+ fps update to a measley one frame per 10 seconds. Simply because maya may actually pulse the dirty bits several times in one update cycle. Worst case scenario being that maya just marks your node dirty all the time having no actuall time to do anything else.

So no matter what you want it is mayas design for you to wait for the update cycle. Its like jumping a que, you may think your special but for the functioning fo society its best if nobody thinks of themselves as special.

[joojaa]

if i register a nodeDirty callback for my node that is derived from this type of object, when one of its attrs has an incoming connection, and that attr is changing..errr... being dirtied... due to this incoming connection, will i get a triggering for every value change?

No you won't actually. See it works like this.

nodeA ->nodeB->nodeC

nodeA attrib that affects gets dirty:

nodeA dirty ->nodeB dirty->nodeC dirty

you get notification. But node B is still dirty it will never ever clean up untill somebody actually asks the output plug value. Shapes that get affected by C would do that. But as i said the value in A can change many times before maya decides to update, because maya estimates the time the opengl needs to update. If you now force your way here maya breaks down. OR worse your answer is not what the current stae is but what some slightly future state would end up being because your computation ahs iterated many times when others have done one compute.

you always set people on the straight and narrow to do it right instead of do it wrong

yes offcourse 99.99999% of people only want to subvert the system to work unlike it works because they didint understand what they are doing.

[markth]

little follow-up:

so i have now successfully added a feature to activeAttrNode.py, that allows the user to connect the output of any maya attr to the input of a dynamic attr on the activeAttrNode. then, in a string attr on the activeAttrNode (attr2command) that relates the dynamic attr to a function, one can now define either "attribute message filter", "attribute dirty condition" or both. whats more, the user can further define persistent dirty or normal dirty behavior for the triggering of the callback..

now a user can test any arbitrary group of normal maya node attrs for attribute change by attatching them to this node. this is a big improvement on the scriptJob attrChange functionality using the -allchildren flag (testing a compound parent to detect activity on all its children) because first of all, that does not work as described in the docs, and second, compound dynamic attrs are flakey at best to create in maya now adays, but most importantly,  this does not require the generation, management  and destruction of many scriptjobs to test for attrchange. whats more, the user can dectect and utilize, via callback, many other attribute signals that are not available with the scriptjopb command, such as 'eval', incoming outgoing connect/disconnect 'set', 'renamed', etc etc.. see enum values "MNodeMessage::AttributeMessage".

in testing the persistent dirty functionality, there are no ill effects as yet. further, i have timed the difference between the creation of 60 individual attr change scriptjobs, vs 60 individual connections to the activeattrnode using the persistent dirty functionality to trigger a simple callback function. there are two important differences in efficiency:

1. the scriptjob is always there, always activly listening for specific attribute change, and has a fairly large memory footprint. the node only triggers passively when any incoming connection is changed and has a smaller memory footprint; (as far as ram used by maya as far as i can currently tell)....(and is easier to create abnd destroy than the same number of scriptJobs.)

2. the triggering of the callback its self happens about 15% faster on my computer (according to timerX) than the same function called via numerous scriptjobs.

Because this node has no downstream connections, it is the only node ever pulling on its own attributes. when you change the attr on its incoming connection, the callback is tripped once, or consistently during manip, fcurve edit, or timeline scrub, based on user preference, and then immediately stops when that attr stops changing. there is no leakage, no build up, no crashes. if i were to (and i have) pull on the monitor attr or the attr being monitored in the callback function itself, still no spinning out of control, no crashes, no leaks.. you just get twice the number of callbacks.. but as soon as the input attr stops changing, the cycle stops as well. did i mention no spinning out of control?

i believe that this is a great example of a usefull plugin that bends the rules of push-pull, (as maya itself does internally) and is a credit to the fact that maya allows the user to do this.. and thus ultimately is in maya's extended plan for the user.

in conclusion: if maya crashes while you are experimenting.. don't have a cow. understand the rules, and then break them. don't be afraid of pushing the boundries, maya wants you to.. it gave you an api that lets you think outside the box. with this power comes responsability, but remember.. its just a cartoon.. or a game.. or whatever, your not driving a schoolbus full of kids. don't be afraid to crash maya.

-thanks for the help!

[joojaa]

Well you should have implemented this node a s shape the shape would then automatically trigger maya whenever it deems to update the viewport

[markth]

Nice..

i will have to try that out.
i was thinking of refactoring this node anyway.
this might allow some simplifications.

thanks for the tip Jooja.