Optimized Render Tuning Workflow

Table of Contents

Introduction

Techniques for Accelerating Rendering

Tradeoff quality for speed

Avoid common pitfalls

More pixels means slower rendering

More geometry means slower rendering

Computed Maps slow things down

More processors mean faster rendering (up to a point)

Optimize RIB Generation

it support

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

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:

• 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

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.

Optimize RIB Generation

Before an image of a scene is rendered, MTOR writes out a RIB file for PRMan. The RIB is a special format for 3D information that PRMan uses to render an image. Because the process of RIB generation can take a long time in itself its good to make it as efficient as possible.

• Use "Deferred" or "Distributed" RIB Generation-  When working interactively with Maya and MTOR, these RIB Generation Settings free your current copy of Maya and MTOR from generating RIB, allowing you to continue to work with the current copy of Maya while the RIB generation occurs somewhere else. This can save a lot of time. Notice that RIB generation isn't necessarily any faster, but because it occurs somewhere else you can keep working with Maya and MTOR, without being delaying by the RIB generation calculations. These are the RIB generation modes:
  • Immediate - All RIB files are generated immediately when you select Render, via the MTOR plugin. This is usually faster than Deferred mode, however this may affect your currently running Maya session since MTOR may need to change the frame counter to properly account for dynamics.
  • Deferred - MTOR will submit an Alfred job which will in turn invoke a completely separate standalone mtor process on your machine. This separate process will use a temporarily saved copy of your Maya scene to generate the RIB. Something to keep in mind is that since this is an entirely separate process with its own copy of your scene, you will need twice the memory as you would in Immediate mode; also, unless your machine has multiple CPUs it may adversely impact the performance of your machine. However, your current Maya session will not be otherwise affected (i.e. no changes to the current frame.)
  • Distributed - RIB generation is distributed via an Alfred job to remote servers which have the pixarMTOR service key. In order for this to succed, the remote server must have a full RAT installation, and you must be able to run remote jobs via Alfred. In other words, the RemoteCmd Alfred command must be capable of running, which may require either set up of the rsh mechanism, or that Alfserver be installed on the remote server machine. If you are using this mode, you should also consider the use of superframe Job Chunk Size.
  • Distrib+Render - Like Distributed, this will cause RIB generation to occur on remote servers; however, it also forces the rendering of the created RIB to occur on the same machine which generated the RIB file. In this case, the renderer used cannot be netrender, it must be render or custom.
• Turn off the Visibility Attribute off for Unseen Objects- If there are objects in a scene that aren't appearing in a shot, try turning their Visibility attribute off. This simple solution works especially well for heavy objects with lots of animation curves. This allows you to keep the objects in the scene, without deleting them, but they will be not be included in the RIB generation process.
• Recycle RIB with RIB Archivers- For every frame in an animation the geometry is written into a RIB file. By attaching a special MTOR appearance, the RIB Archiver, to the top node of an object we can recycle the RIB and reuse it in the RIB files for subsequent frames. There are a couple situations where this can come in handy.
  •  The Giant Spaceship- In situations where you have an extremely geometrically complex rigid object (like a spaceship, city, or terrain) a RIB Archiver can be attached to cause the RIB to be generated as an "archive". The "archive" of RIB will be reused in subsequent frames as the spaceship flies through the scene. 
    • For this to work the archived object must be rigid, no deforming geometry.
    • This technique should be used in conjunction with animating the "Visibility" of the object. After the object is archived, on the first frame, it can be made invisible tp speed up RIB generation.
  • Archiving Animation Cycles- Deforming geometry can be archived. From run cycles to spinning propellers, geometry can be archived in a cycles, including motion blur.  

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.