The mental ray pipeline at Rhinofx
Article by Jesse Clemens (Article Info)
|
|
|
|
 |
 |
 |
I am the programming TD at RhinoFX, a New York CG house. TOmrUG
invited me and my co-worker Vadim Turchin to Toronto to speak about our
use of mental ray. Highend3D asked me to write up an article based on
our presentation, so Ive taken what I consider to be the most
interesting part of the talkour mental ray pipelineand gone into more
specific detail on how it works and the reasons we chose to set it up
in those ways. At RhinoFX we have built a fairly robust mental ray pipeline, using a combination of tools developed in house and Temerity Softwares Pipeline
program, that allows us to handle a variety of jobs in the most
efficient way possible. Economy, especially with a rendering pipeline,
is always a difficult calculation based on the complexity of the job,
the schedule, render times, and the time it takes an artist to wrangle
the complexities of the pipeline. A highly technical solution which
requires extensive setup time is not the best choice for a short job;
it is even worse when lighters are having to manage all the renders in
addition to their normal work. On the other hand, some jobs can shave
significant time from rendering by implementing a more complicated
rendering setup. With all that in mind, the following is the basic
list of guidelines that were always present in our minds (if not
explicit defined) when we started the project and which have guided
all the development of our tools for both mental ray and Renderman
compliant renderers since.1. The default setup must be easy enough for anyone to setup and wrangle without requiring extensive technical help.
2. It must have fairly easy solutions for situations when the default setup is unable to perform adequately.
3. It must be able to scale up for complicated jobs, where rendering efficiencies are more important than simplicity.
Temeritys Pipeline has made it much easier to implement our solutions.
Its workflow automation tools allow us to present complicated setups to
artists in simple ways. Pipeline is a node-based system, with each node
representing a version-controlled file or sequence of files.
Asset
Management screen in Pipeline, showing the versions of the file, the
date they were checked in, the user who checked it in, and the message
that it was checked-in with.
Nodes are hooked together into trees allowing you to describe
dependencies among files (an image sequence will depend on a lighting
scene, which depends on an animation scene, which depends on model
files).
A
Pipeline tree structure, starting with clean models on the far right,
progressing through shaded models to final models, and then into
animation and lighting.
In addition to just tracking dependencies, Pipeline also allows a user to
assign Actions to a nodean Action can be any task or group of tasks
that can be run from the command linewhich are used to generate the
files of the node. For example, an image sequence might make use of an action that calls the mental ray renderer, while a sequence of mi
files could call Maya with a custom MEL script to export mental ray
files. The use of Actions allows us to automate almost the entire
rendering pipeline, making much of it transparent to the lighters.
A mental ray render action in Pipeline, showing some of the render global settings.
Our default setup is a Maya-to-mental ray solution. The decision to go
this route was fairly easy to make because it presents the least
complexity to the artists: the lack of intermediate files between the
lighting scene and the rendered images eliminates any possible
confusion. In order to get the most out of this solution we generally
render multiple passes from each lighting scene. The passes break down
based on object types (background, character1, etc.), based on
different light/shader setups (diffuse, specular, occlusion) or
occasionally both. In order to make this as efficient as possible,
passes are controlled with pre-render MEL scripts connected to the
image nodes in Pipeline.
Depending on the complexity of the setups, the MEL scripts will either
create the shader setups themselves (in the case of something like an
occlusion pass where only one shader is needed) or will edit/make
shader assignments. One method is to build shaders using mental ray
color mix nodes: this allows us to render the entire thing together as
a beauty pass if we wish or to disconnect certain layers for each pass.
For more complicated setups, we will include all the needed shader
setups in each model file and create selection sets for each shader.
When the script runs, to generate a diffuse pass for example, it will
select DiffuseSet1 and apply DiffuseShader1 and so on.
 The diffusePass script is run on the beauty_sc01.ma scene as a pre-render MEl to make the correct shader assignments.
These scripts are usually built as modular components, allowing
multiple scripts to be chained together in Pipeline. This makes it easy
for an artist to create a new pass: if a specular background pass is
needed, the artist can just chain the specular script and the
background script together and connect the result into an image node.

Chaining two pass MEL scripts together.
.
Continue Article: 1 2 
|
|
 |
 |
 |
|
Related Articles and Features
Related Learning Tools
Global Related DVDs
No Results. |
Global Related Books

The Art and Science of Digital Compositing |
Global DVDs

Shake: Effective Keying Techniques |

|
|