Hi John, If you already have a callback that reliably fires up frequently enough, you should be able to use node.opHashes() as Frank suggested.
Not sure how you tested it before, but to my knowledge any change upstream of a node should change the hash of that Op, as long as you have your viewer somewhere downstream from it. The hash should change whether it's an input change, changing a knob of a node upstream, moving to a different frame (if there's a sequence or something animated upstream) etc., but the Viewer must be somewhere below, or else those nodes won't be validated, and their hash won't change. It seems to me that the trickiest part of it would be having a callback that gets called "at least" as often as you want it to, but not too often. If you have a global knobChanged callback targeting all nodes, this will be triggered very often (not only on explicit knob changes, but also if you move nodes in the DAG, connect/disconnect inputs, etc). If you're happy with that, though, and all you want is to check whether a more intense calculation is really needed, opHashes should work for that purpose. Not sure that will help you much, but it may give you some ideas. Cheers, Ivan On Thu, Apr 7, 2011 at 6:23 PM, John Vanderbeck <[email protected]>wrote: > I have things working to some extent, but i'm not 100% happy with it. > > By registering a global callback with nuke.addKnobChanged(), and then > filtering the events to only fire off if the calling node is upstream, i've > got it mostly working. Performance could be better though, and I really > wish I could just know if I really need to recalculate things or not. > > Anyway i'm now running into weird issues that I think are due to how Nuke > handles the callback stack. randomly, but quite often, the callback seems > to occur before the image data is really completely redrawn and thus my > script's calculations end up wrong. I haven't found a work around for this > yet :( > > A better way of re-calculating when the upstream changes would be ideal. > > > - John Vanderbeck > - http://www.johnvanderbeck.com > > > On Thu, Apr 7, 2011 at 10:02 AM, John Vanderbeck > <[email protected]>wrote: > >> Thanks Frank. My main issue is more with callbacks. How can Ivey my script >> to even be run by Nuke in the first place when things change. I can tap in >> with knobChanged on a global level but if I do that then i get hit everytime >> anything changes, even if it isn't upstream. It's also global and I was >> hoping for something self contained in the node. >> >> I looked at opHashes and best I can tell, it only changes based on what >> nodes are connected not if the knobs on those nodes change. IOW if you >> attach a blur to the custom node's input, the hash changes. But if you now >> adjust that blur the hash does not change. >> >> Sent from my iPhone >> >> On Apr 6, 2011, at 9:45 PM, Frank Rueter <[email protected]> wrote: >> >> have you tried checking nuke.selectedNode().opHashes() to see if it has >> changed? >> >> >> On Apr 6, 2011, at 3:17 AM, John Vanderbeck wrote: >> >> Hey all, sorry for what is probably a really noob question, but I'm not >> finding the answer in the docs. >> >> I write little scripts for things all the time, but what I need to do now >> is essentially make a custom node that runs a python script whenever >> anything upstream is changed. How would I go about doing this? >> >> - John Vanderbeck >> - <http://www.johnvanderbeck.com/>http://www.johnvanderbeck.com >> _______________________________________________ >> Nuke-python mailing list >> <[email protected]> >> [email protected] >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> >> _______________________________________________ >> Nuke-python mailing list >> [email protected] >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> > > _______________________________________________ > Nuke-python mailing list > [email protected] > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > >
_______________________________________________ Nuke-python mailing list [email protected] http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
