From: Greg Ercolano <erco@(email surpressed)>
Subject: Re: Submit Confirmation
   Date: Fri, 06 Jan 2012 13:18:33 -0500
Msg# 2187
View Complete Thread (23 articles) | All Threads
Last Next
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)


Last Next