Frame Buffers

mental ray stores finally rendered pixel data in frame buffers. There are up to five main frame buffers pre-defined in mental ray: for RGBA color, depth, normal vectors, motion vectors, and labels. The depth, normal vector, motion vector, and label frame buffers store the respective values of the frontmost object at each sample of the image. If multiple samples are taken for a pixel, the frame buffer value for that pixel may be either any one sample value, or a blend of all samples. The number and type of frame buffers to be rendered is controlled by framebuffer3.6 statements. Any number of additional user frame buffers of any data type but identical resolution to the main frame buffers may be defined. These buffers will not be filled by mental ray; their content is controlled by custom shaders only, like output shaders. However, mental ray will take care of writing the buffer content to image files.

3.6 The framebuffer statement allows to create 'named' frame buffers in mental ray, together with data type and other properties for this specific buffer. The number of frame buffers is not limited by mental ray but only dependent on available system resources. Storing a frame buffer to an output file can be activated per buffer. It is possible to store several frame buffers in a single file with multiple channels, for capable formats like OpenEXR. mental ray will take care of performing all required operations like data conversions and compression. For backwards compatibility, frame buffer creation may also be controlled with output statements.

The primary purpose of output statements is to specify output shaders which operate on the frame buffers. For backwards compatibility, deprecated output statements can also specify files to write.

Frame Buffer Files

mental ray is able to temporarily store frame buffers in frame buffer files on disk instead of keeping them in memory during rendering, given that sufficient disk space is available. This allows to use very large frame buffers, or very large numbers of frame buffers, without being limited by available physical memory. This feature can be controlled on the mental ray command line. By default, this disk cache mechanism is using memory mapping techniques for performance reasons, which requires that the frame buffers fully fit into the virtual memory address space of the process.

3.6 The frame buffer cache, on the other hand, stores only fragments of frame buffers in the disk files on demand. This feature may save significant amount of memory when rendering very high resolution images, and is especially useful on 32bit systems with limited memory resources. If enabled, only a small fraction of each frame buffer is present in memory, like the currently rendered tile, and tiles recently accessed in mental ray by the display callbacks, output shaders, or when writing final images to files. This technique is typically superior to memory mapped frame buffers which need to be stored and restored as a whole, hence more appropriate when rendering many but smaller frame buffers.

Note: Memory mapping large files can occupy a significant portion of the application's virtual address space. The address space for a single process is limited on 32-bit architectures to 4 gigabytes or less, dependent on reserved space for system frameworks and libraries. Trying to map a very large file or many files might fail since there is not enough room left for the process to address it.

Frame buffer files are stored in the directory specified with the -fb_dircommand line option; or in the directory specified in the TMPDIR or TEMP environment variables.

Frame buffer files are removed from disk when rendering has finished.