I ended up doing exactly like Frank suggested. Used a CurveTool to force a refresh.
*John Vanderbeck* *2D Pipeline TD* *T:* +1 604 733 7030 1205 Melville Street, Vancouver, B.C, V6E 0A6, Canada. primefocusworld.com <http://www.primefocusworld.com> On Fri, Nov 8, 2013 at 5:41 PM, Dennis Serras <dennis.ser...@bydeluxe.com>wrote: > Did you ever come up with a solve for this? I’m creating a tool to > evaluate the bbox of a read node over the entire range of a shot, and I > haven’t found a way get it to give me the correct result without running an > executable (ps, what’s the fastest executable?). > > > > > > *den serras * > > @ stereoD > > > > *From:* nuke-python-boun...@support.thefoundry.co.uk [mailto: > nuke-python-boun...@support.thefoundry.co.uk] *On Behalf Of *Frank Rueter > *Sent:* Wednesday, October 30, 2013 11:42 AM > *To:* nuke-python@support.thefoundry.co.uk > *Subject:* Re: [Nuke-python] Trying to script O_Solver > > > > I'm not aware of one, but I have been doing lots of other things besides > nuke scripting recently, so I might be missing something. > > On 31/10/13 01:05, Steve Newbold wrote: > > Hi Frank, > > Weirdly, coming to this thread doing the exact same thing with the > O_Solver. I've used this work around a while back and its been ages since > I've done any proper Python scripting, but I do vaguely remember someone > (Ivan???) saying there was going to be a better method of forcing a UI > update. I guess this didn't happen? > > Cheers, > Steve > > > On 26/10/13 08:48, Frank Rueter 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 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 > > > > This e-mail and any attachments are intended only for use by the > addressee(s) named herein and may contain confidential information. If you > are not the intended recipient of this e-mail, you are hereby notified any > dissemination, distribution or copying of this email and any attachments is > strictly prohibited. If you receive this email in error, please immediately > notify the sender by return email and permanently delete the original, any > copy and any printout thereof. The integrity and security of e-mail cannot > be guaranteed. > > _______________________________________________ > 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
