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 
Sent: Friday, April 08, 2011 9:12 AM
To: Nuke Python discussion 
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]> 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
          _______________________________________________
          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



--------------------------------------------------------------------------------
_______________________________________________
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

Reply via email to