Monthly Archives: March 2017

[MtoA] Getting the MtoA build ID

Posted on by
Reply

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)

The case of the mesh that wouldn’t displace

Posted on by
Reply

Riddle me this: two meshes with the same displacement shader. One has displacement, the other doesn’t. What’s up with that?

dispmaps

Your first guess might be that it’s a “padding is at least %x smaller than it should be” warning, like this:

// Warning: [disp] planeTestShape: padding is at least 10x smaller than it should be! given disp_padding: 0, recommended: 0.00835387595 //

But that’s not it.

In this case, the plane (the mesh on the right, with displacement) was scaled up. Displacement happens in object space, before any transformations are applied. So effectively, the mesh was displaced, and then everything was scaled up. The displacement scale was just too small for the other mesh, which hadn’t been scaled up).

If you freeze the scaling on the plane, then both objects will be displaced the same, as long as the displacement scale was set large enough.

[MtoA] UnicodeEncodeError when rendering

Posted on by
Reply

UnicodeDecodeError

If you get this UnicodeEncodeError when you render

# Error: line 1: UnicodeEncodeError: file C:\Program Files\Autodesk\Maya2016\bin\python27.zip\encodings\utf_8.py line 16: ascii #

it’s probably because because the project folder has a special character in the name (for example, an accent mark like é).

If that’s not it, then we’d need more context (hint: everything else that is logged in the script history).

For a project name with a special character, you’ll see something like this in the script history:

file -f -save -options "v=0;";
// C:/maya/projects/New_Projéct/scenes/blank.mb // 
# Error: line 1: UnicodeEncodeError: file D:\Program Files\Autodesk\Maya2017\bin\python27.zip\encodings\utf_8.py line 16: ascii # 
# Error: line 1: UnicodeEncodeError: file D:\Program Files\Autodesk\Maya2017\bin\python27.zip\encodings\utf_8.py line 16: ascii #

 

 

The case of the 15% rendering utilization

Posted on by
Reply

Or, “Understanding the Arnold log, part 23”

In this case, a client had very low (15%) CPU usage for a render. We got the Arnold log, and here’s the interesting part:

00:01:44  856MB   | OpenImageIO ImageCache statistics (0000000025850F20) ver 1.5.24
00:01:44  856MB   |   Images : 3 unique
00:01:44  856MB   |     ImageInputs : 299 created, 2 current, 3 peak
00:01:44  856MB   |     Total size of all images referenced : 192.4 MB
00:01:44  856MB   |     Read from disk : 12.0 GB
00:01:44  856MB   |     File I/O time : 45m 41.5s (48.1s average per thread)
00:01:44  856MB   |     File open time only : 0.0s
00:01:44  856MB   |   Tiles: 711523 created, 559 current, 640 peak
00:01:44  856MB   |     total tile requests : 249379431
00:01:44  856MB   |     micro-cache misses : 3353694 (1.34482%)
00:01:44  856MB   |     main cache misses : 711523 (0.285317%)
00:01:44  856MB   |     Peak cache memory : 10.0 MB
00:01:44  856MB   |   1 not tiled, 1 not MIP-mapped
00:01:44  856MB   | -----------------------------------------------------------------------------------
00:01:44  856MB   | performance warnings:
00:01:44  856MB   | Rendering utilization was only 15%. Your render may be bound by a single threaded process or I/O.
00:01:44  856MB   | -----------------------------------------------------------------------------------
  • File I/O time seems a bit high for three textures and a render that took less than 2 minutes
  • main cache* misses is pretty high. Normally you expect something less than 0.01%.

    0.285% means that texture tiles are loaded from disk (instead of from the in-memory texture cache) once out of every 350 texture lookups. That’s a little high.

    * The main cache is the cache of 64×64 texture tiles loaded from disk into the texture cache.

  • Peak cache memory is 10.0 MB !!! That explains the main cache misses: the texture cache is really, really small.

Other clues to the too-small texture cache size:

  • Read from disk is 12 GB but the total size of all images referenced is just 192.4 MB, and the peak cache memory was just 10.0 MB
    So the same texture data is constantly being unloaded from the cache and reloaded from disk.

The solution? Increase the size of the texture cache. The current default is 2048, which should be good in most cases.

Choosing hardware for rendering

Posted on by
Reply

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

Ignoring self-occulsion

Posted on by
Reply

Question: how do you set up the Arnold ambient_occlusion shader so that it ignores self-occlusion?

Let’s start with the default ambient occlusion. here’s a sphere and a plane. Each has it’s own Ambient Occlusion shader. For the sphere, Ambient Occlusion.Black is Red.

image (1)

Now, let’s disable Receives Shadows on the sphere.
That means no occlusion based on the plane (shadow rays from the sphere ignore the plane); but there’s still self-occlusion.

image (2)

Next, Cast Shadows disabled. No self-occlusion, but no ambient occlusion on the plane either

image (3)

And finally, Self Shadows disabled. Now, there’s no self-occlusion. The ambient occlusion on the sphere is coming solely from the planeimage (4)

The case of the missing Yeti fur

Posted on by
Reply

In this case, a client complained that Arnold wasn’t rendering Yeti fur. I asked him to try with a simple sphere, and to send me the log (at verbosity level Warnings + Info).

This what I was looking for:

00:00:00  1222MB         | there are 1 light and 2 objects:
00:00:00  1222MB         |       1 persp_camera
00:00:00  1222MB         |       1 skydome_light
00:00:00  1222MB         |       1 utility
00:00:00  1222MB         |       1 lambert
00:00:00  1222MB         |       1 driver_exr
00:00:00  1222MB         |       1 gaussian_filter
00:00:00  1222MB         |       1 polymesh
00:00:00  1222MB         |       1 list_aggregate
00:00:00  1222MB         |       1 MayaShadingEngine
00:00:00  1222MB         |       1 renderview_display

So, what’s there? Well, the important thing is not what’s there, but what’s not there.

There’s no procedural. If Yeti was installed properly, there would a procedural node. The Yeti extension exports a procedural node when MtoA translates the scene.

That means the PATH or MTOA_EXTENSIONS_PATH wasn’t set up properly. I always use the Yeti module file for that.