[MtoA] Instancing lights

Posted on May 6, 2015 by xsisupport

If you want to instance lights in Maya, use Duplicate Special. MtoA will correctly translate those instances to Arnold (as copies, not instances, because Arnold itself doesn’t support light instances).

MtoA doesn’t support the particle instancer for lights.

PS I don’t think Maya supports instancing lights with the particle instancer. The Maya docs say “Do not instance lights; they’ll have no effect in rendering.”, and that’s the behavior I’ve observed with mental ray and the Maya Software renderer. Also, if I leave the viewport set to Viewport 2.0, Maya crashes when I try to use the particle instancer with point or spot lights (and that’s without MtoA loaded).

[MtoA] Flushing the texture cache from Python

Posted on April 29, 2015 by xsisupport

MtoA provides an arnoldFlushCache command (and the Arnold > Flush Caches menu uses that command). You can call it from Python like this:

import maya.cmds as cmds
cmds.arnoldFlushCache( textures=True )

[Arnold] Standard shader AOVs and shading trees

Posted on April 2, 2015 by xsisupport

Here’s a question asked recently. Given a shading tree like the one below, why don’t AOVs like diffuse_direct include the blended color from the Blend Color node?

The answer: because it is the Standard shader that writes the AOV, not the Blend Color shader. The diffuse_direct AOV gets the diffuse layer calculated by the Standard shader, and that’s it.

The MtoA AOV browser shows you what AOVs are implemented by which shaders:

[MtoA] Finding your Arnold log file

Posted on March 26, 2015 by xsisupport

When you enable file logging, it can seem a bit of a mystery where the .log files end up. You may find log files in different folders of your project, like the scenes folder, or the sourceimages folder.

Here’s how it works.

If the MTOA_LOG_PATH environment variable is set, the log files are saved to the folder specified by MTOA_LOG_PATH.
If MTOA_LOG_PATH is not set, the log files are saved in the current workspace directory (in MEL, that’s workspace -q -directory). In other words, the log files are saved to last place you went with the Maya file browser. If you haven’t used the file browser yet, the log file is saved in the root folder of the project.
If you click the folder icon beside the Filename text box, you can choose where the log files are saved.

Note that the log files will always include the frame number, so you’ll get arnold.1.log, arnold.2.log, and so on.

[Arnold] System requirements: minimum Windows version

Posted on March 24, 2015 by xsisupport

As of Arnold 4.2.3.1, the minimum Windows version is Windows 7. We no longer support Windows versions before Windows 7 and Windows Server 2008 R2.

This applies to all plug-ins (such a MtoA 1.2.02 and later, or SItoA 3.4 and later) that use Arnold 4.2.3.1 or later.

If you try to load an Arnold plugin on an unsupported Windows, you’ll get an error (something like “The specified procedure could not be found”).

On Vista with Arnold 4.2.3.1 or later, kick -nodes gives you a more specific error:

"kick.exe - Entry Point Not Found" 
"The procedure entry point SetThreadGroupAffinity could not be located in the dynamic link library KERNEL32.dll."

[MtoA] Setting defaults for options and drivers

Posted on March 20, 2015 by xsisupport

If you want to set default rendering options, or change the defaults for AOVs, you can use the hook functions provided by mtoadeploy/2015/scripts/mtoa/hooks.py.

hooks.py provides a number of setup functions that MtoA calls during initialization. You can override the default hook functions to do your own custom setup. For example, you could put this Python in your userSetup.py:

import mtoa.hooks

#
# Set some defaults for the defaultArnoldRenderOptions node
#
def setupOptions(options):
    options.AASamples.set(2)
    options.display_gamma.set(1)
    options.light_gamma.set(2.2)
    options.shader_gamma.set(2.2)
    options.texture_gamma.set(2.2)
    options.GITotalDepth.set(6)    
mtoa.hooks.setupOptions = setupOptions    

#
# Enable Merge AOVs for the defaultArnoldDriver and
# any other drivers created later by the user 
#
def setupDriver(driver, aovName=None):
    driver.mergeAOVs.set(1)
mtoa.hooks.setupDriver = setupDriver

The setupOptions() function gets a pymel.PyNode object that holds the defaultArnoldRenderOptions. setupDriver() gets an aiAOVDriver pynode and the name of the AOV as a string.

Here’s a snippet that shows how to work with the pynode for an aiAOVDriver node.

import pymel.core as pm
driver = pm.PyNode('defaultArnoldDriver')

print driver
print driver.aiTranslator.get()
print driver.mergeAOVs.get()

The case of the disappearing particles

Posted on February 28, 2015 by xsisupport

In this case, nParticles (render type = point) weren’t visible behind a refractive plane:

For the points render type, you get an Arnold points shape (with mode “disk”), so I exported an ASS file to see the parameter settings on the points node. I noticed the visibility 243 right away (the default visibility is 255, which is visible to all rays). And sure enough, in the Render Stats for the particle shape, some rays were turned off (and the check boxes were disabled too).

I used the User Options to force the visibility to 255

and the particles behind the refractive surface appeared:

This is a Maya thing. For most particle render types, the particles are not visible in reflections or refractions. It says so in the docs:

You can turn on reflections, refractions, and shadows when you software render Clouds, Tubes, and Blobby Surfaces

I’m not sure where the default values are set, but I did find the AEtemplate code that disables the render stats for all particle render types except the “s/w” type:

// C:\Program Files\Autodesk\Maya2015\scripts\AETemplates\AEparticleLayout.mel
		if( $value == 7 || $value == 8 || $value == 9 ) {
			// software particle type
			editorTemplate -dimControl $nodeName "visibleInReflections" false;
			editorTemplate -dimControl $nodeName "visibleInRefractions" false;
			editorTemplate -dimControl $nodeName "castsShadows"    		false;
			editorTemplate -dimControl $nodeName "receiveShadows" 		false;
			editorTemplate -dimControl $nodeName "primaryVisibility" 	false;
		} else {
			// hardware particle type
			editorTemplate -dimControl $nodeName "visibleInReflections" true;
			editorTemplate -dimControl $nodeName "visibleInRefractions" true;
			editorTemplate -dimControl $nodeName "castsShadows"			true;
			editorTemplate -dimControl $nodeName "receiveShadows" 		true;
			editorTemplate -dimControl $nodeName "primaryVisibility" 	true;
		}

So, since that AE template code just enables and disables UI controls, but doesn’t change the actual values, another way to enable Visible in Refractions (or Visible in Reflections) is to do this:

Change the Particle Render Type to one of the “s/w” types, like Blobby Surface.
Now the Visible in Refractions check box is enabled.
Select the check box.
Go back and change the Particle Render Type to points.

Now when you render, the points are visible to refraction rays, so they show up behind the glass.

[MacOSX] Troubleshooting with dtruss

Posted on February 20, 2015 by xsisupport

In a previous post, I looked at how things could go wrong in the file ~/pymel.log wasn’t accessible. On Windows, this was fairly easy to track down using Process Monitor:

On Mac OS X, I had to use dtruss. For example, I ran this command to trace the syscalls of the Maya Render command:

sudo dtruss -f -t open_nocancel -n Render 2> /var/tmp/mtoarender.log

When the render job failed, I checked the log file, and found this line:

11668/0x35deb: open_nocancel("/Users/stephenblair/pymel.log\0", 0x601, 0x1B6) = -1 Err#13

One important gotcha: if you repeat the render, you won’t find any mention of pymel error in the dtruss output. My guess is that at that point, the Render command ends up going through the file system cache, so dtruss doesn’t see the attempt to find pymel.log.

Here’s a quick summary of the dtruss command I showed above:

Use sudo to run dtruss, because it needs additional privileges.
-f tells dtruss to follow any child processes (like mayabatch) launched by Render
-t filters the trace for open_nocancel system calls
-n tells dtruss to trace the process named “Render”
2> /var/tmp/mtoarender.log redirects the dtruss output to a file

The case of the “cannot remove alias” RuntimeError

Posted on February 18, 2015 by xsisupport

In this case, mayabatch reported some runtime errors when loading a certain scene:

# Traceback (most recent call last):
#   File "C:\solidangle\mtoadeploy\2015\scripts\mtoa\callbacks.py", line 415, in deferredCallback
#     func(*args, **kwargs)
#   File "C:\solidangle\mtoadeploy\2015\scripts\mtoa\aovs.py", line 471, in createAliases
#     pm.aliasAttr(sg + '.ai_aov_' + name, remove=True)
#   File "C:\Program Files\Autodesk\maya2015\Python\lib\site-packages\pymel\internal\pmcmds.py", line 134, in wrappedCmd
#     res = new_cmd(*new_args, **new_kwargs)
# # RuntimeError: 'aiStandardSG.ai_aov_direct_specular' is not a unique name.  Cannot remove alias.

Now, even though I have the advantage of access to the MtoA source code, the problem remained: how do I fix the scene and stop these errors? To find a solution (and understand the problem) I had to resort to examining the Maya ASCII version of the scene.

The “fix” was to clear the AOV names on the shadingEngine node:

setAttr "aiStandardSG.aovs[0].aov_name" -type "string" ""; 
setAttr "aiStandardSG.aovs[1].aov_name" -type "string" ""; 
setAttr "aiStandardSG.aovs[2].aov_name" -type "string" "";

The problem is that the shadingEngine node has some named custom AOVs, but no corresponding “attribute alias” list. So the AOV name couldn’t be found in the alias list, which in the error message came out as “not a unique name”.

In the Maya ASCII version of the problem scene, I saw this:

createNode shadingEngine -n "aiStandardSG"; 
	addAttr -ci true -h true -sn "aal" -ln "attributeAliasList" -dt "attributeAlias"; 
	setAttr -s 4 ".aovs"; 
	setAttr ".aovs[0].aov_name" -type "string" "direct_diffuse";
	setAttr ".aovs[1].aov_name" -type "string" "direct_specular";
	setAttr ".aovs[2].aov_name" -type "string" "indirect_diffuse";
	setAttr ".aovs[3].aov_name" -type "string" "indirect_specular";

instead of this:

createNode shadingEngine -n "aiStandard1SG";
	addAttr -ci true -h true -sn "aal" -ln "attributeAliasList" -dt "attributeAlias";
	setAttr ".ihi" 0;
	setAttr ".ro" yes;
	setAttr -s 4 ".aovs";
	setAttr ".aovs[0].aov_name" -type "string" "direct_diffuse";
	setAttr ".aovs[1].aov_name" -type "string" "direct_specular";
	setAttr ".aovs[2].aov_name" -type "string" "indirect_diffuse";
	setAttr ".aovs[3].aov_name" -type "string" "indirect_specular";
	setAttr ".aal" -type "attributeAlias" {"ai_aov_direct_diffuse","aiCustomAOVs[0]",
			"ai_aov_direct_specular","aiCustomAOVs[1]",
			"ai_aov_indirect_diffuse","aiCustomAOVs[2]",
			"ai_aov_indirect_specular","aiCustomAOVs[3]"} ;

I don’t know how the user managed to get the scene into that state 😉

The case of the missing PyMel debug log file

Posted on February 16, 2015 by xsisupport

In several recent cases, I had to figure out why MtoA wouldn’t load on a render farm. The root cause turned out to be the PyMel debug log: ~/pymel.log

If PyMel cannot find or open ~/pymel.log, that stops PyMel and anything that uses PyMel (like MtoA).

On a render farm, this can happen if the render manager user account doesn’t have a home folder, ~/pymel.log doesn’t expand to a valid location, or if user doesn’t have read-write permissions on pymel.log.

For example, here’s the Process Monitor log when ~ cannot be resolved:

And here’s the log when the user doesn’t have read-write permissions:

The location of pymel.log is specified by the pymel.conf configuration file, like this:

os.path.expanduser('~/pymel.log')

When there’s a problem with the PyMel debug log, it can be hard to tell from the MtoA errors. You may see API errors like this (but the line numbers all point to unrelated bits of source code). However, if you see these line numbers with the MtoA 1.x, it’s probably a pymel.log problem.

API error detected in plugins\mtoa\Main.cpp at line 794
: (kFailure): Unexpected Internal Failure
00:00:00   514MB ERROR   | Failed to register renderer 'arnold'

API error detected in plugins\mtoa\Main.cpp at line 716
: (kFailure): Unexpected Internal Failure
00:00:00   514MB ERROR   | Failed to register Arnold swatch renderer

API error detected in plugins\mtoa\Main.cpp at line 716
: (kFailure): Unexpected Internal Failure
00:00:00   515MB ERROR   | Failed to register Arnold swatch renderer

You might also see errors like this:

API error detected in plugins/mtoa/Main.cpp at line 794
: (kFailure): Unexpected Internal Failure
Error: line 1: IOError: file /Applications/Autodesk/maya2015/Maya.app/Contents/Frameworks/Python.framework/Versions/Current/lib/python2.7/logging/__init__.py line 916: 13
Error: line 1: Failed to register renderer 'arnold'
Error: line 1: initializePlugin function failed (mtoa)

Arnold Support Corner

Tips, tricks, and troubleshooting help from Steve "xsisupport" Blair

Category Archives: MTOA