Thanks Ivan. You got me looking at it in a different light and I've got it working now. I honestly didn't even realize that you could run full on python scripts as expressions!
Sent from my iPhone On Apr 8, 2011, at 2:56 PM, Ivan Busquets <[email protected]> wrote: > > Unfortunately what we are doing is modifying the image in this node. > > Yeah, what I'm saying is, you may be able to modify the image by redoing your > logic with standard nodes inside your gizmo (mults, adds, merge expressions, > etc) that combine your image with your sampled colors. > Does that make sense? > > > And therein I think lies the problem. So each node, even downstream ones, > don't wait for the nodes above to finish? > > It depends on what the node does. If the node needs the whole image to be > computed before doing its thing, then yes, it will have to wait until all > processing above is done. Otherwise, if it can do its job scanline by > scanline (or using just a bunch of them, like most filters), then you will > have multiple threads running through the tree in parallel. > > > On Fri, Apr 8, 2011 at 11:45 AM, John Vanderbeck <[email protected]> > wrote: > And therein I think lies the problem. So each node, even downstream ones, > don't wait for the nodes above to finish? > > Unfortunately what we are doing is modifying the image in this node. > > Sent from my iPhone > > On Apr 8, 2011, at 2:09 PM, Ivan Busquets <[email protected]> wrote: > >> I see. >> The problem I see with that is that, typically, trees are rendered >> multithreaded, scanline by scanline, so your downstream nodes will usually >> start doing their job long before an upstream node has finished processing >> the whole image. >> Do you need the result of those samples to be stored specifically in knobs? >> Otherwise, you could use expression nodes inside your gizmo, do your >> sampling there, get full-sized images with the color of your samples, and >> use those as needed. >> >> Would that help in your case? >> >> >> >> On Fri, Apr 8, 2011 at 9:42 AM, John Vanderbeck <[email protected]> >> wrote: >> What I need to do is sample various pixels in the image to provide data to a >> downstream node. This calculation needs to happen in pseudo realtime and >> transparently to the user. Unfortunately for various reasons it needs to be >> done as a python script and not as a plugin. >> >> This should be doable and in fact it all works fine EXCEPT getting the >> script fired off at the proper time. >> >> Sent from my iPhone >> >> On Apr 8, 2011, at 12:29 PM, Ivan Busquets <[email protected]> wrote: >> >>> knobChanged fires immediately after a knob is changed. It doesn't have >>> anything to do with the frame updating or not, as it could be triggered by >>> a knob that doesn't force your viewer to update (as in, a knob in a node >>> that's in a different tree than the viewer, or simply moving a node in the >>> DAG). >>> >>> What is it that you're trying to do? I assumed the calculations you need to >>> do in your callback just needed to check for certain knobs in all nodes >>> upstream, since you were using knobChanged, but it sounds like you want to >>> sample pixel data from the image, right? >>> Depending on what you need to do, I think you'll either need to make a >>> plugin, or use nodes inside your gizmo to get the info you need from the >>> image (like a Dilate/Erode if you need to get the max/min value, or an >>> Expression node if you want to sample from a specific pixel coordinate, etc) >>> If you need to do something more involved with the image data, though, you >>> may need to go the plugin route. >>> >>> Cheers, >>> Ivan >>> >>> On Fri, Apr 8, 2011 at 9:12 AM, John Vanderbeck <[email protected]> >>> wrote: >>> 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 >> >> _______________________________________________ >> 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
