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:


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


[MtoA] MayaFile node uses a default color for missing textures

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
import os

def set_useDefaultColor(b):"file")
    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:

[node MayaFile]
	[attr useDefaultColor]
		default		BOOL	false

ERROR | [mtoa] [xgenTranslator] Could not find xgen_procedural in search path $ARNOLD_PLUGIN_PATH

This error

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.

[Linux] Missing .sog files?

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 

or this:

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:

  • couldn’t be loaded because LD_LIBRARY_PATH didn’t include the Maya lib folder, so all the tbb-related libraries were missing.
  • 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

[SItoA] Uninstalling SItoA

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.


[MtoA] The case of the renderer that failed to register

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:

import mtoa.cmds.registerArnoldRenderer

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