Let’s pick up on the topic Let .mi export… and show how to export to .mi from 3ds Max.
Step by Step Procedure
You can simply export your scene to an .mi file in 3ds Max when using mental ray as Production renderer.
Go to “Rendering/Render Setup” or press F10.
Choose NVIDIA mental ray as Production renderer.
You find “Export to .mi File” in the “Processing” panel in the “Translator Options” rollout.
Note: All the controls (but the “Browse…” button) are initially greyed out until a filename is specified.
Press the “Browse…” button to spectify the .mi file output.
Render or press Shift+Q. Instead of actually rendering, the scene is exported to .mi file.
You can use mental ray Standalone to render the exported .mi file.
Note: When rendering with Standalone you might see errors about missing SubstanceShader.dll and PointCloudShader.dll. These errors can usually be ignored and do not prevent proper rendering. You might want to delete the corresponding link in the .mi file to prevent these errors to show up (see link directives at the top of the .mi file).
“Export on Render”
Uncheck “Export on Render” if you want to render to the viewport instead of export to .mi file.
If you choose to export “Un-compressed” (the default), the three dimensional vectors in objects are echoed in ASCII format. If you uncheck this option and choose to export compressed, vectors in objects are exported in binary format resulting in a smaller .mi file size and in exact floating point precision. See also the section “Export Binary vs. Ascii” in the post about exporting to .mi file in Maya.
“Incremental (Single File)”
If you select “Incremental (Single File)” options, animations are exported as a single .mi file that contains a definition of the first frame and descriptors of the incremental changes from frame to frame. If you uncheck “Incremental (Single File)”, each frame is exported as a separate .mi file.
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.
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.
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.
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.
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:
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:
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.
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.
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.
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.