The only thing I figured out is to for loop and change the read node I'm
analyzing to the first frame, run the analysis, then change it to the next
frame - but not actually change the viewer frame Nuke thinks is current. I
haven't tried that with time offsets, but perhaps that would work for you?


On Tuesday, December 17, 2013, Steve Newbold wrote:

>  Sorry to re-open this thread but I'm having real inconsistencies using
> the CurveTool 'hack'.  I have it working fine in one script but it simply
> won't work in another.  It would be really, really useful to have the
> ability to force Nuke to update the UI with python so we can do things like
> this without resorting to workaround.  Does anyone know if there is a
> feature request for this?
>
> Steve
>
> On 09/11/13 02:20, John Vanderbeck wrote:
>
> 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….
>
>
>
>
_______________________________________________
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

Reply via email to