Optimized Render Tuning Workflow
So you've finished modeling and are ready to tweak lighting and shading
effects in your scene? And that probably means that you want to get rapid
feedback on your creative decisions in the form of finished pixels?
No es asi?
Well, *TOR has several features which will help you develop a workflow
that should maximize your productivity. And, if you're maximally productive,
perhaps you'll get home in time for reruns of The Three Stooges.
Techniques for accelerating rendering
reuse or ignore computed maps
avoid common pitfalls such as eyesplits and displacement bounds
render selection only
use multiple processors on a single image
tradeoff quality for speed
render a subset, a crop window, of your image
re-render frames from it
choose crop region from it
render directly to combiner to preview
drag colors between image and appearance editor
rapidly change RenderMan Globals through the use of presets.
Armed with a few simple ideas, you should be able to accelerate your rendering
workflow quite nicely.
Early in the render tuning process, many decisions can be made on
approximations of the final image. The most important knob governing
the tradeoff between speed and quality is Shading Rate. Compare rendering times on
your scene with a Shading Rate of 1000 and 1. You'll note that with a
Shading Rate of 1000, your rendering will go much faster albeit with
many faceting and shading artifacts.
A nice, though detailed, RenderMan
Application note provides many details about how specific
RenderMan globals settings affect rendering performance. You may only
need to read this document in order to fine-tune rendering jobs which
are posing extraordinary problems pumping through your system.
If you're a real gearhead, another RenderMan
Application note describes how to get statistics out of your
renders, including highly detailed memory usage and timing
numbers. It's not for the faint of heart, and requires inserting a
RIBBox into your scene, but may prove useful for figuring why some
renders that seem to take up a lot of memory.
One of the most common causes of a slow rendering or one that seems to
use up a lot of memory is eyesplits. This is a problem where the
renderer has to do a lot of extra work due to having to split geometry
which sits astride both the camera and near clipping planes. The way
to tell if this is a problem is if errors like the following appear in
your render logs:
R56001 Primitive "" will not split at camera plane (WARNING)
Here are some ways of ameliorating the problem:
- The quickest way of dealing with this is to push out the near
clipping plane as far as possible. This can be done by editing the
Maya camera attribute (if dealing with a main render), or for computed
maps by editing the Slim shader property. Note that PRMan usually has
a very small default clipping plane, and it's best to bump this up to
something reasonable immediately (even something like 0.1 may make an
immediate difference). This may cause some geometry to be clipped
against the near clipping plane; however, keep in mind that you might
not want to have things this close to the camera anyways (would you
really film like this in real life?).
- If you have displacement on things close to the camera, make sure
that the displacement bounds are as tight as possible.
- If you have things flying through the camera plane, the near clipping
plane won't help. Again, try to avoid modelling this situation.
- If it happens that your camera is close to a ground plane, try to
avoid having the camera parallel and looking along the plane - if you can
have the camera perpendicular and looking "down" at the plane this should
avoid eyesplits problems.
- If all of these fail, you can change the eyesplits field in the Quality subpanel. This controls the level
to which the renderer will try to split geometry which is astride both
eye and camera planes. Try setting it down to 3, which will cause the
renderer to stop splitting much earlier at the possible expense of
missing some geometry.
Another cause for a slow rendering is setting inappropriate
displacement bounds (this is controlled in the settings for your
displacement shader). Displacement bounds tell the renderer how far in
advance of the bucket in which the geometry is the displacement shader
needs to be run. In practical terms: if you set the displacement
bounds too low, then you will get cracking - the renderer will leave
holes because the geometry is not rendered sufficiently far in advance
to account for displacement. Larger buckets may help this problem
somewhat, but this is not the correct way to fix it because you may
still have cracking at the corners of buckets; instead, you should be
setting the displacement bounds to be at least as large as the maximum
displacement the geometry undergoes.
But - you don't want to set it too high either! Large displacement
bounds slow down the renderer because the renderer must shade the
geometry in advance of the bucket and cache the results until that
bucket is encountered. This uses up more memory than it would if the
displacement bounds weren't set.
You can reduce the pixel count by rendering smaller images during preview.
This can be controlled either by making your Maya image smaller or through
the display tab.
Sometimes you want to render at final resolution and so you can use
crop regions to reduce the number of pixels rendered. This can be
controlled through the it image window or through the
Often you'll find yourself focused on a small number of objects while render
tuning. By choosing Selected Objects Only,
you can cause *TOR to only output the geometry of the current Maya selection.
This will dramatically improve your iteration time.
Another way to reduce the amount of geometry that the renderer must
process is to selectively establish objects to be One Sided. This
attribute is controlled in your modeling system and tells the renderer
that it can cull back facing geometry. This technique should only
be applied to objects which are opaque and closed and which have the correct
normals. Typically you can work with the object normals through a standard
modeling attribute known as orientation.
Computed maps (shadows, reflections, environments) slow down rendering
in two ways. First it takes time to actually compute the maps. During render
tuning, it's often the case that you can reuse the calculation of a map
from a previous iteration. To achieve this, make sure that your maps aren't
automatically cleaned and enable the lazy
compute: Maps mode.
The second way that computed maps slow down rendering is in their
use. Since the renderer must look up information in these maps,
rendering with computed maps enabled is slower than when they're
disabled. To temporarily disable the use and calculation of maps, just
change the Computed Maps control from
Use to Ignore.
have your network configured to support netrender, you can
accelerate your previews by rendering on multiple processors. Typically a number
between 2 and 8 is a useful range to set in the maximum processors
field - the benefits of parallelism begin to diminish as you increase
the number of processors beyond a point. You should also note that
when rendering multiple frames, it will always be faster to
devote a single processor to each frame. Thus you should
generally only use multi-processor rendering during preview renders
(i.e. for lighting tests), or for large format still frames.
To the right is a portion of an it (image tool) window. The
image tool can be selected as a display server via the Primary Display settings.
It is closely integrated with MTOR, and has features which are very
useful for quick render tuning:
- Re-Render - From the it popup menu (accessed via the
right mouse button), you can have MTOR render the current frame
without having to go back into Maya and initiate a
RenderMan->Render. This requires that a correct rendering
context can be established (this usually means it needs to be
running on the same machine as your MTOR session).
- Crop Window - You can draw a crop window using the left
mouse button. Now, when you select Re-Render MTOR will use this crop
window information and have PRMan only redraw the pixels inside the
crop window. This is useful for tweaking a shader which only appears
in a subset of your image.
- AutoRender Crop - When this is enabled, drawing a crop
window automatically tells MTOR to go ahead and rerender the area
it also supports the usage of catalogs and multiple images. In
conjunction with the Fresh Window setting (again, accessed via
the Primary Display
panel), you can render multiple images from the same view point and
compare them quickly.
Please consult the It: Image Tool documentation for more details on how
to use it.
Pixar Animation Studios
(510) 752-3000 (voice)
(510) 752-3151 (fax)
Copyright © 1996-
Pixar. All rights reserved.
RenderMan® is a registered trademark of Pixar.