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
