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

Reply via email to