On 01/05/12 21:18, Dan Rosen wrote:
Greg,
As Dan said we didn't know about that floating point number thing. How do th=
e numbers correlate to Write nodes?
To convert the numbers to write node names, use the number as an
index into the list
of names.
So if your node names are A,B,C,D.. then save them to a file,
one name per line,
and then the render script uses the numbers at render time to
pick which line in the
file as a way to convert the numbers into names.
So for instance, at render time let's say RUSH_FRAME ends up
being "10.3",
so you parse out the frame number (10) and the writenode number
(3),
then use the '3' to pick the third line in the file, which would
have "C" in it.
Now you have a node name that you can use for rendering.
Hust save the list of your write node names to a file in the
job's log directory
on submit, so that the render script can access it easily at
render time.
As Dan also mentioned we list the Write n=
odes by name in the Rush submit so that users can turn off any Writes on the=
fly. We initially get that list from the Write nodes that they have selecte=
d or all Write nodes if nothing is selected. We also ignore disabled Write n=
odes, etc, etc.=20
We normally render all Writes in one job, but this special case we have ligh=
ting td's that want each Write to be a separate job for a workflow reason. S=
ounds like you've given us an i between option to think about.
Hmm, if you want the jobs to be separate for a "workflow
reason",
I guess I'd need more info to understand why that's better than
having one job handle all the write nodes.
Certainly its easy to get nuke to run each frame (or batch of
frames)
to render *all* the nodes in a single process, but I was
thinking
you were perhaps using separate jobs just so that each writenode
runs
on a separate machine for speed. If that's the only reason, then
I think
the above floating point frame trick would be better, to avoid
having
lots and lots of jobs.
But if there's some other reason to have each node be a separate
job
(eg. some more important than others, etc), then yes, forget the
floating point thing and submit them as separate jobs.
Note too, with the floating point frame trick, you can include
the node names in the 'NOTES' field of the frames report.
When the submit script builds the 'frames' command, it could do
something like this:
[..]
frames 0001.1:Node_A
frames 0001.2:Node_B
:
frames 0005.4:Node_D
frames 0005.5:Node_E
frameflags keepnotes
[..]
(The 'frameflags keepnotes' makes sure the note names don't get
cleared
when the renders start rendering.)
With the above, your "frames" report ends up looking something
like this:
STAT FRAME TRY HOSTNAME PID JOBID
START ELAPSED NOTES
Done 0001.1 1 ta 7254 ta.197
01/06,10:01:24 00:00:02 Node_A
Done 0001.2 1 ta 7257 ta.197
01/06,10:01:28 00:00:02 Node_B
Que 0001.3 0 - 0 ta.197
00/00,00:00:00 00:00:00 Node_C
An example of this overloading of floating point frames is
used
in the 'tile' versions of the submit scripts, eg.
submit-maya-tile,
etc.
Note that you can add frame padding to the number after the
decimal,
and this will be preserved in the frames report, so you can have
as many
digits as you need for your write node count. So if you know you
need 2
digits, pad with 2 digits, eg:
frames 0001.01
frames 0001.02
:
frames 0001.59
frames 0001.60
Whatever padding you use to the right of the decimal will be
preserved.
--
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)
|
|