> Is there a way to have the rush submit scripts run different
> versions of Nuke?
I would suggest instead making separate copies of the
submit-nuke script (eg. submit-nuke-63v2, submit-nuke-62v1, etc),
and modify the env variable settings at the top of each
to run that particular version of nuke.
This way the user can control which version of nuke is used
by running the appropriate submit script.
> We use different versions of Nuke for different productions,
> but all running on the farm concurrently. Is there a way to
> have it run the version of Nuke the user is using?
If you've hot wired nuke to have a 'Rush' pulldown menu
in it for submitting jobs, eg:
http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1973+1971+1972+1973+1974+1991+1992+1993
..then you can include logic in that code to determine
the current nuke version, and to then invoke the correct
submit-nuke-xxx script (described above).
> I was looking at the submit-nuke example program, and am curious
> how Rush identifies the job being submitted is a 'Maya' job,
> and not a Nuke job, or some other renderer. Does it check
> the extensions for .ma and .nk to determine this?
The submit-maya script submits itself to run on the farm,
so it's constructed to run maya.
'Rush' itself (the C++ code) does not know about any of
the renderers; it just runs commands and manages the queue.
The submit scripts do all the work of running the different
renderers. These scripts submit themselves (ie. use recursion)
to do the work, and therefore are self contained to handle
all the logic for both submitting and rendering jobs.
So no, it does not look at the extension, but rather,
it depends on which submit script the user invoked
that determines what type of job is being rendered,
and what renderer to use.
Here's some info on how the mechanics of these submit
scripts work.
The submit scripts for maya (both perl and python) work
the same way, and have several sections (functions) that
do different types of work:
def MAIN_Input(): -- this brings up the submit form
def MAIN_Submit(): -- this handles when the user hits 'Submit' in the form
def MAIN_Render(): -- this handles rendering frames on all the machines
When you run the submit script to bring up the interface,
it runs MAIN_Input(). This constructs a form, and sets up
the 'Submit' button to run itself with "-submit" as a command
line option.
When the user hits 'Submit', it invokes the script again
with the -submit flag which invokes the MAIN_Submit() code.
This parses the form and tells rush to submit the job,
using itself as the command to run on all the machines,
but passing a "-render" flag (instead of -submit).
Whenever a processor becomes available on the remotes, rush
invokes the script with the -render flag which runs the
MAIN_Render() code, which in the case of submit-maya
constructs a maya command to render the scene, and uses the
RUSH_FRAME environment variable (passed from rush) to determine
which frame(s) to render.
The script has a few other routines, like MAIN_ImgCommand()
which is invoked whenever someone middle-clicks on a frame
in irush, which determines how to bring up an image viewer
to show the rendered image. There's also MAIN_Defaults()
which is invoked when the user hits the 'Defaults' button
in the submit form to clear out the form.
Rush itself knows nothing about the submit scripts. The
scripts use rush the way a csh script might use rsh(1)
to run itself on some other machine. 'Rush' is just a
glorified rsh(1) with priorities and the concept of
frames, error logging, and some other goodies tied in.
This is why you can write your own submit scripts that
are very simple and use other scripting languages. Rush
(the core utility) has no ties to any specific scripting
language; you can use csh, python, ruby, etc. For examples
of simple submit scripts in other scripting languages, see:
http://www.seriss.com/rush-current/rush/rush-submit.html
|