The Render Camera dialog allow you to select a specific camera from which the rendered image is created. While a basic Modo project begins with a single default camera, additional cameras may be added within the Item List using the Add Item button and selecting Camera.

These cameras, like any item in the mesh list, can be renamed by right-clicking and choosing Rename. By default each new camera is assigned a numeric differentiator such as Camera(2), Camera(3), and so on. Once additional cameras have been added to a project, the Render Camera dialog is used to select them. Additionally, the current camera can be animated to switch to different views during a sequence or select different cameras for individual Render Passes.

In animated scenes, the frame range specifies the sequence of frames rendered when you use the Render Animation command. First Frame specifies the first frame rendered, while Last Frame specifies the last frame rendered.

When rendering out animated sequences, the frame step value skip the specified number of frames. Essential for testing rendered sequences, rendering with a frame step of 2 (every other frame) cuts the overall render time in half. A frame step of 4 (every fourth frame) cuts the overall render time by three quarters and so on. This gives you a good idea of the final animated scene, albeit at a lower frame rate.

This function is relative to the Frame Range. If you specify frame 7 as your first frame with a step of 2, frames 7, 9, 11, 13, and so on are rendered. Swapping the Frame Range values and setting the value to a negative number causes Modo to render frames in reverse order.

This controls how many times a single frame is rendered (not to be confused with Render Passes, which are entirely different). The results of each pass are evenly blended to make up the final frame.

For example, the random numbers used to generate fur are varied for each pass, so the resulting blended fur looks softer. If motion blur is enabled, then each frame pass covers just part of the exposure. If there are four frame passes then the first pass covers the first quarter of the interval from shutter open to shutter close. The random sampling for Depth of Field effect are also varied between passes, so additional passes help to smooth out troublesome soft focus.

Increasing this value above 1 increases render times significantly, so unless you need softer fur or higher quality motion blur and depth of field, there is no added benefit to increasing this value.

These pattern options provide a means to automatically name files when saving rendered animations, as either flat or layered images. Instructions appear in the <> brackets, and those in the [ ] (square brackets) are ignored in instances that don't apply. For example:

• <LR> adds an L for Left or an R for Right when rendering stereo images.

• <output> names the file for the render output item (uses the actual name specified for the Render Output item in the Shader Tree).

• <pass> names the file for the Render Pass.

• <F> is the frame number (add an extra F for extra leading zeros).

So in practice, you could write Robot_[<LR>]_<pass>_<FFFF> and the resulting file name for the left render of the BG named Render Pass would be:

Robot_L_BG_0001.exr

Where the L for stereo output would only be assigned when rendering in stereo, since it is in brackets it would be ignored for non-stereo renders.

TIP:  To disable the output pattern there is also the additional <none> command which eliminates any of the file naming additions.

This control allows you to select how the rendered frame's image size is specified, either as pixels or as inches.

Frame Width and Height allow you to specify the size of the frame rendered when invoking the Render command. Dependent upon the resolution unit, if Pixels is selected, then you can specify the size in pixel units, or if Inches is specified, you can set the printed resolution of the rendered image in inches.

When set to Inches, the DPI setting is used to determine the number of pixels rendered. The typical widescreen video size of 720 pixels by 480 pixels is the default size.

The DPI input field allows you to directly determine the number of Dots Per Inch. This is particularly useful when defining image height and width using the Inches resolution unit, as it is used to determine the final pixel resolution of the rendered images. It is also added to files on export, determining the eventual printed size of the image.

Most computer screens use a Pixel Aspect Ratio of 1 which yields square pixels, by default. However, some target media use non-square pixels to display images, such as NTSC television (0.90). Use this setting to properly render the image for its intended destination.

NOTE:   Modo still displays the image as if they were square pixels, so rendered images may look squashed/stretched depending on this setting.

The Bucket size defines the number of pixel values calculated concurrently and is controlled by the Height and Width settings. The default value of 32 by 32 means that each bucket is 32 pixels wide and 32 pixels high.

Using larger buckets increases the amount of memory required but can result in speed improvement. However, if multiple threads are being used it is important to remember that using smaller buckets can result in a better load balanced total frame.

It is unlikely, when using multiple buckets, that they finish rendering at exactly the same instant, therefore there is usually one bucket/thread computing when the other bucket(s)/thread(s) are finished. If the buckets are very large, the amount of time the render engine is using only one thread increases, which decreases the impact of the additional processors on final render time. You might come to the conclusion that you should set the bucket size as small as possible, but this is incorrect as well. System performance may decrease with the overhead to manage the buckets, while reducing anti-aliasing quality (as bucket borders cannot be anti-aliased to their neighboring pixels outside the bucket; decreasing the size of the bucket increases the number of border buckets).

We recommend that the default bucket size (32 x 32 pixels) is typically the ideal size when rendering video resolution sized frames.

The Bucket Order determines the pattern in which the buckets are rendered. In some cases there can be a small performance benefit to certain patterns. In particular the Hilbert pattern is designed to maximize bucket edge concurrency to reduce the amount of data that must be purged and loaded, whereas Random is most likely the least efficient in that regard. The following Bucket Orders are available:

• Rows - Renders the buckets in rows from left to right, starting and the top and working down.

• Columns - Renders the buckets in columns from top to bottom, starting on the right side and working to the left.

• Spiral - Renders the buckets from the center spot outward, in a clockwise spiraling pattern.

• Hilbert - Uses a specially formulated pattern that snakes across the screen making certain that there is as much concurrency from bucket to bucket across the entire frame.

This pattern can result in slightly improved render performance on certain hardware architectures that are not as efficient with bus bandwidth as it reduces the amount of data being loaded and purged from bucket to bucket.

• Random - Renders the buckets in a random order across the screen.

When enabled, the order of buckets is reversed. For example, the Columns pattern would start at the bottom right hand side of the image and work its way bottom to top in columns towards the left of the screen.

Designed to facilitate renders of enormous resolution, this option causes each completed bucket to store its frame buffer data on disk rather than in system memory.

The frame buffer of an image contains a tremendous amount of data and can become quite large, for even video resolution images. For instance a 640 x 480 pixel image requires upwards of 5 MB to hold in the frame buffer. Doubling the image resolution quadruples the number of pixels and memory requirement for the frame buffer. When rendering images for large format media, such as printed billboards or IMAX film, the frame buffer size can become unwieldy. Activating Write Buckets to Disk drastically reduces the memory overhead.

NOTE:  This feature is not compatible with Network Rendering.

The 3D process is one of constant iteration and refinement. Rendering entire images repeatedly is a significant waste of time and a disruption to the creative workflow. To alleviate some of this pain, Modo provides the Render Region rendering functionality. You can use the Left/Right/Top/Bottom functions to specify the region manually, or use the Render Region Tool to specify an area by dragging in any 3D Viewport.

Additionally, the function can be activated through a button of the Render Display window, under the options tab. When enabled, the next time a render command is invoked (such as by pressing F9), only the area within the region specified is rendered. The function can be disabled by toggling the Render Region setting.

This button toggles the Render Region function on and off.

These percentage settings work in conjunction with each other to specify the total rendered region width and height. For example, you could easily render the left half of the image, regardless of the output resolution or aspect ratio, by setting the Right value to 50%.

You can also set a specific area by click dragging over the rendered image in the Render Preview window. When you do that, the render region toggle is automatically activated.

Other than disabling the function with the Render Region toggle, a single click anywhere on the Render Display restores the render to the full frame.