For those who use mental ray Standalone to render on a remote computer or in a render farm, the creation of a scene file in the proprietary .mi format is a necessary step. Most content creation tools are able to “echo” the full scene into a .mi representation on disk using mental ray’s built-in capability. But mental ray for Maya implements a much more flexible approach with extra functionality to ease render pipeline integration. In this post we would like to take a closer look at some of these features.

Export Options

The mental ray export options can be opened in Maya’s “Export All” or Export Selected” windows by sliding the separator handle to the left.

Or, click the little options box next to “Export All” or “Export Selected” menu items.

Last but not least, the file export can be triggered and controlled via scripting, like in the Script Editor. We show an example towards the end of this post.

Export Binary vs. Ascii

Similar to Maya’s ascii (.ma) vs. binary (.mb) scene formats, the .mi file can also come in two flavors: ascii or binary. The binary variant is the preferred choice when the precision of the scene data should be retained. The reason is, floating-point numbers are written in a binary form with no loss of bits and precision. Maya’s mental ray export enables binary by default.

That’s perfectly fine if you just like to feed that .mi file to Standalone for final rendering, and not touch it. In a production studio environment this is rarely the case, though. Typically, all the assets (textures, materials, geometry, …) are collected from different sources or departments, and may undergo steps of post-processing and editing before passing to the renderer. The ascii version of the .mi export is often better suited in such situations since it allows simple text editing and easier scripting. On the other hand, it may result in larger file sizes, and can lead to precision problems due to lossy ascii-binary conversions. There are ways to solve that with mental ray for Maya. Let’s take a closer look in the next sections.

Export Precision

The mental ray for Maya export engine can be tuned to use a more exact ascii conversion of extreme values that reside close to the edge of the floating-point precision range. Especially single-precision floating-point data are prone to this problem. Guess what, this is (still) most widely used to represent 3D scene geometry and transformation operations. The standard ascii conversion, which is using a maximum of 6 significant digits for single-precision values (15 digits for double-precision), can be increased up to 9 (or 18, respectively), by creating the following dynamic attributes in your scene prior to export.

addAttr -at short -ln "exportFloatPrecision" -min 6 -max 9 -dv 7 mentalrayGlobals;
addAttr -at short -ln "exportDoublePrecision" -min 15 -max 18 -dv 16 mentalrayGlobals;

Large scene dimensions and hierarchies, but also repetitive use of certain Maya modeling operations, can lead to such extreme values, see hints in the older Autodesk Knowledge Base Article.

Export File Path

A typical .mi scene contains various references to external files, like textures, finalgather maps, or output images. When rendering on a remote machine or in the render farm, the directory path to these files may be totally different than what was used on the exporting machine. Therefore, it is often desirable to not write an absolute file path into the .mi file, but just the relative one rooted at the project directory, or no path at all, and then use mental ray Standalone’s search path configuration on the remote computer to point to the right folders, or shared network drives. For example, using the “-T <path>” command line option, or the _MI_REG_TEXTURE registry value.

The mental ray for Maya export options provide selective control for each type of file.

Export Filter

This section of the export options allows to create .mi files that only contain elements of a certain scene type, like all “textures”, or all “materials”. It translates the full scene as usual but actually writes only the pieces selected in the “filter”. This way it is possible to split up a large scene into more manageable .mi parts that fit together perfectly. Here is an example. It will export three .mi files:

// Textures, Scene Data (zipped), Camera + Options + Render
Mayatomr -mi -file "textures.mi" -exportFilter 8388599 -xp "abs";
Mayatomr -mi -file "scene.mi" -exportFilter 1704591 -compression 1;
Mayatomr -mi -file "render.mi" -exportFilter 7699832;

The “textures.mi” file contains just the textures references, all with absolute file path. The “scene.mi” file carries most of the scene data, geometry, lights and materials, and gets compressed to save disk space. Finally, the last one “render.mi” stores the render options, render cameras, and the final render command. Now, the first two .mi files can be included into the last one “render.mi” to create a renderable “master” .mi file, see this .mi snippet:

    ...
$include "mayabase.mi"

$include "textures.mi"
$include "scene.mi.gz"

options "miDefaultOptions"
    ...

The resulting .mi file can be given to mental ray Standalone for final rendering. Arrgh, I got a new version of one of the textures last minute! Well, no problem! Just update the “textures.mi” file, no need to touch any of the heavy data. And re-render. Voila!

While this works great in general, it does not help the renderer to load certain scene parts on demand only, like when it is actually “seen” during rendering. That’s where mental ray “assemblies” come into play.

Export Assembly

This export option helps to create a valid mental ray “assembly” from a Maya scene. It writes a normal .mi file with a few special properties. A mental ray assembly is used to store a larger part of the scene that belongs together spatially, like a character or a whole building. Normally, it comprises the geometry details of the sub-scene and related local properties like materials.

Model courtesy Lee Anderson.

Such a .mi file can be referenced from a “master” scene “stand-in” bounding box object, which defines the ultimate location and scale in the global space.

In contrast to Maya file references, such an assembly is not loaded or shown in Maya immediately, thus not filling up memory and impacting your modeling operations. Instead, mental ray will load these parts only on demand during rendering, and even unload the piece in case room for other assemblies is needed. This mechanism enables the renderer to handle massive amounts of scene elements more efficiently, and keep memory consumption under control. The resulting rendering is no different to a regular render.

Model courtesy Lee Anderson.

If you like to build a scene that contains huge amounts of similar looking objects that can share the actual assembly geometry, we suggest to use instances of the same assembly rather than copies (!) (which is the default “duplicate” operation in Maya). The placement and scale of the stand-in “proxy” element referencing the assembly determines the final location and size in the final rendering.

This technique of using mental ray assemblies is also available to shader writers and integrators through the programming API. In fact, it is utilized in the mental ray implementation of crowd simulation engines like Massive for Maya, or Maya’s native procedural generator XGen, to handle incredible amount of elements.

We hope these tips will help you in your daily work.

BTW, there are more possibilities to tweak .mi file export even further (“text boxes”). But they are rarely used, and would justify another blog post in case there is interest. Just let us know.

Happy rendering!