Updating procedural file paths with string_replace


This is actually pretty cool…you can use an operator to update file paths before an ASS file or ABC file is loaded, then use another operator to touch the geometry loaded by that procedural.

For example, suppose at render time you want to replace trex_proxy.abc with trex.abc. You can easily do that with a string replace operator:

  • *.(@node==’alembic’) selects all Alembic procedural nodes
  • Match matches any file name that ends with “_proxy.abc”
  • Replace replaces “_proxy.abc” with “.abc”

And that all happens before the abc file is loaded.

We can see this in the Arnold log (Debug verbosity). First the string replace operator is applied; then after the abc file is loaded, a set parameter operator is applied to the nodes loaded from the abc file.

| initializing 16 nodes …
| [operators] init op: 'aiStringReplace1'
| [operators] cook op: 'aiStringReplace1' | node: '/aiStandIn/aiStandInShape'
| [proc] /aiStandIn/aiStandInShape: loaded 1 nodes (1 objects, 0 shaders)
| [operators] init op: 'TRex:tRexShape_aiSetParameter1'
| [operators] cook op: 'TRex:tRexShape_aiSetParameter1' | node: '/TRex:tRex/TRex:tRexShape'

Auto-instancing in Arnold 6.0.2


Controllable auto-instancing on ASS procedurals: You can now disable the default automatic instantiation of procedurals pointing at the same ASS file with the auto_instancing parameter on each procedural or by the procedural_auto_instancing option. This workaround is sometimes useful when overriding procedural parameters with operators.

Arnold 6.0.2 release notes https://docs.arnoldrenderer.com/x/1gGvBg

So, what’s all that mean?

It means that if you load the same ass file many times, Arnold will load the ass file just one time, and then automatically create instances of that. For example, if I load an ass file three times, I will get two instances.

In previous versions, this was known as the procedural cache, and it was a global option. Now it’s called auto_instancing and you can set it on each procedural node (aka aiStandin in Maya).

In general, you want auto instancing, because instancing is more efficient than loading the same ass file over and over. But if you’re using operators to apply different looks to the same procedural, you need to turn off auto instancing. Otherwise all the procedurals will have the same look (because they all be instances of the same one procedural).

For example, with auto instancing on, I get this, even though I’ve assigned different looks to each procedural (standin):

Everything has the same look with auto instancing on

I can also tell from the Arnold log that I’m getting instances. Note that 2 are reused

| ---------------------------------------------------------
| ass file cache           
|   unique (loaded from disk)              1 (33.33%) 
|   reused (found in cache)                2 (66.67%) 
|   total referenced .ass files            3 (100.00%) 
| ---------------------------------------------------------

If I turn off auto instancing (in the procedural parameters)

then I get three different looks

In the Arnold log, that looks like this (0 reused means 0 instances)

| ---------------------------------------------------------
| ass file cache
| unique (loaded from disk) 1 (100.00%)
| reused (found in cache) 0 (0.00%)
| total referenced .ass files 1 (100.00%)
| ---------------------------------------------------------

Updating texture paths with the string_replace operator


Arnold 6.0.2 includes a new string_replace that lets you do find and replace on string parameters.

For example, I got an ass procedural file from a user, but I didn’t get the textures. Normally I would just enable ignore textures, but this time I used string_replace to replace all textures with my trusty-old-Softimage noicon pic.

string_replace operator in MtoA (Maya)
  • Selection selects all Arnold image nodes. So this string replace operation applies to all string parameters of the image node (which includes name, uvset, color_space as well as filename).
  • Match is a regular expression that matches anything that looks like C:/project/sourceimages/example.tx or X:/temp/test/example.tx
    • [A-Z] matches any drive letter from A to Z
    • .* matches any string of characters
    • Note that match is a regular expression, so you cannot use glob wildcards like this: C:\sourceimages\*.tx (because * is not any string of characters, it is zero or more occurrences of the previous character)
    • \.tx matches a period followed by “tx”. The period has to be escaped with a backslash because ‘.’ matches any single character
    • Note that this match expression won’t handle something like example.txtra.tx
  • Replace is the string that replaces anything matched by the Match expression.

backdoor Arnold: setting visibility


If you want to control object visibility with operator, or the Arnold Python API, or by editing an ASS file, you need to understand Arnold’s visibility parameter.

In the UI, the object visibility options look like a bunch of separate parameters:

 

but in Arnold, all those options are stored in one visibility parameter.

For example, if an object is visible to the camera (primary visibility), and to transmission (both diffuse and specular), then that’s visibility 13.

Why 13? Because 13 = 1 + 4 + 8

  • camera rays = 1
  • diffuse transmission rays = 4
  • specular transmission rays = 8

The Arnold visibility parameter tells Arnold the rays to which the object is visible.

  • visibility 0 means the object isn’t visible to any rays
  • visibility 255 means the object is visible to all rays
  • visibility 253 means the object isn’t visible to shadow rays (so the object does not cast shadows).

Here’s the decimal values for all the different ray types.

To figure out the visibility, just add up the values for the rays you want.

Ray typeDecimal Value
Camera (Primary Visibility)1
Shadow (Casts Shadows)2
Diffuse transmission4
Specular transmission8
Volume16
Diffuse reflection32
Specular reflection64
SSS (subsurface)128

Using an operator to override parameters in an ass file


Arnold 5.1 adds operators, which among other things, allow you to override parameters in ass files loaded by procedural nodes.

Here’s a quick example using the brand new MtoA 3.0

I exported some particles from Softimage, loaded them into Maya with an aiStandin (aka an Arnold procedural), and then used a set_parameter operator to scale the radius by 0.5

Note that I connect my operator by setting the Target Operator in the Render Settings.
set_parameter_radius
I can chain two set_parameter operators together, to set the mode and then scale the radius:
set_parameter_mode_radius