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
• 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
• UI features
• re-render frames from it
• choose crop region from it
• render directly to combiner to preview composites
• drag colors between image and appearance editor
• rapidly change RenderMan Globals through the use of presets.

Techniques for Accelerating Rendering

You can tradeoff quality for speed

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)

• 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.

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

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

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)

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:

• 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 just selected.

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.