[Arnold] Understanding the texture cache


Arnold uses the OpenImageIO texture cache. From the OIIO Programmer Documentation:

In short, if you have an application that will need to read pixels from many large image files, you can rely on ImageCache to manage all the resources for you. It is reasonable to access thousands of image files totalling hundreds of GB of pixels, efficiently and using a memory footprint on the order of 50 MB.

So, if you’re using tx files (tiled and mipmapped textures), then Arnold can read tiles as required, and use the texture cache to keep memory usage under control.

The reason we don’t read all the textures at once is that many of our customers have (literally) 100+GB of textures, so we use a texture cache that constantly loads small bits of texture data as required, and unloads old data.

By default, the size of the texture cache is 2048KB (as of Arnold 4.2.13.0). The size of the texture cache is set in the Arnold Render Settings.

Max Cache Size
The maximum amount of memory to be used for texture caching. Arnold uses a tile-based cache with a LRU (Least Recently Used) type algorithm, where the least recently used tiles are discarded when the texture caches is full.

Note If we get an error reading a texture, we mark that texture as bad and we never try to read it again. This makes the renderer a lot faster when you have a missing texture, since we won’t ask the file server millions of times to read from a nonexistent file. But in a transient network error case, one bad experience and the rest of your render has the texture missing.

[MtoA] Switching between multiple versions of MtoA


start_menu_mtoa

If, like me, you need to switch between different versions of MtoA, here’s a recipe for setting that up.

First, you have to install multiple versions. As you probably already know, the MtoA installer always wants to uninstall first. I take care of that by zapping the Uninstall registry entry with this command:

reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall\MtoA2016" /f

Then I run the MtoA installer and install in a folder with the version name, like this:
C:\solidangle\mtoadeploy\2016-1.2.7.3

I start Maya with a batch file that creates a symbolic link named “C:\solidangle\mtoadeploy\2016” that links to the version of MtoA I want to use:

rmdir C:\solidangle\mtoadeploy\2016
mklink /D C:\solidangle\mtoadeploy\2016 C:\solidangle\mtoadeploy\2016-1.2.7.3
rem mklink /D C:\solidangle\mtoadeploy\2016 C:\solidangle\mtoadeploy\2016-1.2.2.0

set RLM_DEBUG=arnold
start "" "C:\Program Files\Autodesk\Maya2016\bin\maya.exe" %* -log %TEMP%\maya.log

My batch file also adds the location of my custom mtoa.mod to MAYA_MODULE_PATH. My custom mtoa.mod points to “C:\solidangle\mtoadeploy\2016”, and handles all versions of Maya:

+ MAYAVERSION:2018 mtoa any C:\solidangle\mtoadeploy\2018
PATH +:= bin
MAYA_CUSTOM_TEMPLATE_PATH +:= scripts/mtoa/ui/templates
MAYA_SCRIPT_PATH +:= scripts/mtoa/mel
MAYA_RENDER_DESC_PATH +:= 
+ MAYAVERSION:2017 mtoa any C:\solidangle\mtoadeploy\2017
PATH +:= bin
MAYA_RENDER_DESC_PATH +:=
MAYA_CUSTOM_TEMPLATE_PATH +:= scripts/mtoa/ui/templates
MAYA_SCRIPT_PATH +:= scripts/mtoa/mel
+ MAYAVERSION:2016 mtoa any C:\solidangle\mtoadeploy\2016
PATH +:= bin
MAYA_CUSTOM_TEMPLATE_PATH +:= scripts/mtoa/ui/templates
+ MAYAVERSION:2015 mtoa any C:\solidangle\mtoadeploy\2015
PATH +:= bin
MAYA_CUSTOM_TEMPLATE_PATH +:= scripts/mtoa/ui/templates
+ MAYAVERSION:2014 mtoa any C:\solidangle\mtoadeploy\2014
PATH +:= bin
+ MAYAVERSION:2013 mtoa any C:\solidangle\mtoadeploy\2013
PATH +:= bin