UI "Maxwell Render Job..."

This is the name of the job of the job so it can be easily identified in the Qube! UI

Every job in Qube is assigned a numeric priority. Priority 1 is higher than priority 100. This is similar to 1st place, 2nd place, 3rd place, etc. The default priority assigned to a job is 9999.

Instances are the amount of times you would like to spawn a session of your application

Example:

On a 12 slot(core) machine running Maya if you set

"Instances" to 4

"Reservations" to "host.processors=3"

Qube! will open 4 sessions of Maya on the worker simultaneously consuming all slots/cores

if you set

"Instances" to 1

"Reservations" to "host.processors=1+"

Qube will open 1 session of Maya on the worker consuming all slots/cores ("host.processors=1+" is used for all slots/cores)

more on Instances & Reservations

Most jobs require a frame range in which to execute on the worker's you can set this range in a few different ways :

"1-100" will just render the range between 1 and 100

"1-100x3" will render the range 1 to 100 in chunks of 3

"1,3,7,10" will only render the selected frames 1,3,7,10

When submitting a job to the farm it may be more efficient to "chunk" your job. This means that when the job is sent to the worker it tells the worker to render X consecutive frames before requesting more work.

The drop down options are below:

"Individual frames" this tells the worker to render 1 frame at a time

"Chunks with n frames" this tells the worker to render consecutively the number of frames specified in the parallel spinner

"Split into n partitions" this tells the worker to render consecutively the total frames in the range divided by the number in the parallel spinner

Examples:

range 1-100 with "individual frames" set will render 1 frame at a time

range 1-100 with "Chunks with n frames" and the spinner set to 10 will send 10 frames to each worker

range 1-100 with "Split into n partitions" and the spinner set to 4 will send 25 frames to each worker

You can set the order in which your frames are rendered. The drop down options are:

"Ascending" this will render the frames counting upwards from your start frame

"Decending" this will render the frames counting backwards from your end frame

"Binary" Explanation needed

Enabling preview frames will create 2 jobs:

A primary dependent job with a higher priority that will render the selected frames first

and a secondary job with lower priority that will render the remaining frames

This will return the selected frames faster so that you can troubleshoot your renders

Choose the frames that you wish to render first.

If left blank "Default" is selected which renders the first frame , the last frame and the middle frame in that order.

You can select the frames by adding comma separated frame numbers e.g 1,2,10,15,75

Choose the priority for the primary job.

Choose the instances/subjobs for the primary job.

placeholder

placeholder

placeholder

placeholder

browse or enter manually the location of Maxwell.exe on the workers

Setting this to co-op will create a secondary MXIMerge job that combines the finished MXI's upon completion

If Co-op rendering is selected you can choose the Sampling level for the final render

Provide a numeric value for the Sampling override

Provide a numeric value for time in minutes that the render is allowed to commense

Tick box to resume render when previous MXI files exist

Browse or enter manually the location of the scene file to be rendered. This is a required field for submission

Important: Best practise is to ensure the scene file and all of its dependant files such as textures are on network storage accessible by the workers.

Browse or manually enter the location of the output image file you wish to generate

Important: Best practise is to ensure outputs are written to network storage accessible by the workers

Browse or manually enter the location of the output MXI file you wish to generate

Important: Best practise is to ensure outputs are written to network storage accessible by the workers

Browse or manually enter the required scripts

Important: Best Practise is to ensure scripts are on network storage accessible by the workers

Browse or manually enter the required prescripts

Important: Best Practise is to ensure scripts are on network storage accessible by the workers

Browse or manually enter the required postscripts

Important: Best Practise is to ensure scripts are on network storage accessible by the workers

Browse or manually enter the location of the bitmaps file you wish to generate

Important: Best practise is to ensure bitmaps are written to network storage accessible by the workers

Browse or manually enter the location of the textures you wish to replace

Important: Best practise is to ensure textures are written to network storage accessible by the workers

Browse or manually enter the location of the current directory

Browse or manually enter the location of the required dependancies

Browse or manually enter the location of the MXI file to be resumed

Tick box to rename MXI file upon completion

Used for overriding the scenes resolution. IE: 800x600

Used for specifying a specific region or section of the frame to render or enlarge.

Used to override scenes current image depth settings.

Click choices to override the export of channels layers.

Used to override different channels that can export and their format. see tooltip for examples.

Used to override the zmin values

Used to override the zmax values

Tick box to enable

Tick box to enable

Tick box to enable

Tick box to enable

Click choices to override the color space required

Used to override the chosen camera if multiple are available

Used to override the path to the default materials

Important: Best practise is to ensure materials are on network storage accessible by the workers

Enter a number to override the burn value

Enter a number to override the gamma value

Chose the pass from the drop down box to override scene defaults

Chose the required setting from the drop down box to override scene defaults

placeholder

placeholder

placeholder

placeholder

placeholder

placeholder

placeholder

placeholder

Choose from the level of detail you would like the logs to provide

Enter a numeric value for the amount of threads to be spawned on the workers while processing this job

Choose the required CPU priority for the job on the worker

Enter a numeric value in seconds for refresh of sampling info

Enter a numeric value in minutes for automatic saving of MXI files to disk

Tick Box to frce Maxwell not to create MXI files while rendering

placeholder

placeholder

placeholder

see page Job Tags

Click browse to choose from a list of workers that you want to run the job on

Click browse to choose from a list of groups that you want to run the job on

Click browse to choose from a list of workers that you do NOT want to run the job on  

Click browse to choose from a list of groups that you NOT want to run the job on

Click browse to choose from a list of Priority Clusters

Clusters are a way of distributing jobs across the farm with the ability to expand and shrink based on the submitted priority cluster Example: A job submitted to /root/ will run on all machines with /root/ assigned as a cluster.  At a standard priority A job submitted to /root/a will run on all machines with /root/a assigned as a cluster At a higher priority than /root/ meaning that the job will pre-empt a job with the priority cluster

Click browse to choose from a list of Host Order Options

Host Order is a way of telling the job how to select/order workers "+host.processors.avail" means prefer workers which have more slots available "+host.memory.avail" means prefer workers which have more memory available "+host.memory.total" means prefer workers which have more total memory "+host.processor_speed" means prefer workers with higher cpu speeds "+host.cpus" means prefer workers with higher total cpu slots

Click browse to choose from a list of Host Order Options

Requirements is a way to tell the workers that this job needs specific requirements to be met in order to run drop-down menu items: "winnt" this will fill the field with "host.os=winnt" which means only run on Windows based workers "linux" this will fill the field with "host.os=linux" which means only run on Linux based workers "osx" this will fill the field with "host.os=osx" which means only run on OSX based workers The above is not the limit of what "Requirements" can do see a list below of other alterable variants: "host.processors.avail.=4" means only run this job on workers that have 4 or more slots available "host.processors.used=0" means only run this job on workers with 0 slots in use "host.memory.avail=400" means only run this job on workers that have 400 memory available

Click browse to choose from a list of Reservation Options

Reservations is a way to tell the workers that this job will reserve the specific resources for this job Menu items: "host.processors" this will fill the field with "host.processors=X" which means reserve X slots on the worker while running this job "host.memory" this will fill the field with "host.memory=X" which means only reserve X memory on the worker while running this job The above is not the limit of what "Reservations" can do see a list below of other alterable variants: "host.license.nuke=1" when a Global Resources entry has been made you can reserve any arbitrary named item. See also Job Reservations

Click browse to choose from a list of Restrictions Options

Restrictions is a way to tell the workers that this job can only run on specific clusters Example: submit a job that will run only in /farm: "qbsub -cluster /root -restriction /root" submit a job that will prefer to run in /farm/nuke, but could run in any host in /farm or in the first level below /farm "qbsub -cluster /root/a -restriction '/root or /root/*'" submit a job that will prefer to run in /farm/nuke/workstations, but could run in any host at any level at /farm or below "qbsub -cluster /root/a/workstations -restriction '/root or /root/+' hostname"

Sends mail to the designated user based on the status of the job being complete

Sends mail to the designated user based on the status of the job being failed

Enable this tickbox to ensure after submission this job is in a blocked state

Enable this if you would like to combine you logs

Legacy method of labelling jobs see Job Tags

see How to restrict a host to only one instance of a given kind of job, but still allow other jobs

see Process group labels

Set this to retry any failed frames or instances automatically

Set this to create a delay in second between the frame/instance retries

Use this if the acceptable instance/subjob spawn time is known.

Use this if the acceptable frame time is known.

Explanation needed

You can specify key/value pairs of environment variables

This is useful when you might need different settings for your render applications based on different departments or projects

You can specify which user you would like to submit the job as

This is useful for troubleshooting a job that may fail sent from a specific user

Example:

Setting "qube\josh" would attempt to submit the job with the domain "qube" and the user "josh"

Note: "impersonate user" permissions need to be set on the user submitting this job

Used to provide OS specific environment variables for Windows

Used to provide OS specific environment variables for Linux

Used to provide OS specific environment variables for OSX

Select this option to create a secondary job that will wait for the render to complete then combine the output files into a movie

Note: For this to work correctly the "Qube (ImagesToMovie) Job..." has to be setup to use your studios transcoding application

This can be used for creating tags for your job

The created tags can be searched in the "Performance Charts" Tab

You can add entries by typing in the drop-down window or select already created accounts from the drop-down

See also "Qube Job Tags"

Add text about the job for future reference. Viewable in the Qube UI