WARNING | unable to load dynamic library .\ai_renderview.dll: The specified module could not be found.


kick checks the current working directory for plugins (shaders and procedurals). That means kick tries to load all .dll/.so/.dylib files in the current directory.

So if you do this:

cd C:\solidangle\mtoadeploy\2017\bin
kick -nodes

Then you’ll get a warning like this (plus a pop-up System Error dialog that says “Qt5Core.dll is missing from your computer”).

loading plugins from .
WARNING | unable to load dynamic library .\ai_renderview.dll: The specified module could not be found.

On OSX, the warning would  say ./libai_renderview.so, and on Linux, ./libai.so

Notice the “loading plugins from .” The single period, or dot, represents the current directory.

The solution? Don’t run kick in the MtoA bin folder. Don’t run kick in an any folder where there are non-plugin libraries.

 

[MtoA] Getting the MtoA build ID


When you contact support or log bugs, it’s nice to provide the version number and build ID of the MtoA version that you’re using.

This information is displayed in the Arnold > About box.

mtoa_buildid

But the build id (circled in the screenshot) is kinda a pain to type out. Fortunately, you can get the build ID with the arnoldPlugins command:

arnoldPlugins -gbi;
// Result: 261bd4ca (master) //

You can get both the MtoA version and the MtoA build ID like this:

print( "MtoA " + `pluginInfo -v -q "mtoa.mll"` + " - " + `arnoldPlugins -gbi`);

In Python:

print( "MtoA {} - {}".format( cmds.pluginInfo( 'mtoa', query=True, version=True), cmds.arnoldPlugins(getBuildID=True) ) )
# MtoA 1.4.2.2 - 261bd4ca (master)

Choosing hardware for rendering


In general, the more cores the better.

Here’s some general guidelines for choosing hardware:

  • Arnold scales linearly with increasing processor speed
  • Arnold scales well to multiple cores
  • For a rough estimate of  expected performance, you can multiply the clock speed by the number of physical cores.
  • Get enough RAM to hold your typical data sets (you probably should run
    some tests with your most challenging scenes)
  • Hyperthreading on Intel processors usually gives about 1.2x speedup on average.
  • If possible, running some tests is the best way to choose the best hardware for you

The case of the noisy shadows


In this case, a client reported a lot of noise in the shadows of his forest of opacity-mapped trees. In a progressive render, he saw lots of fireflies at the low AA levels, so it seemed to be something out of the ordinary, since he’d never had this problem before in other, similar scenes.

He managed the get rid of the noise by cranking up the light samples, the AA, and the transparency depth, at the cost of extremely long render times.

But sampling wasn’t the problem, or the solution, in this case. The problem was a large  “sky” sphere that had the skydome HDR mapped to it. This sphere was just there to make the sky visible, but this sphere was visible to all ray types. The solution was to make the sphere visible to camera rays only.

Unlike a Skydome light, a textured sphere isn’t importance-sampled intelligently by Arnold. So you’ll get noise and fireflies from the random diffuse rays that happen to hit a super bright pixel in the sky texture.

hat tip: TI

Vertices and the maximum valence limit


The valence of a vertex is the number of edges connected to that vertex. In Arnold, the maximum valence is 255 (that’s because of the data type we use to store the valence; we minimize the memory requirements since this is stored per-vertex).

If a mesh in the scene has a vertex with more than 255 edges, you’ll get a WARNING like this:

 [polymesh] example_mesh: mesh has at least a vertex with valence higher than 255, disabling subdivision

But if the adaptive subdivision results in a vertex with too many edges, you’ll get an ERROR:

 ERROR: [arnold] [subdiv] example_mesh: edge (144578,287741) in face 263433 has a vertex that exceeded the max valence limit of 255 

Sampling after the first bounce


With the default Diffuse = 2 sampling, you’ll get four diffuse rays for each camera ray. Those four diffuse rays are the first bounce after the camera ray “hits” a shape.

diffuse_one_diffuse_bounce

After the first bounce, Arnold sets all the sampling settings back to 1, so for each of those four diffuse rays, you get one second-bounce diffuse ray. This prevents an exponential explosion of rays as secondary rays like diffuse rays bounce around a scene.

diffuse_two_diffuse_bounces

The same thing is true for the other secondary rays such as glossy, refraction, and shadow rays.

So, in summary:

  • For a camera ray you can get multiple secondary rays (for example, multiple diffuse rays or multiple glossy rays, and for light sampling, multiple shadow rays)
  • But for a secondary ray, you’ll get just one ray. For example: one diffuse ray, one glossy ray (if any), one shadow ray, and so on.