If you have both Renderman and MtoA installed, you may see a warning that says “Arnold for Maya degrades Renderman performance.” Unless you are running a version of MtoA from 20 months ago, this performance warning is false. MtoA does not degrade Renderman performance.
This was fixed in Arnold 4.2.3.1 (fix #4393 main thread was pinned to a single core) back in January 2015.
The Arnold log is important, not just for troubleshooting and getting help from us at Solid Angle, but also for understanding what’s going on when Arnold renders your scene.
To get an Arnold log:
For batch rendering, Arnold log messages go into mayaRenderLog.
For the render -rt 1 command, you can specify the output ASS name in
the defaultArnoldRenderOptions.output_ass_filename attribute. For example:
set PRE_RENDER_MEL="setAttr -type \"string\" defaultArnoldRenderOptions.output_ass_filename \"c:/Users/StephenBlair/Documents/test\";" render -s 6 -e 8 -r arnold -rt 1 -preRender %PRE_RENDER_MEL% C:\projects\Support\scenes\_2016\XSI_deformed_logo.mb
The scene should have the Frame/Animation ext set to something like
“name.#.ext”. Otherwise, if it is “name.ext” you’ll get filenames like
“example.ass.0004.ass”
output_ass_filename can have environment variables, but you have to be
careful to use forward slashes. For example:
set PRE_RENDER_MEL="setAttr -type \"string\" defaultArnoldRenderOptions.output_ass_filename \"%OUTPUT_ASS_FILENAME%\";" set OUTPUT_ASS_FILENAME=C:/Users/StephenBlair/Documents/example render -s 6 -e 8 -r arnold -rt 1 -preRender %PRE_RENDER_MEL% C:\projects\Support\scenes\_2016\XSI_deformed_logo.mb
There’s also the arnoldExportASS command, if you want to script the export.
maya -batch -file scene.mb -command "arnoldExportAss -f "/home/blairs/Desktop/example.ass" -mask 255 -lightLinks 1 -compressed -shadowLinks 2 -cam sideShape;"
You may have noticed the Force Translate Shading Engine option in the export dialog (or in the Feature Overrides section of the Render Settings).
Force Translate Shading Engines forces MtoA to export shape nodes with a shader link, like this:
polymesh
{
...
shader "aiStandard1SG"
declare mtoa_shading_groups constant ARRAY NODE
mtoa_shading_groups "aiStandard1SG"
}
where “aiStandard1SG” is the name of a MayaShadingEngine shader node.
This allows you to keep your shapes and shaders in separate ASS files. For example, you could have one standin that loads the shapes, and a second standin that loads the shaders. As long as the shape nodes include links to the shaders, Arnold will resolve the links and render the shapes with the right shaders.
Here’s a good example of why you might use the User Options, and how it lets you set Arnold parameters that aren’t exposed by MtoA in Maya.
If you set the verbosity level to Warnings + Info, you’ll get some detailed image statistics in the Arnold log:
But what if you’ve got thousands of image files (eg udims)? You might not want all that in your log. There used to be a check box in the Arnold Render Settings that allowed you to turn off the detailed image file statistics, but we removed that a few years ago.
But the Arnold options.texture_per_file_stats parameter is still there, so you can use the User Options field to set that parameter to false. Just enter the parameter name “texture_per_file_stats” and the parameter value, like this:
PyMEL is great. But…if pymel.log can’t be accessed, any plugin that uses PyMEL will fail to load.
And MtoA uses PyMEL, so every now and again I see a case where MtoA doesn’t load, and you get something like this in the script history:
import arnold // Successfully imported python module 'arnold' import mtoa // Successfully imported python module 'mtoa' import mtoa.cmds.registerArnoldRenderer;mtoa.cmds.registerArnoldRenderer.registerArnoldRenderer() # Error: line 1: IOError: file C:\Program Files\Autodesk\Maya2016\bin\python27.zip\logging\__init__.py line 926: 13 # // Error: Failed to register renderer 'arnold' // // Error: line 1: initializePlugin function failed (mtoa) //
The important bit is this error:
# Error: line 1: IOError: file C:\Program Files\Autodesk\Maya2016\bin\python27.zip\logging\__init__.py
That error means that PyMELcannot create a log file in your user folder.
By default, the PyMEL log file is created in your Documents folder. For example, if your Windows user account name is Stephen, then this would be the log file:
C:\Users\Stephen\Documents\pymel.log
You need to check the permissions on that log file, or delete it so that PyMel can create a new log file.
Note that the pymel.log file may be a hidden file.
This blog post is for Google search to find; I’ve already blogged about the SSE4.2 requirement elsewhere.
If your processor does not support SSE4.2, the Arnold won’t run on your computer. MtoA will either fail to load, or you’ll get a crash whenever you try to render.
To check whether an older machine supports SSE4.2, here’s a few suggestions:
A note about coreinfo:
SSE4.2 * Supports Streaming SIMD Extensions 4.2
SSE4.2 - Supports Streaming SIMD Extensions 4.2
You can’t. The background object isn’t visible in refractions. Or reflections, or anything but camera rays.
Here’s an example: a refractive sphere in front of a torus, in front of the background checkerboard object. The black areas are where the background object isn’t visible to refraction rays.
The “background object” is actually a shader plugged into the Arnold background slot.
You won’t see it in Cinema 4D, but when C4DtoA translates the scene to Arnold, the background object is translated as a shader plugged into the options.background parameter (in Cinema 4D, this is the Environment > Background parameter in the Render Settings).
In an ASS file, it looks like this:
options
{
background "c4d|Background"
}
image_plane
{
name c4d|Background
color c4d|Arnold_Shader_Network|checkerboard
lenx 1
leny 1
ox 0
oy 0
}
The image_plane node is a shader, and if you were to check its code, you’d see that it handles camera rays only; for any other ray type (like refraction), the image_plane shader returns black.
shader_evaluate
{
if (!(sg->Rt & AI_RAY_CAMERA))
{
sg->out.RGBA = AI_RGBA_BLACK;
return;
}
Procedurals (aka standins) don’t expose the parameters of objects and shaders inside the procedural.
For example, you cannot override shader parameters like standard.Kd (diffuse color) or standard.emission (emission scale) by setting those parameters on a procedural node.
But what you can do is use “user data parameters”. Inside the procedural, use user data shaders to set shader parameters, but don’t define the user data parameters on the shape.
For example, if I wanted to be able to override the emission scale, then I would set up a shader like this:
A userDataFloat shader sets the Emission. The important thing is that the custom attribute emission_scale is not defined on the shape, so the default value is used instead.
By doing that, I can put an emission_scale attribute on the procedural node, and the aiUserDataFloat shader picks up that value.
In the above example, I’ve added a mtoa_constant_emission_scale attribute to the standinShape, and that allows me to set the Emission for that specific standin.
In Arnold scene source (ASS) format, I have this in my main scene file:
procedural
{
name ArnoldStandIn1Shape
dso "standin_torus_w_emission.ass"
...
declare emission_scale constant FLOAT
emission_scale 0.649999976
}
And in the ASS file loaded by the procedural, I have this:
polymesh
{
name pTorusShape1
...
shader "someshader"
}
standard
{
name someshader
...
emission aiUserDataFloat1
...
#
# NO user data declared here
#
}
userDataFloat
{
name aiUserDataFloat1
floatAttrName "emission_scale"
defaultValue 0.100000001
}
For example, can I transfer Arnold shaders from 3ds Max to Maya? Or from Houdini to Maya?
The answer is no. The Arnold plugins don’t include code for reading shader nodes from an ASS file and creating shader trees inside the host application (eg Maya, Houdini, or Cinema 4D).
You can use ASS files to take shapes and shaders from one app and render them in another app, but those shapes and shaders are never created inside the other app.
An MtoA Standin (aka an Arnold Procedural in HtoA and C4DtoA) references an ASS file, and passes that on to Arnold at render time.
The ASS file contains Arnold nodes (shapes and shaders). Those Arnold nodes are not created inside the 3D application.
Instead, the standin node is translated to an Arnold procedural node, and at render time, that procedural node is expanded, and all the Arnold shapes and shaders are created inside the Arnold scene.
// Warning: file: C:/Program Files/Autodesk/Maya2017/scripts/others/supportRenderers.mel line 64: The renderer "arnold" used by this scene, is not currently available. The "mayaSoftware" renderer will be used instead. //
By itself, this warning doesn’t mean there’s a problem with MtoA or Arnold. The warning means that the MtoA plugin isn’t loaded, so all you have to do is load MtoA:
However, if you get a “Unable to dynamically load : ../mtoa.mll The specified module could not be found.” error, then that’s a different problem.
I have another, more general, version of this post here. This one is for new Arnold users with Maya 2017.
Here’s what to do if you get errors like this:
// Error: file: C:/Program Files/Autodesk/Maya2017/scripts/startup/autoLoadPlugin.mel line 32: Unable to dynamically load : C:/solidangle/mtoadeploy/2017/plug-ins/mtoa.mll The specified module could not be found. // // Error: file: C:/Program Files/Autodesk/Maya2017/scripts/startup/autoLoadPlugin.mel line 32: The specified module could not be found.
If this is the first time you’ve tried to use the Maya to Arnold (MtoA) plugin, then check whether your processor supports SSE4.2.
If MtoA used to load, but now it doesn’t, then something happened to the MtoA installation. I’ve seen several cases where DLLs were missing from the MtoA bin folder; most importantly, Arnold itself was missing (Arnold is ai.dll on Windows, or libai.so on Linux, or libai.dylib on OSX).
If you make a backup copy of the MtoA install folder, we can investigate after you fix things by installing MtoA.
If a clean install of MtoA doesn’t work (and the computer does support SSE4.2), then “The specified module could not be found.” usually means there’s a missing dependency. Dependency Walker is a decent, if aging, tool for checking out dependencies, but for leaving no stone unturned, I prefer Process Monitor.
The MtoA plugin (mtoa.mll) depends on a handful of files only. Here’s the log of loaded DLLs for a working MtoA:
Here’s a quick walkthrough (no audio) of how to get a Process Monitor log:
MtoA uses these environment variables:
set MTOA_TEMPLATES_PATH C:\solidangle\alShaders\alShaders-win-1.0.0rc18-ai4.2.12.2\ae
set MAYA_CUSTOM_TEMPLATE_PATH C:\solidangle\alShaders\alShaders-win-1.0.0rc18-ai4.2.12.2\aexml
These are not MtoA environment variables:
With the default Diffuse = 2 sampling, you’ll get four diffuse rays for each camera ray. Those four diffuse rays are the first bounce after the camera ray “hits” a shape.
After the first bounce, Arnold sets all the sampling settings back to 1, so for each of those four diffuse rays, you get one second-bounce diffuse ray. This prevents an exponential explosion of rays as secondary rays like diffuse rays bounce around a scene.
The same thing is true for the other secondary rays such as glossy, refraction, and shadow rays.
So, in summary:
The valence of a vertex is the number of edges connected to that vertex. In Arnold, the maximum valence is 255 (that’s because of the data type we use to store the valence; we minimize the memory requirements since this is stored per-vertex).
If a mesh in the scene has a vertex with more than 255 edges, you’ll get a WARNING like this:
[polymesh] example_mesh: mesh has at least a vertex with valence higher than 255, disabling subdivision
But if the adaptive subdivision results in a vertex with too many edges, you’ll get an ERROR:
ERROR: [arnold] [subdiv] example_mesh: edge (144578,287741) in face 263433 has a vertex that exceeded the max valence limit of 255
In this case, a Windows 7 machine did support SSE4.2, but Maya 2017 still couldn’t load mtoa.mll.
I didn’t get a full Process Monitor log from the client, but I did get a Dependency Walker log, and this case, that was enough.
When you first open a Dependency Walker (dwi) file, it’s easy to focus on the wrong thing. In this case, the missing MSVCR90.DLL (Visual Studio 2008 redistributable) might catch your eye.
But you can ignore that, because if you take a closer look, you’ll see that MSVCR90.DLL is indeed found and loaded.
Likewise, you can ignore all these. You’ll almost always see most of those in a Dependency Walker log for Windows 7 and up.
What’s important in this depends log is the warning for AI.DLL.
That warning means that there’s missing functions: MtoA (MTOA.MLL) expects to use certain functions provided by Arnold (AI.DLL), but those functions aren’t there. For example:
And finally, if we click View > Full Paths, we see the reason for the problem:
There’s some older version of Arnold on the system, and that old version is being loaded by MtoA.mll. Most likely, the system PATH includes this location.
With a Process Monitor log, we would have seen right away that ai.dll was being loaded from a non-standard location.
Not all renderers have batch render options, so if you click the box beside the Batch Render menu command:
then you’ll get a warning:
// Warning: file: C:/Program Files/Autodesk/Maya2017/scripts/others/batchRenderOptions.mel line 19: Renderer "arnold" does not provide batch rendered options. // // Warning: file: C:/Program Files/Autodesk/Maya2017/scripts/others/batchRenderOptions.mel line 19: Renderer "mayaHardware" does not provide batch rendered options. // // Warning: file: C:/Program Files/Autodesk/Maya2017/scripts/others/batchRenderOptions.mel line 19: Renderer "mayaHardware2" does not provide batch rendered options. // // Warning: file: C:/Program Files/Autodesk/Maya2017/scripts/others/batchRenderOptions.mel line 19: Renderer "mayaVector" does not provide batch rendered options. //
All the rendering options for Arnold are in the Arnold Render Settings.
To start a batch render, click the Batch Render text in the Render menu:
In this case, a client reported a lot of noise in the shadows of his forest of opacity-mapped trees. In a progressive render, he saw lots of fireflies at the low AA levels, so it seemed to be something out of the ordinary, since he’d never had this problem before in other, similar scenes.
He managed the get rid of the noise by cranking up the light samples, the AA, and the transparency depth, at the cost of extremely long render times.
But sampling wasn’t the problem, or the solution, in this case. The problem was a large “sky” sphere that had the skydome HDR mapped to it. This sphere was just there to make the sky visible, but this sphere was visible to all ray types. The solution was to make the sphere visible to camera rays only.
Unlike a Skydome light, a textured sphere isn’t importance-sampled intelligently by Arnold. So you’ll get noise and fireflies from the random diffuse rays that happen to hit a super bright pixel in the sky texture.
hat tip: TI
In this case, a client complained that Arnold wasn’t rendering Yeti fur. I asked him to try with a simple sphere, and to send me the log (at verbosity level Warnings + Info).
This what I was looking for:
00:00:00 1222MB | there are 1 light and 2 objects: 00:00:00 1222MB | 1 persp_camera 00:00:00 1222MB | 1 skydome_light 00:00:00 1222MB | 1 utility 00:00:00 1222MB | 1 lambert 00:00:00 1222MB | 1 driver_exr 00:00:00 1222MB | 1 gaussian_filter 00:00:00 1222MB | 1 polymesh 00:00:00 1222MB | 1 list_aggregate 00:00:00 1222MB | 1 MayaShadingEngine 00:00:00 1222MB | 1 renderview_display
So, what’s there? Well, the important thing is not what’s there, but what’s not there.
There’s no procedural. If Yeti was installed properly, there would a procedural node. The Yeti extension exports a procedural node when MtoA translates the scene.
That means the PATH or MTOA_EXTENSIONS_PATH wasn’t set up properly. I always use the Yeti module file for that.
Question: how do you set up the Arnold ambient_occlusion shader so that it ignores self-occlusion?
Let’s start with the default ambient occlusion. here’s a sphere and a plane. Each has it’s own Ambient Occlusion shader. For the sphere, Ambient Occlusion.Black is Red.
Now, let’s disable Receives Shadows on the sphere.
That means no occlusion based on the plane (shadow rays from the sphere ignore the plane); but there’s still self-occlusion.
Next, Cast Shadows disabled. No self-occlusion, but no ambient occlusion on the plane either
And finally, Self Shadows disabled. Now, there’s no self-occlusion. The ambient occlusion on the sphere is coming solely from the plane
