Optimized Render Tuning Workflow


Introduction

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

Armed with a few simple ideas, you should be able to accelerate your rendering workflow quite nicely.

You can tradeoff quality for speed

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.

Avoid common pitfalls

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:

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.

More pixels means slower rendering

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 acceleration tab.

More geometry means slower rendering

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 slow things down

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.

More processors mean faster rendering (up to a point)

If you 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.

it support

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:

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.