Genius Frank this works! You saved my bacon man.
On Sat, Oct 26, 2013 at 8:35 AM, John Vanderbeck <jwvanderb...@gmail.com>wrote: > That is actually brilliant Frank. Dirty as heck but brilliant :) > > John Vanderbeck > http://www.johnvanderbeck.com > jwvanderb...@gmail.com > > > > On Oct 26, 2013, at 12:48 AM, Frank Rueter <fr...@beingfrank.info> wrote: > > I remember having to deal with this sort of thing in the past and using a > nasty workaround like creating a dummy node that can be executed (e.g. > CurveTool), changing to the frame in question, executing the dummy node on > that frame (to force nuke to refresh the frame context), then doing what > you actually want to do on that frame, move to the next frame, rinse and > repeat, and in the end just delete the dummy node. > > There is probably (hopefully) a more elegant way now but this is how I > remember getting around the problem quickly. > > > On 26/10/13 4:52 PM, John Vanderbeck wrote: > > Right but the problem is i'm not actually moving through the frames. Just > using nuke.frame() to set 3 frames. Maybe a tight loop trying to verify > the frame has taken. Worth a try. > > This is an automated script that is supposed to 1) set three keyframes > on then 2) o_solver (first, middle, last), and then render. Problem is > that #2 is happening before #1 is finished :) > > - John Vanderbeck > - http://www.johnvanderbeck.com > > > On Fri, Oct 25, 2013 at 8:14 PM, Richard Bobo <richb...@mac.com> wrote: > >> >> On Oct 25, 2013, at 7:01 PM, John Vanderbeck < >> john.vanderb...@primefocusworld.com> wrote: >> >> Thanks for the thoughts Rich, but I don't think its a solution. >> >> Sleeping is one of the first things I tried, but it blocks Nuke so the >> functions don't actually happen. Nuke races to try and do them all at once >> after the sleep and just drops most of them. >> >> As for using a conditional, i'm not sure how I would set that up, but >> i'm fairly certain it isn't an option because these keys need to be set, so >> that Ocula can do its thing BEFORE rendering begins. >> >> Unless I misunderstood you? >> >> >> I'm probably not getting the whole drift of what's happening, but what >> I was suggesting was, just before the execute, doing the test… >> …… >> …… >> …... >> if nuke.frame() == firstFrame: >> addKeyKnob.execute() >> >> It sounds too easy, so I'm sure that's not what the problem is. >> >> Rich >> >> >> - John Vanderbeck >> - Prime Focus World, Vancouver >> - 2D Pipeline / Comp TD >> >> >> >> On Oct 25, 2013, at 1:29 PM, Richard Bobo <richb...@mac.com> wrote: >> >> John, >> >> This may be to simplistic, but didi you try making a condition for the >> execute to be something similar to nuke.frame() == firstFrame ? >> Maybe use a try: statement with some number of tries or with a sleep time >> in-between…? Just thinking…. >> >> Rich >> >> >> >> On Oct 25, 2013, at 1:41 PM, John Vanderbeck < >> john.vanderb...@primefocusworld.com> wrote: >> >> Hey all, >> >> Been going out of my mind the last few days and hoping one of you >> geniuses might be able to help ease my pain. >> >> Basically I need to script the use of O_Solver to set three keyframes. >> >> I'm running into issues though because of the way Nuke handles threads. >> If I do something like this all in the main thread: >> >> solverNode = nuke.toNode("O_Solver1") >> addKeyKnob = solverNode.knob("addAnalysisKey") >> print "Jumping to frame %d" % firstFrame >> nuke.frame(firstFrame) >> print "Setting Key" >> addKeyKnob.execute() >> >> Then what happens is the key gets set, but NOT on the proper frame. >> Nuke doesn't seem to have finished setting the frame before the next call, >> so the key ends up being set on whatever frame the playhead happened to be >> on. >> >> So I then reworked things to do it all in a subthread. This worked >> perfectly, but then I had the problem of knowing when it was done. If I >> tried to block the main thread while waiting on the subthread, then Nuke >> again wouldn't properly set the keyframes. Unfortunately it is vital that >> I be able to wait and not return until all keyframes are set :( >> >> Any thoughts? >> >> -- >> - John Vanderbeck >> - Prime Focus World, Vancouver >> - 2D Pipeline TD >> >> _______________________________________________ >> Nuke-python mailing list >> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> >> _______________________________________________ >> Nuke-python mailing list >> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> >> _______________________________________________ >> Nuke-python mailing list >> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> >> >> _______________________________________________ >> Nuke-python mailing list >> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> > > > _______________________________________________ > Nuke-python mailing listnuke-pyt...@support.thefoundry.co.uk, > http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > > _______________________________________________ > Nuke-python mailing list > Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > > > _______________________________________________ > Nuke-python mailing list > Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > -- - John Vanderbeck - Prime Focus World, Vancouver - 2D Pipeline TD
_______________________________________________ Nuke-python mailing list Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
