Thanks, I will take a look at opHashes() again. It is always quite possible I just missed something in testing it. Bouncing around from one project to another will do that to you :)
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. > Yeah there is the crux of it. The knobChanged is manageable by filtering out fluff events like those you mention, and checking for upstream changes (i'm doing it a slightly harder way right now), but it in fact is NOT reliable. It seems that occosionally - but far too often - Nuke fires the callback BEFORE it has finished processing the image. As a result our calculations on the image end up incorrect. I need a way to reliably be told, "Hey the image has changed and its finished updating", so I can recalculate. I thought updateUI was going to do that but Nuke refuses to send it to my node unless the frame changes it seems. - John Vanderbeck - http://www.johnvanderbeck.com On Thu, Apr 7, 2011 at 10:25 PM, Ivan Busquets <[email protected]>wrote: > 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 > >
_______________________________________________ Nuke-python mailing list [email protected] http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
