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 <mailto: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>
[mailto: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
<mailto: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 <mailto:richb...@mac.com>> wrote:
On Oct 25, 2013, at 7:01 PM, John Vanderbeck
<john.vanderb...@primefocusworld.com
<mailto: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 <mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
