The case of the missing Yeti fur


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.

[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.

dwi_01.jpg

But you can ignore that, because if you take a closer look, you’ll see that MSVCR90.DLL is indeed found and loaded.

dwi_02.jpg

Likewise, you can ignore all these. You’ll almost always see most of those in a Dependency Walker log for Windows 7 and up.

dwi_03

What’s important in this depends log is the warning for AI.DLL.

dwi_04

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:

dwi_05

And finally, if we click View > Full Paths, we see the reason for the problem:

dwi_06

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.

 

[MtoA] Unable to dynamically load : mtoa.mll The specified module could not be found.


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.

Check if your processor supports SSE4.1

As of Arnold 4.2.16.2, the SSE requirement is now SSE4.1

If this is the first time you’ve tried to use the Maya to Arnold (MtoA) plugin, then check whether your processor supports SSE4.1.

Reinstall MtoA

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.

Get a Process Monitor log

If a clean install of MtoA doesn’t work (and the computer does support SSE4.1), 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:

process_monitor_mtoa

Here’s a quick walkthrough (no audio) of how to get a Process Monitor log:

[MtoA] The renderer ‘arnold’ used by this scene, is not currently available


warning_renderer_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
    plug-in_manager_mtoa
  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.

[Arnold] [MtoA] How to check if your processor supports SSE4.1


As of Arnold 4.2.16.2, the requirement is now “just” SSE4.1.

This blog post is for Google search to find; I’ve already blogged about the SSE4.1 requirement elsewhere.

If your processor does not support SSE4.1, 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.1, here’s a few suggestions:

  • Google your processor and “SSE”
    cpu-world is pretty reliable, but I have seen one or two cases where the info was wrong, and SSE4.1 wasn’t really supported by a processor.
  • Windows: Download and run coreinfo -f
  • OSX: Run sysctl -a | grep machdep.cpu.features
  • Linux: Check /proc/cpuinfo

A note about coreinfo:

  • If you see an asterisk (*), then SSE4.1 is supported.
    SSE4.1          *       Supports Streaming SIMD Extensions 4.1
  • If you see a dash (-), then SSE4.1 is not supported.
    SSE4.1          -       Supports Streaming SIMD Extensions 4.1

[MtoA] The curse of pymel.log


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

or this:

Error: line 1: IOError: file /Applications/Autodesk/maya2018/Maya.app/Contents/Frameworks/Python.framework/Versions/Current/lib/python2.7/logging/__init__.py line 935: 13

The important bit is this error:

# Error: line 1: IOError: file C:\Program Files\Autodesk\Maya2018\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.

[MtoA] Unable to dynamically load mtoa.mll …The specified procedure could not be found.


If the MtoA plug-in  does not load and you get a “The specified procedure could not be found” error like this:

// Error: line 1: Unable to dynamically load : C:/solidangle/mtoadeploy/2016/plug-ins/mtoa.mll
The specified procedure could not be found.
 // 
// Error: line 1: The specified procedure could not be found.
 (mtoa) //

then there’s a few basic things you need to check first.

Does your processor support SSE4.1?

Support for SSE4.1 is a minimum requirement. You won’t be able to load MtoA or use Arnold if your processor doesn’t support SSE4.1.

Check the environment in Maya

For example, does the PATH include any older versions of MtoA? If you’re on Windows, run the MEL command system(“set”) to get the environment. On OSX or Linux, run system(“printenv”).

Look for any environment variable that has an Arnold or MtoA folder in it. For example, on Windows, you should not have any MtoA bin folders in PATH.

Get a Process Monitor log

If a clean install of MtoA doesn’t work (and the computer does support SSE4.1), 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:

process_monitor_mtoa

Here’s a quick walkthrough (no audio) of how to get a Process Monitor log:

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

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:

  • 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.

The case of the blue render view


Reason #35 why you should check the Arnold log

In this case, a scene that used to render yesterday, now just resulted in a blue render view, like this:

blue_render_view

Anytime the render view doesn’t update when your render, you can be fairly sure there’s some ERROR in the Arnold log.

In this case, the problem was a broken path to the IES file used by a photometric light. In the Arnold log, there was this ERROR:

00:00:04 870MB ERROR | [photometric] can't open C:/Assets/IES/example.ies

It’s easy to say “check the log”, but where do you find the log? It’s not like there’s a nice, color-coded button (red for error) on the render view UI that will pop up the log for you.

  • On Windows, you should see the Arnold log in the Output Windows. However, I find that this happens only when I start Maya from the command line. If I start Maya from the Windows Start menu, the Arnold log messages don’t show up in the Output Window. So I have to enable file logging, and check the log file.
  • On OSX and Linux, you’ll also have to enable file logging, unless you start Maya from a terminal.

Update: For Google:

  • Arnold renders a black screen
  • Arnold renders a blue screen

 

WARNING : [ass] node name already in use


Shader nodes must have unique names.

So if you’re using standins, each standin ASS file has to have unique shader node names. Otherwise you’ll get unexpected results when you render, like all standins having the same shading, or some “flickering” in animation if the order of standin loading changes.

In the Arnold log, look for “node name already in use” warnings:

WARNING | [ass] standin_01.ass line 50: node name "aiStandard1SG" already in use
WARNING | [ass] standin_01.ass line 58: node name "aiStandard1" already in use
WARNING | [ass] standin_01.ass line 118: node name "file1" already in use
WARNING | [ass] standin_01.ass line 147: node name "aiNoise1" already in use

 

If each standin should look different, you need to have unique shader names in each ASS file. If you’re using MtoA, that includes the name of the SG node (for example, aiStandard1SG).