If you’re running Maya 2013 and you don’t see the Arnold shaders in the Assign New Materials window, then you need to install the latest Maya 2013 service pack. After that, you’ll be able to right-click an object and then assign an Arnold shader.

If you’re running Maya 2013 and you don’t see the Arnold shaders in the Assign New Materials window, then you need to install the latest Maya 2013 service pack. After that, you’ll be able to right-click an object and then assign an Arnold shader.
You can add attributes to shape nodes in Maya, and MTOA will export those extra attributes as user data in Arnold shape nodes. For example, you use this mechanism to add user data to a procedural node.
Add some extra attributes to a shape node, using the naming convention mtoa_constant_parameter-name. That is, the attribute name must always start with “mtoa_constant_”.
Export to ASS. In the .ass file, your extra attributes will be declared as user parameters:
procedural { name ArnoldStandInShape dso "C:/Users/SOLIDANGLE/Dev/MyProcedural.dll" min -9.63329697 0 0.861843109 max -6.73797035 3.62841082 9.87797546 matrix 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 declare MyVector constant VECTOR MyVector 0 0 0 declare MyFloat constant FLOAT MyFloat 0 declare MyInteger constant INT MyInteger 0 declare MyBoolean constant BOOL MyBoolean off declare MyString constant STRING MyString "" }
If you need to change the same Arnold attributes on many nodes, use the Attribute Spreadsheet. For example, suppose you wanted to turn off the Opaque attribute on a number of objects in your scene. Here’s how to do it:
In this case, a user installed the latest MtoA, but when he went to load mtoa.mll in the Plug-in Manager, he got this error:
--------------------------- Settings/Preferences: maya.exe - Entry Point Not Found --------------------------- The procedure entry point ?IsRenderablePath@CArnoldSession@@SA_NVMDagPath@@@Z could not be located in the dynamic link library mtoa_api.dll.
From past experience, I knew that the problem was probably the Maya.env file. And sure enough, it looked something like this:
MAYA_RENDER_DESC_PATH = C:\solidangle\mtoadeploy\2013.0.22.0 PATH = %PATH%;C:\solidangle\mtoadeploy\2013.0.22.0\bin; solidangle_LICENSE=5053@SOLIDANGLE-PC MAYA_RENDER_DESC_PATH = C:\solidangle\mtoadeploy\2013.0.22.1 PATH = %PATH%;C:\solidangle\mtoadeploy\2013.0.22.1\bin;
Notice that there are two MAYA_RENDER_DESC_PATH and PATH settings. Maya reads just the top two, which are for an older version of mtoa, so when Maya loads mtoa.mll we end up with a “missing entry point” error.
How did this happen? Well, in this case, in-between installs and uninstalls of different versions MtoA, the user had updated Maya.env with his own MAYA_RENDER_DESC_PATH and PATH settings for MtoA. And then the next install of MtoA appended its own settings to the Maya.env file.
The MtoA Installer works like this:
So if your Maya.env already has MtoA settings for MAYA_RENDER_DESC_PATH and PATH settings, then when you install another MtoA, you end up with a problem (because the new settings will be at the bottom, where they are ignored).
Ok, so that’s problem solved. Just remove those extra entries from Maya.env.
NOTE: This is a Maya issue that can happen with any renderer, including mental ray.
Like many other Maya users, I started getting this error when I tried to batch render:
// Error: line 1: Socket error creating command port SOLIDANGLE-PC:7835 (10048).
I checked the port 7835 with netstat, and that gave me a PID (process ID) of 109736
C:\Program Files\Autodesk\Maya2014\bin>netstat -ano | find "7835" TCP XXX.XXX.XXX.XXX:7835 0.0.0.0:0 LISTENING 109736
But unfortunately, there didn’t seem to be any process with that PID, so I couldn’t kill it to free up the port. tasklist | find “109736″ came up empty; there was no such PID in the Task Manager or Process Explorer; and TCP View said that PID was non-existent.
I was resigned to having to reboot my machine until I saw this. Then I used Process Explorer to find the process that was referencing the “non-existent” PID, and when I killed that process, I could batch render again from Maya.
This post is about a Maya issue on Window. It’s not an MtoA or Arnold issue.
Whenever I tried to export the selection as an XGen archive, I’d get [Error 6] The handle is invalid.
[Error 6] The handle is invalid xgmArchiveExportBatchUI.py except block xgmArchiveExportBatchUI.py call subprocess.Popen mayapy "C:/Program Files/Autodesk/Maya2014/plug-ins/xgen/scripts/xgenm/xmaya/xgmArchiveExportBatch.py" 0 0 0 1.0 1.0 -destName ["'DragonArchive'"] -destDir ["'C:/Users/SOLIDANGLE/Documents/maya/projects/Support/xgen/archives/'"] -sourceFiles ["'C:/Users/SOLIDANGLE/Documents/maya/projects/Support/scenes/Dragon1.mb'"] -scriptPaths ["'C:/Program Files/Autodesk/Maya2014\\plug-ins\\xgen\\scripts'"] -loadPlugins ["'AbcExport'", "'Mayatomr'", "'xgenMR.py'"] xgmArchiveExportBatchUI logging to C:/Users/SOLIDANGLE/Documents/maya/projects/Support/xgen/archives/DragonArchive.log
Googling [Error 6] The handle is invalid subprocess.Popen led me to the problem: I was starting Maya from the command line. When I started Maya from the Start menu, then the XGen Export Selection worked.
The reason I start Maya from the command line is because that’s the only way I can get the MtoA diagnostics in the Output Window. So something seems a little weird about how Maya handles STDOUT and STDERR ;)
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:
os.path.expanduser('~/pymel.log')
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)
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_direct_specular","aiCustomAOVs[1]", "ai_aov_indirect_diffuse","aiCustomAOVs[2]", "ai_aov_indirect_specular","aiCustomAOVs[3]"} ;
I don’t know how the user managed to get the scene into that state ;)
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:
Now when you render, the points are visible to refraction rays, so they show up behind the glass.
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 version: 4.2.4.1 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:
mayaBump2D { 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 } MayaFile { name file1 ... filename "shaders_offest_normalmap.jpg" ...
Notice that file1 (the MayaFile node) is linked to mayaBump2D.normal_map.
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:
C:\Users\StephenBlair\Documents\maya\2016\modules
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:
If you want MtoA to available to all users, then you could copy mtoa.mod to one of the common locations.
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:
C:\solidangle\mtoadeploy\2016-1.2.7.3
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-1.2.7.3 rem mklink /D C:\solidangle\mtoadeploy\2016 C:\solidangle\mtoadeploy\2016-1.2.2.0 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
I’ve seen several variations of this question recently. Usually there’s some confusion about “Arnold standalone” and what’s actually required on a render node.
If you rendering scene files from Maya, or 3ds Max, or some other 3d application, then you do not need Arnold standalone.
You need the 3d application (Maya, 3ds Max) and the Arnold plugin for that application (MtoA, MAXtoA). Download the Arnold plugin from https://www.solidangle.com/arnold/download
For example, let’s suppose you want to render Maya scene files.
It’s the same thing for 3ds Max and MAXtoA.
If you don’t use Arnold, but someone has saved your scene files with MtoA loaded, then you’ll get some errors and warnings when you open that scene without MtoA.
// Error: line 0: The camera 'perspShape' has no 'ai_translator' attribute. // // Error: line 0: Node "perspShape" has no attribute "ai_translator". // // Error: line 0: The camera 'topShape' has no 'ai_translator' attribute. // // Error: line 0: Node "topShape" has no attribute "ai_translator". // // Error: line 0: The camera 'frontShape' has no 'ai_translator' attribute. // // Error: line 0: Node "frontShape" has no attribute "ai_translator". // // Error: line 0: The camera 'sideShape' has no 'ai_translator' attribute. // // Error: line 0: Node "sideShape" has no attribute "ai_translator". // // Error: line 0: The mesh 'pPlaneShape1' has no 'ai_translator' attribute. // // Error: line 0: Node "pPlaneShape1" has no attribute "ai_translator". // // Error: line 0: The mesh 'pSphereShape1' has no 'ai_translator' attribute. // // Error: line 0: Node "pSphereShape1" has no attribute "ai_translator". // // Error: line 0: The mesh 'pCubeShape1' has no 'ai_translator' attribute. // // Error: line 0: Node "pCubeShape1" has no attribute "ai_translator". // // Warning: line 0: Unrecognized node type for node 'defaultArnoldRenderOptions'; preserving node information during this session. // // Warning: line 0: Unrecognized node type for node 'defaultArnoldFilter'; preserving node information during this session. // // Warning: line 0: Unrecognized node type for node 'defaultArnoldDriver'; preserving node information during this session. // // Warning: line 0: Unrecognized node type for node 'defaultArnoldDisplayDriver'; preserving node information during this session. //
Here’s how to remove all the MtoA (aka Arnold) attributes and nodes.
First, don’t load MtoA. Uninstall MtoA.
Now, just loading and saving your scene will get rid of the ai_translator attributes. All that’s left to do is get rid of the unknown nodes. There’s just four (assuming nobody created any Arnold shaders or lights or standins in the scene): the four defaultArnold nodes:
ls -typ "unknown"; // Result: defaultArnoldDisplayDriver defaultArnoldDriver defaultArnoldFilter defaultArnoldRenderOptions //
Here’s a MEL script to remove all unknown MtoA nodes from a scene:
string $mtoaNodes[] = `ls -typ "unknown"`; for ($node in $mtoaNodes){ if (`objExists $node` && `unknownNode -q -p $node` == "mtoa"){ print("Deleting mtoa node " + $node + "\n"); delete $node; } }
How can you update the paths used to load textures, standins, or volumes? Use dirmap.
You can use dirmap to update the paths for the following nodes:
For example, if I have a scene file that uses Linux paths like /server/assets/textures/noicon.tx, I can do this:
dirmap -en true; dirmap -m "/server/assets" "D:/Assets/";
After I run that, when I load a scene Maya will replace “/server/assets” with “D:/Assets” in all file paths.
You can test your directory mapping (dirmap) like this:
dirmap -cd "/server/assets/textures/noicon.tx"; // Result: D:/Assets/textures/noicon.tx //
So:
TIP For batch rendering, you can use a pre-render script to apply dirmap.
BONUS TIP: dirmap does not update a path if the path is valid. dirmap replaces paths that cannot be resolved.