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.