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.
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:
Here’s a quick walkthrough (no audio) of how to get a Process Monitor log:
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:/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.
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:
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
Here’s something important to remember when you’re debugging a scene…
By default, the MayaFile node uses a default color if a texture is missing.
This means the render won’t abort because of missing textures, and you won’t see ERRORs like these in the Arnold log for missing texture files:
ERROR | [texturesys] OpenImageIO could not open "sourceimages/noicon.tx" as tx: Could not open file "sourceimages/noicon.tx"
ERROR | [texturesys] Invalid image file "sourceimages/noicon.tx"
So missing textures can easily go unnoticed.
If you need to disable Use Default Color for testing, an easy way is to export an ASS file and then render it with kick -set MayaFile.useDefaultColor false.
I suppose you could also modify the Maya scene file directly:
import maya.cmds as cmds
for item in filenodes:
cmds.setAttr( "%s.aiUseDefaultColor" % item, b )
set_useDefaultColor( False )
And finally, you can change the default value of the Use Default Color parameter by adding this to shaders/mtoa_shaders.mtd:
default BOOL false
ERROR | [mtoa] [xgenTranslator] Could not find xgen_procedural in search path $ARNOLD_PLUGIN_PATH
happens only when MtoA is first loaded, and it can be safely ignored. It doesn’t cause any problems when you render, and MtoA loads the XGen procedural from the MtoA procedurals folder.
The error is a consequence of how MtoA searches folders when it loads extensions. If you really need to get rid of the error, you can try copying the xgen_procedural library to the MtoA shaders folder.
Sometimes on Linux you may get “unable to load dynamic library” errors for .sog files. Like this:
00:00:00 0MB WARNING | unable to load dynamic library: /home/stephen/solidangle/mtoa/2014/xgen_procedural.sog: cannot open shared object file: No such file or directory
00:00:00 0MB WARNING | unable to load dynamic library: /usr/apps/houdini/houdini-13.0.343/htoa/arnold_plugins/driver_houdini.sog: cannot open shared object file: No such file or directory
Don’t worry about the “.sog” part. In most cases, Arnold isn’t actually looking for a .sog file. Arnold is trying to load a .so file, and either the .so itself or a dependency is missing. The “.sog” is printed by mistake in the log message (and this is fixed in the next Arnold version).
So (heh) focus your investigation on why Arnold couldn’t load the .so file (try running ldd on it).
In the two examples above:
- xgen_procedural.so couldn’t be loaded because LD_LIBRARY_PATH didn’t include the Maya lib folder, so all the tbb-related libraries were missing.
- driver_houdini.so was missing some Houdini dependencies, but in this case it was being loaded into MtoA, so driver_houdini wasn’t needed and the warning could be safely ignored.
What’s a .sog?
If a plugin has a .sog extension, AiLoadPlugins() will load the plugin with RTLD_GLOBAL, which means the symbols from the plugin will be globally exposed and available to other plugins.
.sog is a Maya naming convention for an .so to be dlopen’ed with RLD_GLOBAL
When you install an addon like SItoA, you may see an error like this the next time you start Softimage:
// ERROR : 2356 - This plug-in is not installed: ArnoldRenderPreferences
That’s because addons like SItoA install custom preferences, which are left behind when you uninstall the addon. At startup, Softimage finds the custom preference but can’t find the plugin that owns the preference (because it’s been uninstalled).
To get rid of this error, go to your Softimage user folder, and delete the Data\Preferences\Arnold Render.preset file.
In this case, a customer running Maya 2013 on Ubuntu reported this error when he tried to load the mtoa plugin:
API error detected in plugins/mtoa/Main.cpp at line 710: (kFailure): Unexpected Internal Failure
ERROR | Failed to register renderer 'arnold'
That specific line in plugins/mtoa/Main.cpp runs these two lines of Python:
So I asked the customer to run that Python in the Maya script editor, and that gave us this error:
# Error: ImportError: file
/usr/autodesk/maya2013-x64/lib/python26.zip/hashlib.py line 63: No module
named _md5 #
Now we’re cooking with EVIL gas! I’ve seen these kinds of errors before…
This appears to be general problem with Maya 2013 and pymel (I found a few different posts about this via Google search). For example, this thread from the pymel project, or the Troubleshooting section on this page.
In brief: you need to create some symlinks to the right versions of the libssl.