Rhinoceros Output
The Output tab contains several groups which control how MXS files are written and exported.
File Output
Name
This is the name which will be used to generate the various filenames required to write MXS files. This includes the file name of the MXS file, the image-output file, and the MXI file. This should be specified as a name with no extension; the appropriate extensions will be inserted as necessary by the plugin. The Name should therefore also not contain characters which are illegal for use in file paths. If no name is entered here, the plugin will first try to use the name specified in Options > Default Output > scene Name, or else it will try to use the current document name.
Image Format & Output Bit-depthÂ
This determines the format of the image output path written into the exported MXS; this is the file which Maxwell Render will write the primary (RGB) render output to. Depending on the image format selected, output may be written in 8-, 16-, or 32bpp.
Folder
This is the root folder used for the plugin’s output. MXS, image, and MXI files will be written to this location. If no folder is specified here, the plugin will try to use the location specified in Options > Default Output > Working Folder, or else it will try to use the current document location. If it is not possible to determine the current document location (for example, when the document has not yet been saved), the plugin will try to write output to [documents]\Maxwell\output.
Append Camera Name
Sometimes it is useful to keep track of output files using the name of the view being rendered; enabling this option accomplishes this by appending the name of the current view to whatever is entered in the Name field. So, rendering to a file named output with a current view named perspective would result in files named output_perspective.mxs, etc.
Relative Output
Both the Name and Folder parameters accept relative folders as input. So, if values were set like this:
If added_folder and make_this_folder did not currently exist, the plugin would create the necessary intermediate folders, and the output files written would be:
- C:\output_folder\make_this_folder\added_folder\filename.mxs
- C:\output_folder\make_this_folder\added_folder\filename.mxi
- C:\output_folder\make_this_folder\added_folder\filename.png
Additionally, rather than setting Folder to an absolute path like C:\output_folder, it would also be possible to simply specify output_folder. In this case, the plugin would create a folder named output_folder at the current document location and write the output there. Furthermore, it is possible to set these values using environment variables; to do so, an environment variable must exist and point to a valid location. To use it, enclose the name of the variable in percent symbols: %MAXWELL_OUTPUT_PATH%; Â the plugin will retrieve the value of this environment variable and use it for the rendered output.
Auto File-naming
This group contains parameters which determine whether or not the plugin will automatically name output files, and how that naming will be done.
For each of these that is checked when the export is done, the plugin will scan through the output directory and determine the highest-numbered existing file; it will then increase the number by one and use that as the new output filename. So for example, if the MXS option is checked, the output Name is scene, and a file named scene_0006.mxs in found in the output directory, the MXS file written by the plugin will be named scene_0007.mxs. This is done individually for the image, MXS, and MXI outputs, unless the Synchronize option is checked; in that case, all three outputs will be numbered using the same number, which will be the highest number found in the output directory for any of the three formats.
The reason that the Synchronize option is provided is that it can be confusing to open an MXS file named scene_0007.mxs and find that it contains an image output of scene_0001.png and an MXI output of scene_0001.mxi. Such a scenario would be possible if all three auto-name options were enabled, but no rendering was done; in that case, seven MXS files would exist, but no image or MXI files would exist; using Synchronize makes sure that all three would be named using the same _0007 sequence number.
Engine
This group contains parameters which affect various aspects of the rendering engine (i.e. Maxwell Render) itself, which is a standalone application that runs in a separate process from the host application and plugin.
Parameter | Description |
---|---|
Time/SL | Time is the maximum time Maxwell will render before stopping. As it is possible to stop Maxwell at any time, it is generally best to leave this set to a higher number of minutes than will be necessary to obtain a clear image. Rendering will also stop if it reaches the specified SL (Sampling Level), or the Time value, if it is unable to reach the specified SL before the Time has been surpassed. |
Threads | This parameter specifies how many threads will be spawned by the Maxwell render process. Setting this to zero will cause Maxwell to auto-detect and render using all available CPU resources. Setting the number of threads to [CPU count – 1] represents a trade-off between rendering speed and machine responsiveness, in case the machine must be used for other purposes while rendering. |
Command line | The plugin (like all Maxwell plugins) does not directly contain any rendering functionality. Rather, it is an MXS file exporter. To render the MXS files it produces, it uses the Maxwell Render application. Maxwell Render runs from a command line, and different command-line flags are supplied by the plugin to start it rendering on an exported MXS file. In addition to the flags passed by the plugin, you can also enter any other Maxwell Render command-line flags you wish in this text box, and they will be added to the flags that the plugin gives Maxwell. |
Color Space | Determines which color space maxwell.exe will use to render the output image. |
Burn/Gamma | These parameters correspond to those of the same name as seen in the Maxwell Render user-interface. Burn is used to simulate over-exposure, while Gamma is used to compensate for monitor gamma. |
Multilight | If this is enabled, the Multilight feature will be enabled. When Multilight is enabled, each emitter will get its own controls in the Maxwell Render’s Multilight panel, allowing you to adjust the output power emitters on an individual basis, in real-time, while rendering. |
Low Priority | If this is enabled, Maxwell Render will be started on a low-priority process. This can help to keep the machine responsive, since on Maxwell is able to use nearly all available CPU power for rendering. |
Render Silent | If this is enabled, Maxwell Render will be run with no GUI. This allows it to use fewer resources. |
Export
This group contains parameters which control various aspects relating to the actual export process.
 |  |
---|---|
Instances | Enabling this option will cause the plugin to write Block Links out as Maxwell instances. This can drastically reduce both the size of the output files and the amount of memory required during export and rendering. Export speed can also be reduced greatly since the actual mesh-geometry only needs to be written once. |
Native Lights | Enabling this option will cause the plugin to translate native spot, cone, and rectangular lights into real geometry for use by Maxwell. Emitter materials will be generated based on the native parameters of the light, or an explicit Maxwell matererial may be directly assigned. In the specific case of a spot light which has an IES-based Maxwell emitter assigned, the global transformation of the native light will be used to determine the directionality of the IES representation. |
Protect MXS | Enabling this option will set a flag in the exported MXS file which will prevent the geometry it contains from being exported again from Maxwell Studio. This is provided as a way to protect intellectual property which may be contained in the file, while still allowing it to be distributed as necessary. |
Cache Meshes | The process of exporting an MXS file consists of the plugin reading the mesh data contained in the Rhino model and transferring it into an in-memory representation of an MXS file. Once this has been accomplished, the in-memory MXS data is written to disk as an MXS file, which may then be processed in Maxwell Render. Enabling this option will cause the plugin to keep the in-memory data instead of freeing it immediately after export. While this means that more memory will be used, it also means that as long as no physical changes are made to the model, then the mesh data which was previously exported does not need to be exported again. Therefore, when this option is enabled, changes to materials and camera position may be made after an MXS export, and the export repeated without the actual mesh-data being exported again. Since complex models may contain millions of points of mesh data, this data-caching can save a substantial amount of time. It has limitations, however, and these include: objects may not be added/removed/altered/moved, texture-coordinates may not be altered, and the optics group of the camera may not be changed. For the most part, these changes are detected automatically, and any cached mesh data is invalidated. These things may not be detected in every case though, so keep it in mind when using this option that it may be necessary to disable and re-enable the option, thereby manually invalidating cached data, in some rare cases. |
Active Camera Only | Normally, the plugin exports a camera for each view (including Named Views), whether it is the current camera or not. If you do not wish to export these extra Cameras, enable this option; only the currently-active camera will be exported. |
Pack and Go | When this option is activated, the plugin will scan through all files referenced in the scene (i.e. texture, ior, hdr, etc.) and copy them to the output directory during export. The paths contained in the exported mxs will point to the new copies, rather than the original files. This makes it much easier to transport an entire scene to another location. |
Light Multiplier | When the plugin exports native lights, it attempts to approximate the power values used in the native application. This is not an exact science, depending on the size of the scene. If the output is unsatisfactory, it may be adjusted on a global basis using this value. |
SimuLens
This group contains parameters which control the image-enhancing features known as Maxwell SimuLens. For more information, see the SimuLens topic.
Materials
This section is deals with materials on a global basis.
OverrideÂ
If the path to a valid MXM file is placed here, then the file will be used to override all material-assignments (with the exception of emitters). This can be useful for light-studies and similar.
Default  Â
All triangles in a Maxwell MXS file must have a material assigned. For those which do not have a material explicitly-assigned, one will be assigned automatically, and this can be controlled by specifying the path to an MXM file in this field. If no MXM path is specified here, a default gray (153,153,153) diffuse MXM will be created and given to maxwell.exe to use.
Render Channels
Options in this group control the various different image outputs which may be rendered by Maxwell Render. For more information, see Channels.
Render Layers
Though Maxwell naturally calculates all possible light interactions in a scene, it is possible to inhibit certain classes of calculation using the switches found in this section.