[MtoA] The case of the machine that was unable to dynamically load mtoa.mll

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.


Vertices and the maximum valence limit

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 

Sampling after the first bounce

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:

  • For a camera ray you can get multiple secondary rays (for example, multiple diffuse rays or multiple glossy rays, and for light sampling, multiple shadow rays)
  • But for a secondary ray, you’ll get just one ray. For example: one diffuse ray, one glossy ray (if any), one shadow ray, and so on.

[MtoA] What environment variables does MtoA use?

MtoA uses these environment variables:

  • ARNOLD_PLUGIN_PATH is for shaders.
    MtoA and kick use this environment variable. Arnold doesn’t (when you write Arnold code that loads an ASS file, Arnold doesn’t getenv ARNOLD_PLUGIN_PATH)
  • MTOA_TEMPLATES_PATH is for the Attribute Editor (AE) templates of Arnold shaders. For example, if you use the alShaders:
    set MTOA_TEMPLATES_PATH  C:\solidangle\alShaders\alShaders-win-1.0.0rc18-ai4.2.12.2\ae
  • MTOA_EXTENSIONS_PATH is for MtoA extensions like Yeti. By default, MTOA_EXTENSIONS_PATH points to the extensions folder in the MtoA installation.
  • MAYA_CUSTOM_TEMPLATE_PATH is for Node Editor templates for Arnold shaders. For example, if you use the alShaders:
    set MAYA_CUSTOM_TEMPLATE_PATH C:\solidangle\alShaders\alShaders-win-1.0.0rc18-ai4.2.12.2\aexml
  • My personal favorite, MTOA_STARTUP_LOG_VERBOSITY, sets the MtoA log verbosity during startup: 1 for Errors and Warnings, 2 for Errors, Warnings, and Info, and 3 for all. This can be handy for troubleshooting MtoA loading problems.
  • MTOA_LOG_PATH is the default location for Arnold log files.

These are not MtoA environment variables:

  • ARNOLD_PROCEDURAL_PATH is an HtoA environment variable. It’s not used by MtoA (or kick).
  • MTOA_PROCEDURAL_PATH doesn’t exist. No such environment variable is used or supported by MtoA.
  • [MtoA] The renderer ‘arnold’ used by this scene, is not currently available


    // 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:

    1. Click Windows > Settings/Preferences > Plug-in Manager
    2. Scroll down until you see mtoa.mll
    3. Click the Loaded and Auto load check boxes.

    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.

    [FAQ] Can I transfer Arnold shaders to another app?

    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.

    Overriding shader parameters in procedurals

    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:

     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:

     name pTorusShape1
     shader "someshader"
     name someshader
     emission aiUserDataFloat1
     # NO user data declared here
     name aiUserDataFloat1
     floatAttrName "emission_scale"
     defaultValue 0.100000001