The Rush render queue allows users to manage jobs. A 'job' is
usually just a range of frames that need to be rendered. To start a job
you need to run a Submit Script,
which contains: the instructions defining the job, the frame range to be
rendered, which machines are to be used for rendering, the 'priority' the
job should run at, the pathname of the
Render Script for rendering frames, etc.
All you need are these two scripts to use the render queue:
a Submit Script and a Render Script. Rush can create template scripts for
you using the 'rush -tss' (Template Submit Script)
and 'rush -trs' (Template Render Script) commands.
(Here are some examples
showing how to create them)
To render each frame, the render queue runs the Render Script,
usually a simple script that contains the commands necessary to invoke
whatever UNIX commands are necessary to invoke the renderer or compositor.
The 'current frame number' is passed to the render script via the $RUSH_FRAME
environment variable. The Render Script can invoke any command line based
programs: renderers, compositors, custom C programs, perl scripts, etc.
The Render Script is just a top level wrapper script that sets up the
proper rendering environment, runs the renderer, and returns one of the
'rush exit codes' to indicate success or failure; 0=Done ok, 1=Failed, 2=Retry.
The Render Script will be executed on all the machines configured in your
Submit Script via the same pathname, so it must be accessible via NFS.
(Or in the case of Win/NT, the "Network Neighborhood").
When the render script runs, various environment
variables are passed from the render queue, which may be useful to
intermediate or advanced shell programmers.
The Submit Script is executed
to start the job running. As the job runs, frames are started on the various networked machines as needed, eating through the frame list
until there are no more frames to render. After each frame renders,
the system records how long the frame took to run in the
Frame List Report and logs the error output
for each frame in the Frame Logs.
The render queue uses Priority Values
to allow important jobs to take precedence over lower priority jobs. When priorities
of different jobs are equal, a 'round robin' approach is used to allow jobs to vie for cpus.
Priority flags allow a job to fight off other, lower priority jobs instead
of passively waiting for idle cpus to become available ('k', the
Kill flag). A job can also have a priority such that no other jobs
can kill it ('a', the Almighty flag). Combined, these flags enable
a job to kill off other jobs without allowing other jobs to kill it. Sysadmins
will want to monitor audit logs for the use of such flags to prevent misuse.
