External Rendering 21

Introduction

External Rendering is where the real power of the Renderman platform is exposed. Using the LocalQueue render manager (which is included with the Renderman install), or Pixar’s Tractor farm manager, multiple job files can be queued up and run over a length of time. Renders can be stopped, reordered, and check pointed. You will also have access to crossframe denoising (which improves the results on animations). However, all this versatility also means denser controls.

Options

• Enable External Rendering: This is a simple on/off checkbox. Disabling it removes the external render options from the ui.
• Render To: This controls what output driver will be used for the rendered image. Options are EXR, TIFF and the IT Viewer. Please note that this setting only covers the combined RGBA ‘beauty’ pass. AOV/LPE passes are always exported as EXR’s.
• Render Animation: This allows you to render out an animation. Use the Start and End boxes to set the range. NOTE: These two boxes basically duplicate the start and end frame options from the main dimensions render panel.
• Action: This determines whether the exported files are immediately sent to the selected queue manager for rendering or are merely generated and stored in the output directory. This would allow you to render at a later time if necessary.
• Spool to: This determines what queue manager is used to render. LocalQueue is a render manager that controls rendering on the host computer only. Tractor is a Pixar program that is designed to control entire render farms.
  
  

Spooling Options

• Custom Render Command: This is a text box where you can enter any custom rendering commands you may want to use. These commands will be injected into the string that is used to start the renderer.
• Custom Spool Name: This is where you can enter a custom name for the .alf spool file that is ingested into the queue manager to control rendering. Even if you decide not to use this feature you may still end up with multiple .alf files as each one is written with the system time included in the title.
• Denoise Post-Process: As with the Internal Renderer, this checkbox configures the render process to use the denoiser after each frame has rendered. Please note that in the case of animations the denoiser is run after each frame, not after all frames have rendered.
• Crossframe Denoise: This enables a more advanced denoise process that takes into account the information in the frames around the frame being denoised. This makes the denoiser more effective on moving objects (especially ones with motion blur). Obviously this only works when you’re rendering an animation.
• Process denoiseable AOV’s: This command activates an additional denoising function that will denoise any LPE based AOV’s, in addition to the main beauty pass. This allows you to have, say, a denoised indirect diffuse AOV.
• Use GPU for denoising: This tells the denoiser to attempt to use the system’s GPU (if it exists) for denoising. This speeds up the process enormously. Unfortunately, not all denoiser functions are supported by the GPU. For instance, AOV’s cannot be denoised on the GPU.
• Custom Denoise Command: This is where you would enter any custom commands that you would like injected into the string used to launch the denoiser. This is where you would specify any custom filters or overrides you want to use.
• Enable Recovery: This command will cause Renderman to look for an existing output image for the project that was partially completed and resume rendering. It is intended to be used with the checkpoint system.
• Enable Checkpointing: This enables the checkpoint system. It tells Renderman to periodically write out an image file as the render is progressing. This would allow a user to preview early (and noisy) images without stopping the render.
• Checkpoint Method: This determines how Renderman times the writing of checkpoints. It can be either seconds, minutes, hours or even days. The final option is Increments. Basically this is the same as pixel samples.
• Interval: How often to write a checkpoint (via whatever method is chosen).
• Limit: This tells Renderman when to stop the render process. 0 is the same as disabled.
  
  

Notes

The Checkpoint/Recovery system is very powerful, but easily misunderstood. The workflow design behind it was to allow a way for a user to periodically write out ‘progress images’ as a render was active. This would let them preview a very rough image that would, hopefully, reveal any anomalies that might need to be fixed. If they were noticed, the render could be stopped.

Another possible workflow uses the recovery system. In this case a render was told to stop after a certain length of time or sample count. The checkpoint output would then be reviewed. If it was deemed acceptable, the render would be restarted with the recovery command active. This would save time as Renderman would pick up from where the previous render left off.

Of course this type of process would only work if the renders were stopped with the Limit command before the render finished normally (via pixel variance or max pixel samples). If a render finishes through the normal method, recovery will not work as there’s nothing to resume.