Category Archives: Procedurals

Updating procedural file paths with string_replace

Posted on by
Reply

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

Posted on by
Reply

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%)
| ---------------------------------------------------------

Procedural namespaces

Posted on by
Reply

Here’s something new in Arnold 5.0

Each standin (aka procedural) now has its own namespace. So you don’t have to have unique shader names in every ASS file.

For example, here’s two standins. There’s no unique shader names. Both ASS files use the exact same shader names. And there’s no naming conflicts, and each standin renders with the correct shading.

namespaces.png

[FAQ] Can I transfer Arnold shaders to another app?

Posted on by
Reply

For example, can I transfer Arnold shaders from 3ds Max to Maya? Or from Houdini to Maya?

The answer is no. The Arnold plugins don’t include code for reading shader nodes from an ASS file and creating shader trees inside the host application (eg Maya, Houdini, or Cinema 4D).

You can use ASS files to take shapes and shaders from one app and render them in another app, but those shapes and shaders are never created inside the other app.

An MtoA Standin (aka an Arnold Procedural in HtoA and C4DtoA) references an ASS file, and passes that on to Arnold at render time.

standins

The ASS file contains Arnold nodes (shapes and shaders). Those Arnold nodes are not created inside the 3D application.

Instead, the standin node is translated to an Arnold procedural node, and at render time, that procedural node is expanded, and all the Arnold shapes and shaders are created inside the Arnold scene.

Setting the procedural’s load_at_init parameter to true would also fix this.

Posted on by
Reply

There’s an Arnold error that recommends setting the load_at_init parameter, but people don’t always know where to find that in their favorite Arnold plugin.

ERROR| [proc] c4d|Arnold_Procedural: bounds supplied to procedural node are not large enough to contain the actual underlying geometry.
Replace given bounds: (-1, -1, -1) X (1, 1, 1), with: (-9.4028616, -9.43616867, -9.21633244) X (9.3304739, 9.43616867, 9.21633244).
Setting the procedural's load_at_init parameter to true would also fix this.

The load_at_init parameter controls whether the procedural (standin) is loaded during scene intialization (before rendering starts), or during rendering (when a ray hits the procedural bounding box).

By default, load_at_init is false, which means that procedural loading is deferred until render time.

And so, in MtoA, C4DtoA, and SItoA, the load_at_init parameter is exposed as Defer Standin Load, which is enabled by default. In HtoA, you have a Load At Init parameter on for the Arnold Procedural node.