Render Spooling - Job Setup

Display ... Camera ... Reyes ... Rays ... Acceleration ... Spooling

Frames... Alfred... Job Setup... Custom

The Job Setup portion of the RenderMan Globals Spool panel enables you to tune the performance of your rendering job on your network. This subpanel is probably the most powerful and potentially confusing set of controls you've seen in a spell.

Job Setup Overview

Before getting into the specifics of Job Setup, it behooves us to take a look at the big picture. Rendering 3D imagery is a time consuming process requiring fast processors, lots of RAM and big disks. We need lots of expensive machines to compute a sequence of frames in a modicum of time, so the first step in building a studio is to buy enough machines to obtain the desired frame throughput. For some, a single machine is sufficient and for others, 300 machines isn't enough.

As we increase the number of machines in our studio, we also increase the amount of data (images, textures, shaders, models) that must move from artists' machines to the remote rendering servers. Depending on the style and complexity of your imagery, the Asset Distribution part of the process can become the primary bottleneck. In this scenario, you might have lots of fast processors but they spend most of their time sitting around waiting on the network to deliver the pixels or textures. NFS is the most common mechanism for distributing assets. This may not be the best solution because NFS cache sizes are small compared to rendering assets. This can result in the same texture being sent over the network multiple times to the same machine. The recent CacheFS system was designed to alleviate the problem and, used in conjunction with NFS, can be a very effective solution for network rendering.

Another hidden hot spot in the rendering pipeline is the process of model evaluation and RIB Generation. Whether animating complex characters with skeletal deformations or running complex dynamic simulations or even making images of complex models, the process of transferring the data from the modeler to the rendering can take as much or more time that the rendering itself. Intimately connected with this issue is the Asset Distribution issue because it's often the case that the RIB Generation phase involves data amplification. This is the case where a 1 MB model file can turn into hundreds of MBs of RIB files. To minimize network traffic, it's often desireable to perform RIB Generation on the same machine that will render the image.

Once your image is rendered you often want to process it, retrieve it from servers or send it to a recorder. This phase is often intimately connected with the 3d rendering phase because the renderer knows more about the image than just the rgb values at every pixel. Again, network traffic is an important consideration.

Now your frame is complete, it's time to clean up after ourselves. We've just spewed megabytes of data across the network onto remote servers; if we don't clean up after ourselves, we'll quickly fill those tiny 9MB disks on the servers. Sometimes, however, we want to re-use assets to speedup the iteration loop. So we don't alway want to clean up completely.

Add into this tasty stew the case where your system administrators are, well, downright opinionated (you know who you are). You may find these crusty individuals unwilling to add a new NFS mount points or give you logins on remote servers or set up a permanent daemon running on remote machines.

All of these issues turn the apparently simple problem of getting your frames rendered efficiently into a potentially complex one. This panel will help you solve nearly all of them (we can't help you with your sysadmins).

Now to the specifics

Job Settings - A site-configurable collection of job-wide settings for tcl and RenderMan settings. MTOR comes with several default modes, but these can be expanded simply by adding new entries to the tor.ini file. New entries will be populated automatically in the RenderMan Globals. The following is and example of the "Bake" custom spool mode. The "Bake" mode attaches several options and attributes globally, throughout the scene . . . in this case "Bake" changes culling behavior so that surfaces hidden from camera view will still be rendered, which is useful when baking data. "Bake" also sets a couple MTOR and RSL variables. (You'll notice that the "none" option does nothing.)   

SetPref RMCCustomSpoolModes {
	none {}
	bake {
		-tcl {set ::TOR::theGlobalBakeMode write}
		-riopts {
			Option "user" "string bakemode" ["write"]
		-riattrs {
			Attribute "cull" "hidden" 0 "backfacing" 0
			Attribute "dice" "rasterorient" 0

Job Chunk Size - This allows you to control how many RIB files are generated, which in turn determines the granularity of your rendering tasks as seen by Alfred.

Superframe Count - This setting controls the number of frames in each "chunk" when using superframe mode. Larger superframe counts will be more efficient since you incur the cost of scene load and dynamics runup less often. However, your Alfred job granularity will also decrease as a result, which means your CPUs may be tied up for more often.

RIB Generation - This setting controls when and how RIB generation takes place.

RIB Format - RIB files can be in one of four formats. ASCII RIB is in plain text, while binary RIB creates an unreadable (binary) file. Both ASCII and binary RIB can also be gzipped, which is a compression mechanism to reduce the size of the output file into an also unreadable form. The most compact form (binary & gzipped) is recommended unless you wish to read your RIB files; however, note that the catrib utility can be used to convert existing RIB files of any type to their ascii representation.

RIB Style - Changes the way MTOR writes out RIB files. With this setting MTOR can be configured to write out RIB effeciently, archiving as much geometry as possible, by using "Archive Object" mode. This can dramatically accelerate RIB generation times, especially for animated sequences.  

Compute Location - This setting determines whether Alfred will schedule tasks to run on your local machine or on remote processors. In order for the remote setting to work correctly, the RemoteCmd Alfred command must be capable of running, which may require either set up of the rsh mechanism, or that Alfserver be installed on the remote server machine. Furthermore, you will need a strategy for having any necessary resources such as shaders and textures available on the remote machine. This typically occurs via a networked file system such as NFS.

Note that this does not apply if you are using the netrender Renderer setting, nor does it apply if you are using Distrib+Render RIB Generation.

Renderer - This setting gives you control over the choice of renderer used.

Imager - Setting this to custom allows you specify an command which will be invoked on each image after rendering. The command you specify will be passed a frame number and the name of the image file as arguments, and can then perform some operation on the image. Typical usages include copying the final image to a disk farm or renaming the image. Make sure that you also enter the appropiate information in the Custom subpanel.

Cleanup - Enabling each option causes that type of temporary file to be removed after the frames has completed rendering. You can use this option in conjunction with the Lazy Compute Acceleration setting to, most commonly, prevent shadows from being recomputed during interactive operation.

The types of temporary files include:

Common Settings - This popup menu allows you select from common premade configurations which affect portions of the job setup subpanel.


Pixar Animation Studios
(510) 752-3000 (voice)   (510) 752-3151 (fax)
Copyright © 1996- Pixar. All rights reserved.
RenderMan® is a registered trademark of Pixar.