try hijacking a text node you can grab the hash function there and if that is executed make the text change that will force evaluating the tree
Florian Strobl compositor phone: +1 310 906 9493 flotv.info On Fri, Apr 8, 2011 at 10:05, John Vanderbeck <[email protected]>wrote: > Is there any way to setup a heartbeat to call a function every X > milliseconds? > > Sent from my iPhone > > On Apr 8, 2011, at 12:34 PM, Nathan Rusch <[email protected]> > wrote: > > I’ve got an idea simmering on the back burner to try and write a node > that fires some kind of Python callback or otherwise indicates that the > upstream tree has changed and is in the process of being re-calculated, and > then another when it’s done processing. It’s fairly low priority though, so > I’m not sure if/when I’ll actually be able to get around to it (or how > doable it will turn out to be). I’ve run into several situations now where > it would be incredibly useful to have a node that indicates tree > invalidations and exposes them for use in Gizmos/Python scripts, since > testing/filtering .opHashes() on every knobChanged trigger feels overkill > and fairly inefficient/slow. > > -Nathan > > > *From:* John Vanderbeck <[email protected]> > *Sent:* Friday, April 08, 2011 9:12 AM > *To:* Nuke Python discussion <[email protected]> > *Subject:* Re: [Nuke-python] Creating a custom scripted node? > > So what I am finding is that the knobchanged callback always occurs > BEFORE the frame is updated. I need a way to have my script called AFTER the > frame has been updated. Any thoughts? > > Sent from my iPhone > > On Apr 7, 2011, at 10:25 PM, Ivan Busquets < <[email protected]> > [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]><[email protected]> > [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> <http://www.johnvanderbeck.com> >> http://www.johnvanderbeck.com >> >> >> On Thu, Apr 7, 2011 at 10:02 AM, John Vanderbeck >> <<[email protected]><[email protected]> >> [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]><[email protected]> >>> [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> >>> http://www.johnvanderbeck.com >>> _______________________________________________ >>> Nuke-python mailing list >>> <[email protected]><[email protected]> >>> [email protected] >>> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python><http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>> >>> >>> >>> _______________________________________________ >>> Nuke-python mailing list >>> <[email protected]><[email protected]> >>> [email protected] >>> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python><http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>> >>> >> >> _______________________________________________ >> Nuke-python mailing list >> <[email protected]><[email protected]> >> [email protected] >> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python><http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> > > _______________________________________________ > Nuke-python mailing list > <[email protected]>[email protected] > <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> > 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
