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,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
