[mtoa] Getting a Process Monitor log to troubleshoot problems loading mtoa


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:

process_monitor_mtoa

Here’s a quick walkthrough (no audio) of how to get a Process Monitor log:

SItoA is open-sourced


First, here’s some Arnold renders of a few old-time Softimage models:

And now, here’s the announcement:

Softimage to Arnold (or SItoA), the Arnold plugin for Autodesk Softimage is being made available to the community under an Apache2.0 open source license at:

https://github.com/Autodesk/sitoa

This repository contains the official SItoA plugin source code. Solid Angle, the company behind the Arnold renderer, and now part of Autodesk, developed the SItoA plugin commercially from 2009 to 2017.

After the Softimage end-of-life announcement in April 2014, Solid Angle committed to continue the development and maintenance of SItoA for at least a year, and then extended this period until July 2017, porting SItoA to the new Arnold 5 API along the way.

Governance
 

Please submit your issues and pull requests on github, the old Trac server will remain available for a while as read-only but we won’t accept any new users.

We will continue to monitor and review pull requests submitted to this repo on a voluntary basis, but will not release official builds any more.

Acknowledgments

Before it was open-sourced, throughout the years, SItoA has been developed by:

  • Luis Armengol
  • Borja Morales
  • Stefano Jannuzzo

With contributions by:

  • Andreas Bystrom
  • Steven Caron
  • Julien Dubuisson
  • Steffen Dunner
  • Michael Heberlein
  • Paul Hudson
  • Halfdan Ingvarsson
  • Vladimir Jankijevic
  • Alan Jones
  • Guillaume Laforge
  • Thomas Mansencal
  • Helge Mathee
  • Eric Mootz
  • Holger Schoenberger
  • Frederic Servant
  • Jules Stevenson

Special thanks to all the users who passionately provided feedback, production assets, bug reports and suggested features during those years.

[mtoa] Using dirmap to update paths


How can you update the paths used to load textures, standins, or volumes? Use dirmap.

You can use dirmap to update the paths for the following nodes:

  • aiImage (Image Name)
  • aiStandin (Path)
  • aiVolume (Filename)
  • MayaFile (Image Name)

For example, if I have a scene file that uses Linux paths like /server/assets/textures/noicon.tx, I can do this:

dirmap -en true;
dirmap -m "/server/assets" "D:/Assets/";

After I run that, when I load a scene Maya will replace “/server/assets” with “D:/Assets” in all file paths.

You can test your directory mapping (dirmap) like this:

dirmap -cd "/server/assets/textures/noicon.tx";
// Result: D:/Assets/textures/noicon.tx //

So:

  • Enable dirmap with dirmap -en, and then create a directory mapping with dirmap -m
  • Load a scene and the dirmap is applied.

TIP For batch rendering, you can use a pre-render script to apply dirmap.

BONUS TIP: dirmap does not update a path if the path is valid. dirmap replaces paths that cannot be resolved.

[MAXtoA] Rendering XGen in 3ds Max


 

You can export an ASS file from Maya (with the XGen primitives) and then use an Arnold Procedural to load the ASS file into 3ds Max.

You need to add these two folders to the system environment variable Path:
  • C:\Program Files\Autodesk\Maya2018\plug-ins\xgen\bin
  • C:\Program Files\Autodesk\Maya2018\bin

For example, you can copy this:

C:\Program Files\Autodesk\Maya2018\plug-ins\xgen\bin;C:\Program Files\Autodesk\Maya2018\bin;

and paste it at the beginning of the current Path:

windows_sys_env_var

Restart 3ds Max after you do this.

Then add the MtoA procedurals folder to the Plugin Search Path:

maxtoa_plugin_search_path

 

[MtoA] Error: defaultArnold Driver can’t create file


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.

 

[MtoA] cross-platform volume file names


The Arnold volume node uses the texture search path, so you don’t have to use an absolute path in the volume filename.

volume_texture_searchpath

So if you need to set up a Maya scene so that the OpenVDB volumes work on any platform, you could put an environment variable in the Texture Search Path

volume_env_var

Just note that support for volume filenames is still a little … rough. You can’t enter an absolute path in the aiVolume Filename box, then enter a texture search path, and expect MtoA to automatically export a relative path. That still needs to be implemented.

For now, here’s what to do:

  • When you first create the volume, load the vdb file and leave the full absolute path in the aiVolume Filename box.
  • Select the grids and set the other volume parameters.
  • Then set the texture search path and strip off the path from the volume file name (leaving just the file name).
  • Now the environment variable will control where Arnold looks for the vdb file.

The Arnold volume node also support environment variables, so you could do this:

volume_env_var_in_filename

But again, once you put the environment variable into the Filename, the path won’t be resolved inside Maya (but it will work when you render).

Tracking down the “error initialzing CLM (9)”


It’s not rocket science, but here’s a little application of the scientific method to technical support.

Observation

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.

procmon_adlmintres

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

Hypothesis

Autodesk licensing will fail if there’s a problem with AdlmIntRes.xml

Testing

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