Overriding shader parameters in procedurals


Procedurals (aka standins) don’t expose the parameters of objects and shaders inside the procedural.

For example, you cannot override shader parameters like standard.Kd (diffuse color) or standard.emission (emission scale) by setting those parameters on a procedural node.

But what you can do is use “user data parameters”. Inside the procedural, use user data shaders to set shader parameters, but don’t define the user data parameters on the shape.

For example, if I wanted to be able to override the emission scale, then I would set up a shader like this:

user_data_procedurals

A userDataFloat shader sets the Emission. The important thing is that the custom attribute emission_scale is not defined on the shape, so the default value is used instead.

By doing that, I can put an emission_scale attribute on the procedural node, and the aiUserDataFloat shader picks up that value.

user_data_procedurals2

In the above example, I’ve added a mtoa_constant_emission_scale attribute to the standinShape, and that allows me to set the Emission for that specific standin.

In Arnold scene source (ASS) format, I have this in my main scene file:

procedural
{
 name ArnoldStandIn1Shape
 dso "standin_torus_w_emission.ass"
 ...
 declare emission_scale constant FLOAT
 emission_scale 0.649999976
}

And in the ASS file loaded by the procedural, I have this:

polymesh
{
 name pTorusShape1
 ...
 shader "someshader"
}

standard
{
 name someshader
 ...
 emission aiUserDataFloat1
 ...
 #
 # NO user data declared here
 #
}

userDataFloat
{
 name aiUserDataFloat1
 floatAttrName "emission_scale"
 defaultValue 0.100000001
}

					

[C4DtoA] How can I make my background object visible in refractions?


You can’t. The background object isn’t visible in refractions. Or reflections, or anything but camera rays.

Here’s an example: a refractive sphere in front of a torus, in front of the background checkerboard object. The black areas are where the background object isn’t visible to refraction rays.

c4d_background_object_refraction

The “background object” is actually a shader plugged into the Arnold background slot.

You won’t see it in Cinema 4D, but when C4DtoA translates the scene to Arnold, the background object is translated as a shader plugged into the options.background parameter (in Cinema 4D, this is the Environment > Background parameter in the Render Settings).

In an ASS file, it looks like this:

options
{
background "c4d|Background"
}

image_plane
{
 name c4d|Background
 color c4d|Arnold_Shader_Network|checkerboard
 lenx 1
 leny 1
 ox 0
 oy 0
}

The image_plane node is a shader, and if you were to check its code, you’d see that it handles camera rays only; for any other ray type (like refraction), the image_plane shader returns black.

shader_evaluate 
{ 
    if (!(sg->Rt & AI_RAY_CAMERA)) 
    {
        sg->out.RGBA = AI_RGBA_BLACK;
        return; 
    }

 

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


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

If your processor does not support SSE4.2, 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.2, 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.2 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.2 is supported.
    SSE4.2          *       Supports Streaming SIMD Extensions 4.2
  • If you see a dash (-), then SSE4.2 is not supported.
    SSE4.2          -       Supports Streaming SIMD Extensions 4.2

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

The important bit is this error:

# Error: line 1: IOError: file C:\Program Files\Autodesk\Maya2016\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] Hiding the image file statistics in the Arnold log


Here’s a good example of why you might use the User Options, and how it lets you set Arnold parameters that aren’t exposed by MtoA in Maya.

If you set the verbosity level to Warnings + Info, you’ll get some detailed image statistics in the Arnold log:

image_file_statistics

But what if you’ve got thousands of image files (eg udims)? You might not want all that in your log. There used to be a check box in the Arnold Render Settings that allowed you to turn off the detailed image file statistics, but we removed that a few years ago.

But the Arnold options.texture_per_file_stats parameter is still there, so you can use the User Options field to set that parameter to false. Just enter the parameter name “texture_per_file_stats” and the parameter value, like this:

render_settings_user_options