[MtoA] Switching between multiple versions of MtoA


If, like me, you need to switch between different versions of MtoA, here’s a recipe for setting that up.

First, you have to install multiple versions. As you probably already know, the MtoA installer always wants to uninstall first. I take care of that by zapping the Uninstall registry entry with this command:

reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall\MtoA2016" /f

Then I run the MtoA installer and install in a folder with the version name, like this:

I start Maya with a batch file that creates a symbolic link named “C:\solidangle\mtoadeploy\2016” that links to the version of MtoA I want to use:

rmdir C:\solidangle\mtoadeploy\2016
mklink /D C:\solidangle\mtoadeploy\2016 C:\solidangle\mtoadeploy\2016-
rem mklink /D C:\solidangle\mtoadeploy\2016 C:\solidangle\mtoadeploy\2016-

set RLM_DEBUG=arnold
start "" "C:\Program Files\Autodesk\Maya2016\bin\maya.exe" %* -log %TEMP%\maya.log

My batch file also adds the location of my custom mtoa.mod to MAYA_MODULE_PATH. My custom mtoa.mod points to “C:\solidangle\mtoadeploy\2016”, and handles all versions of Maya:

+ MAYAVERSION:2016 mtoa any C:\solidangle\mtoadeploy\2016
PATH +:= bin
+ MAYAVERSION:2015 mtoa any C:\solidangle\mtoadeploy\2015
PATH +:= bin
+ MAYAVERSION:2014 mtoa any C:\solidangle\mtoadeploy\2014
PATH +:= bin
+ MAYAVERSION:2013 mtoa any C:\solidangle\mtoadeploy\2013
PATH +:= bin


[MtoA] mtoa missing from Plug-in Manager

If mtoa.mll is not listed in the Plug-in Manager, that means that Maya did not find the MtoA module file (mtoa.mod). And if you try to manually load mtoa.mll, you’ll get errors like this:

// Error: file: C:/Program Files/Autodesk/Maya2016/scripts/others/pluginWin.mel line 781: Unable to dynamically load : C:/solidangle/mtoadeploy/2016/plug-ins/mtoa.mll
The specified module could not be found. // 
// Error: file: C:/Program Files/Autodesk/Maya2016/scripts/others/pluginWin.mel line 781: The specified module could not be found. (mtoa) //

To load MtoA, you need to make sure that Maya finds the MtoA module file.

By default, the MtoA installer puts the mtoa.mod file in the user’s modules folder. For example:


If you installed MtoA using one user account, and try to run Maya with a different user account, Maya will not find the module file.

The module file has to be in the MAYA_MODULE_PATH. For example, for the user account “StephenBlair”, here are the default places where Maya looks for modules:

  • C:/Program Files/Autodesk/Maya2016/modules
  • C:/Users/StephenBlair/Documents/maya/2016/modules
  • C:/Users/StephenBlair/Documents/maya/modules
  • C:/Program Files/Common Files/Alias Shared/Modules/maya/2016
  • C:/Program Files/Common Files/Alias Shared/Modules/maya
  • C:/Program Files/Common Files/Autodesk Shared/Modules/maya/2016

If you want MtoA to available to all users, then you could copy mtoa.mod to one of the common locations.

[MtoA] Normal mapping with mayaBump2d

mayaBump2D has an RGB parameter for normal maps, and it’s named “normal_map”:

C:\solidangle\mtoadeploy\2015\bin>kick -l ..\shaders -info mayaBump2D
node:         mayaBump2D
type:         shader
output:       RGBA
parameters:   11
filename:     ..\shaders/mtoa_shaders.dll

Type          Name                              Default
------------  --------------------------------  --------------------------------

FLOAT         bump_map                          0
FLOAT         bump_height                       1
RGB           normal_map                        0, 0, 1
BOOL          flip_r                            true
BOOL          flip_g                            true
BOOL          swap_tangents                     false
BOOL          use_derivatives                   true
BOOL          gamma_correct                     true
ENUM          use_as                            bump
RGBA          shader                            0, 0, 0, 1
STRING        name

In Maya, you don’t connect your normal map directly to mayaBump2D.normal_map. Instead, just connect the normal map alpha to the Bump Value
and then change bump2d > 2d Bump Attributes > Use As to Object Space Normals or Tangent Space Normals.
The Use As parameter controls how MtoA translates the shaders to Arnold. For example, if Use As is Object Space Normals, you get this:

 name bump2d1
 bump_map file1.a
 bump_height 1
 normal_map file1
 flip_r on
 flip_g on
 swap_tangents off
 use_derivatives on
 gamma_correct on
 use_as "object_normal"
 shader aiStandard1

 name file1
 filename "shaders_offest_normalmap.jpg"

Notice that file1 (the MayaFile node) is linked to mayaBump2D.normal_map.

The case of the disappearing particles

In this case, nParticles (render type = point) weren’t visible behind a refractive plane:

For the points render type, you get an Arnold points shape (with mode “disk”), so I exported an ASS file to see the parameter settings on the points node. I noticed the visibility 243 right away (the default visibility is 255, which is visible to all rays). And sure enough, in the Render Stats for the particle shape, some rays were turned off (and the check boxes were disabled too).

I used the User Options to force the visibility to 255
and the particles behind the refractive surface appeared:

This is a Maya thing. For most particle render types, the particles are not visible in reflections or refractions. It says so in the docs:

You can turn on reflections, refractions, and shadows when you software render Clouds, Tubes, and Blobby Surfaces

I’m not sure where the default values are set, but I did find the AEtemplate code that disables the render stats for all particle render types except the “s/w” type:

// C:\Program Files\Autodesk\Maya2015\scripts\AETemplates\AEparticleLayout.mel
		if( $value == 7 || $value == 8 || $value == 9 ) {
			// software particle type
			editorTemplate -dimControl $nodeName "visibleInReflections" false;
			editorTemplate -dimControl $nodeName "visibleInRefractions" false;
			editorTemplate -dimControl $nodeName "castsShadows"    		false;
			editorTemplate -dimControl $nodeName "receiveShadows" 		false;
			editorTemplate -dimControl $nodeName "primaryVisibility" 	false;
		} else {
			// hardware particle type
			editorTemplate -dimControl $nodeName "visibleInReflections" true;
			editorTemplate -dimControl $nodeName "visibleInRefractions" true;
			editorTemplate -dimControl $nodeName "castsShadows"			true;
			editorTemplate -dimControl $nodeName "receiveShadows" 		true;
			editorTemplate -dimControl $nodeName "primaryVisibility" 	true;

So, since that AE template code just enables and disables UI controls, but doesn’t change the actual values, another way to enable Visible in Refractions (or Visible in Reflections) is to do this:

  1. Change the Particle Render Type to one of the “s/w” types, like Blobby Surface.
  2. Now the Visible in Refractions check box is enabled.
  3. Select the check box.
  4. Go back and change the Particle Render Type to points.

Now when you render, the points are visible to refraction rays, so they show up behind the glass.

The case of the “cannot remove alias” RuntimeError

In this case, mayabatch reported some runtime errors when loading a certain scene:

# Traceback (most recent call last):
#   File "C:\solidangle\mtoadeploy\2015\scripts\mtoa\callbacks.py", line 415, in deferredCallback
#     func(*args, **kwargs)
#   File "C:\solidangle\mtoadeploy\2015\scripts\mtoa\aovs.py", line 471, in createAliases
#     pm.aliasAttr(sg + '.ai_aov_' + name, remove=True)
#   File "C:\Program Files\Autodesk\maya2015\Python\lib\site-packages\pymel\internal\pmcmds.py", line 134, in wrappedCmd
#     res = new_cmd(*new_args, **new_kwargs)
# # RuntimeError: 'aiStandardSG.ai_aov_direct_specular' is not a unique name.  Cannot remove alias.

Now, even though I have the advantage of access to the MtoA source code, the problem remained: how do I fix the scene and stop these errors? To find a solution (and understand the problem) I had to resort to examining the Maya ASCII version of the scene.

The “fix” was to clear the AOV names on the shadingEngine node:

setAttr "aiStandardSG.aovs[0].aov_name" -type "string" ""; 
setAttr "aiStandardSG.aovs[1].aov_name" -type "string" ""; 
setAttr "aiStandardSG.aovs[2].aov_name" -type "string" ""; 

The problem is that the shadingEngine node has some named custom AOVs, but no corresponding “attribute alias” list. So the AOV name couldn’t be found in the alias list, which in the error message came out as “not a unique name”.

In the Maya ASCII version of the problem scene, I saw this:

createNode shadingEngine -n "aiStandardSG"; 
	addAttr -ci true -h true -sn "aal" -ln "attributeAliasList" -dt "attributeAlias"; 
	setAttr -s 4 ".aovs"; 
	setAttr ".aovs[0].aov_name" -type "string" "direct_diffuse";
	setAttr ".aovs[1].aov_name" -type "string" "direct_specular";
	setAttr ".aovs[2].aov_name" -type "string" "indirect_diffuse";
	setAttr ".aovs[3].aov_name" -type "string" "indirect_specular";

instead of this:

createNode shadingEngine -n "aiStandard1SG";
	addAttr -ci true -h true -sn "aal" -ln "attributeAliasList" -dt "attributeAlias";
	setAttr ".ihi" 0;
	setAttr ".ro" yes;
	setAttr -s 4 ".aovs";
	setAttr ".aovs[0].aov_name" -type "string" "direct_diffuse";
	setAttr ".aovs[1].aov_name" -type "string" "direct_specular";
	setAttr ".aovs[2].aov_name" -type "string" "indirect_diffuse";
	setAttr ".aovs[3].aov_name" -type "string" "indirect_specular";
	setAttr ".aal" -type "attributeAlias" {"ai_aov_direct_diffuse","aiCustomAOVs[0]",
			"ai_aov_indirect_specular","aiCustomAOVs[3]"} ;

I don’t know how the user managed to get the scene into that state 😉

The case of the missing PyMel debug log file

In several recent cases, I had to figure out why MtoA wouldn’t load on a render farm. The root cause turned out to be the PyMel debug log: ~/pymel.log

If PyMel cannot find or open ~/pymel.log, that stops PyMel and anything that uses PyMel (like MtoA).

On a render farm, this can happen if the render manager user account doesn’t have a home folder, ~/pymel.log doesn’t expand to a valid location, or if user doesn’t have read-write permissions on pymel.log.

For example, here’s the Process Monitor log when ~ cannot be resolved:
And here’s the log when the user doesn’t have read-write permissions:
The location of pymel.log is specified by the pymel.conf configuration file, like this:


When there’s a problem with the PyMel debug log, it can be hard to tell from the MtoA errors. You may see API errors like this (but the line numbers all point to unrelated bits of source code). However, if you see these line numbers with the MtoA 1.x, it’s probably a pymel.log problem.

API error detected in plugins\mtoa\Main.cpp at line 794
: (kFailure): Unexpected Internal Failure
00:00:00   514MB ERROR   | Failed to register renderer 'arnold'

API error detected in plugins\mtoa\Main.cpp at line 716
: (kFailure): Unexpected Internal Failure
00:00:00   514MB ERROR   | Failed to register Arnold swatch renderer

API error detected in plugins\mtoa\Main.cpp at line 716
: (kFailure): Unexpected Internal Failure
00:00:00   515MB ERROR   | Failed to register Arnold swatch renderer

You might also see errors like this:

API error detected in plugins/mtoa/Main.cpp at line 794
: (kFailure): Unexpected Internal Failure
Error: line 1: IOError: file /Applications/Autodesk/maya2015/Maya.app/Contents/Frameworks/Python.framework/Versions/Current/lib/python2.7/logging/__init__.py line 916: 13
Error: line 1: Failed to register renderer 'arnold'
Error: line 1: initializePlugin function failed (mtoa)