Or, “things that happen when you use single-user licensing on a render node” 😉
In this case, a Houdini command-line render with Arnold (HtoA) failed because the AdskLicensingAgent failed to start.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: minimal, offscreen, webgl, windows.
After AdskLicensingAgent crashed, the render would continue, but license authorization would fail:
00:00:00 148MB | authorizing with license manager: user ...
00:00:31 153MB WARNING | rendering with watermarks because of failed authorization:
00:00:31 153MB | [clm.v2] timeout before callback was called
Using Process Monitor, I saw (as expected) that the problem was that the AdskLicensingAgent was loading Qt platform plugins from Houdini:
The solution? Set QT_QPA_PLATFORM_PLUGIN_PATH to point to the AdskLicensingAgent\platforms folder.
set QT_QPA_PLATFORM_PLUGIN_PATH=C:\Program Files (x86)\Common Files\Autodesk Shared\AdskLicensing\Current\AdskLicensingAgent\platforms
Unfortunately, there’s no one answer. This is a totally generic error message, and it could be anything. Typically, it’s a bug somewhere. But where?
You could try to manually isolate it…is it shaders? textures? displacement? some object in the scene?
Ideally, you’ll be able to submit a Crash Error Report (CER). That would let us see where the crash actually happened.
The backtrace in an Arnold log won’t tell you, because we hide all the symbols in the shipping Arnold. So every backtrace comes out with things like Ordinal0 or AiLightsPrepare or AiADPDialogStrings, because those just happens to be the nearest unhidden symbols.
If you had a linux backtrace, we could symbolicate that on our end to see where the crash is happening. But on Window, it’s not so easy.
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.
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: