- In the Render Settings, set the log verbosity
- Click Arnold > Open Arnold RenderView, and then open the Arnold Render Logs
- In the Arnold Render Logs window, click IPR Log Frequency > Full
We want the full log, because that includes everything that happens before progressive refinement (that’s the AA -3, -2, -1, 1, 3) renders.
One of the strange thing about supporting Arnold at Autodesk is that you have to be a guru-level licensing expert on Autodesk licensing (not RLM, but Autodesk licensing).
In this case, Maya 2019 would silently fail at startup. Sometimes you’d see the splash screen, but then that would just disappear.
- There was nothing in the Adlm.log
- No MayaAdlm log was created
- The MayaCLM log had only this:
ERROR: checkoutLicense: Failed to authorize license
- The clm log did have this:
JsProductLicenseFact.loadSelectedProductInfoKey - Unable to get selected product key due to unknown problem.
TIP All these log files are in the Temp folder.
- On Windows, look in %LOCALAPPDATA%\Autodesk\Logs
- On OSX, look in $TMPDIR
- On Linux, look in /var/tmp
Process Monitor confirmed that the ProductInformation.pit file was missing:
ProductInformation.pit is an all-important file used by the licensing infrastructure. Every Autodesk product must be registered in that pit file.
If ProductInformation.pit is missing, or corrupted, then everything stops working.
In this case, when the user tried to render after enabling the OptiX denoiser, they got this error:
ERROR | [gpu] OptiX version 0.30.91 is lower than the minimum required version 5.0.0
This was with MtoA 3.0.1, which means Arnold 188.8.131.52
So, that means there is an incompatible version version of the OptiX library on the system, and it’s being loaded instead of the OptiX that ships with MtoA.
I probably could have just checked the PATH setting, but I used Process Monitor to absolutely sure, and I found this:
The problem is that another renderer added itself to the PATH. That’s a bad thing 😉
The solution? Remove that folder from PATH. Create a batch file or wrapper script to set the required environment when you start Maya to use the other software. Rather like the mtoa module file sets PATH when you start Maya.
NOTE In previous versions of MtoA, this would prevent MtoA from even loading.
If a clean install of MtoA doesn’t work (and the computer does support SSE4.1), then “The specified module could not be found.” usually means there’s a missing dependency. Dependency Walker is a decent, if aging, tool for checking out dependencies, but for leaving no stone unturned, I prefer Process Monitor.
The MtoA plugin (mtoa.mll) depends on a handful of files only. Here’s the log of loaded DLLs for a working MtoA:
Here’s a quick walkthrough (no audio) of how to get a Process Monitor log:
You’ll get an error like this if your project path has characters like é or ü or Ô in it.
// Error: [driver_exr] defaultArnoldDriver@driver_exr.RGBA: can't create file ".exr": OpenEXR exception: Permission denied. // // Error: [driver_jpeg] defaultArnoldDriver@driver_jpeg.RGBA: can't create file ".jpg": Unable to open file ".jpg” // Error: [driver_png] defaultArnoldDriver@driver_png.RGBA: can't create file ".png": Could not open file ".png"
Arnold can’t create the output file, because the special characters mess up the resolution of the output path, which ends up as an empty string.
So with no path provided, the ouput driver tries to write “.jpg” in the current working directory, which is probably something like C:\Program Files\Autodesk\Maya2018.
Use plain text characters for your project folders.
It’s not rocket science, but here’s a little application of the scientific method to technical support.
The Autodesk licensing system loads AdlmIntRes.xml
I used dtruss on macOS and Process Monitor on Windows to see what files are accessed by the licensing system. (On Linux, I would use strace)
On Windows, the file %LOCALAPPDATA%\Autodesk\Logs\AdlmIntRes.xml is loaded.
On macOS: $TMPVAR/AdlmIntRes.xml:
56944/0x16208b8: stat64("/var/folders/vb/1d7zhsx97q7_ddz43nccbyj00000gn/T//AdlmIntRes.xml\0", 0x7FFF55D22F00, 0x0) = 0 0 56944/0x16208b8: stat64("/var/folders/vb/1d7zhsx97q7_ddz43nccbyj00000gn/T//AdlmIntRes.xml\0", 0x7FFF55D22F30, 0x0) = 0 0 56944/0x16208b8: open_nocancel("/var/folders/vb/1d7zhsx97q7_ddz43nccbyj00000gn/T//AdlmIntRes.xml\0", 0x0, 0x1B6) = 37 0
On Linux: /var/tmp/AdlmIntRes.xml
Autodesk licensing will fail if there’s a problem with AdlmIntRes.xml
- Delete AdlmIntRes.xml
No problem. The file is recreated
- Delete the contents of AdlmIntRes.xml and save the file.
License authorization fails with the error [clm] error initialzing CLM (9)
If you just installed the Windows version of C4DtoA 2.x, and you don’t see C4DtoA in the Plugins menu, it’s probably because you need to install the Visual Studio 2015 redistributable.
Riddle me this: two meshes with the same displacement shader. One has displacement, the other doesn’t. What’s up with that?
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.
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 #
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.