Using oiiotool and maketx to create a mipmap debug texture


To visualize the different mipmap levels, you can create a custom tx file with different textures for each mipmap level. It’s pretty easy to do with maketx. (or you can download this one)

First, to create the different mipmap levels, I use oiiotool (I use the one shipped with HtoA).

oiiotool --pattern checker:width=32:height=32:color1=1,0,1 8192x8192 3 -o 8192.tif
oiiotool --pattern checker:width=32:height=32:color1=1,0,1 8192x8192 3 -o 8192.tif
oiiotool --pattern checker:width=32:height=32:color1=1,0,0 4096x4096 3 -o 4096.tif
oiiotool --pattern checker:width=32:height=32:color1=1,.25,0 2048x2048 3 -o 2048.tif
oiiotool --pattern checker:width=32:height=32:color1=0,0,1 1024x1024 3 -o 1024.tif
oiiotool --pattern constant:color=1,1,0 512x512 3 -o 512.tif
oiiotool --pattern constant:color=0,1,1 256x256 3 -o 256.tif
oiiotool --pattern constant:color=.5,0,0 128x128 3 -o 128.tif
oiiotool --pattern constant:color=.5,.5,0 64x64 3 -o 64.tif
oiiotool --pattern constant:color=0,1,0 32x32 3 -o 32.tif
oiiotool --pattern constant:color=.5,0,.5 16x16 3 -o 16.tif
oiiotool --pattern constant:color=.82,.41,.12 8x8 3 -o 8.tif
oiiotool --pattern constant:color=0,.5,.5 4x4 3 -o 4.tif
oiiotool --pattern constant:color=0,.75,1 2x2 3 -o 2.tif
oiiotool --pattern constant:color=.5,.5,.5 1x1 3 -o 1.tif

You can’t use constant colors for all the levels, because OIIO will optimize your texture into a constant color and there won’t be any texture access.

Then I use the -mipimage flag to combine all the mipmap levels into a tx file:

maketx 8192.tif ^
-mipimage 4096.tif ^
-mipimage 2048.tif ^
-mipimage 1024.tif ^
-mipimage 512.tif ^
-mipimage 256.tif ^
-mipimage 128.tif ^
-mipimage 64.tif ^
-mipimage 32.tif ^
-mipimage 16.tif ^
-mipimage 8.tif ^
-mipimage 4.tif ^
-mipimage 2.tif ^
-mipimage 1.tif ^
-format exr -d half -o debug.tx

Here’s a couple of examples of using mip-map bias with the debug tx file.

Mip-map Bias = -1 (read a higher resolution mipmap)

mipmap-bias-1

Mip-map Bias = 2 (read two-levels lower resolution mipmap)

mipmap-bias

 

[mtoa] The case of the layeredTexture and Arnold 5 closures


In this case, the question was “why doesn’t layeredTexture work in Arnold 5?”

layeredTexture

This is a common question/problem with Arnold 5: shaders plugged into color slots.

In Arnold 5, shaders like Standard Surface (and Lambert too) don’t return colors. So in general, you can’t plug them into color parameters. And Blinns are translated into Standard Shaders by MtoA, so you can’t plug a Blinn into a color either.

Instead of a layeredTexture, you can use a layeredShader. It knows how to handle shaders that don’t return colors. Or you could use the Arnold aiMix shader.

layeredShader

So, if these shaders don’t return colors, what do they return?

Closures. They return closures.

closure is not a color, it’s a bundle of data that tells Arnold how the surface (or volume) scatters light. Arnold takes care of all the ray tracing and light sampling, and then uses the closure to figure out the surface color.

 

From Master Zap:

“The addition of “closures” is a complete godsend. This relegates the work of rendering to the renderer, as it should be. No longer are material shaders little dumb raytracers that count lights and shoot reflection rays. A material shader returns mix of BxDF closures, and the renderer itself takes care of doing “the right thing” with them”.

From the Arnold 5 release notes:

Closures: a new closure parameter type has been added, which shaders can output instead of final colors. There are BSDF, BSSRDF, emission, matte, transparency and volume closures. See the API documentation and examples for more details on how to use these. Linking a color to a closure parameter will automatically create an emission closure with that color. A closure parameter however can’t be linked or converted to a color, as the integrator only computes lighting after shader evaluation.

 

[mtoa] Running a silent install


On Windows, run the MtoA installer with the flags /S /FORCE_UNINSTALL=1

MtoA-2.0.2.2-2018.exe /S /FORCE_UNINSTALL=1

You can use /D to specify a different install location.

On Linux, use the – – silent command line flags. Note the space between “- -” and “silent”.

sudo sh MtoA-2.0.1.1-linux-2017.run -- silent

The Linux installer will put MtoA in /opt/solidangle/mtoa/<maya version>. If you want to install in a different location, you can extract MtoA, and then set up your own script for installing MtoA.

On OSX, use the installer command:

sudo installer -pkg "MtoA-2.0.2.4-darwin-2017.pgk" -target /

Note that -target is a volume, not a folder.

WARNING | unable to load dynamic library .\ai_renderview.dll: The specified module could not be found.


kick checks the current working directory for plugins (shaders and procedurals). That means kick tries to load all .dll/.so/.dylib files in the current directory.

So if you do this:

cd C:\solidangle\mtoadeploy\2017\bin
kick -nodes

Then you’ll get a warning like this (plus a pop-up System Error dialog that says “Qt5Core.dll is missing from your computer”).

loading plugins from .
WARNING | unable to load dynamic library .\ai_renderview.dll: The specified module could not be found.

On OSX, the warning would  say ./libai_renderview.so, and on Linux, ./libai.so

Notice the “loading plugins from .” The single period, or dot, represents the current directory.

The solution? Don’t run kick in the MtoA bin folder. Don’t run kick in an any folder where there are non-plugin libraries.

 

[MtoA] Using standins with MASH dynamics


mash_dynamics_w_standin

Here’s a way to use standins with MASH dynamics: instance a low-poly mesh that has its Arnold Translator set to procedural.

  • Use a low-poly primitive as a proxy for the standin
  • In the low-poly primitive Attribute Editor, set Arnold Translator to procedural, and enter the path to the ASS file in the Path box.

arnold_translator_procedural

  • Instance that proxy object with MASH, and apply MASH dynamics

Procedural namespaces


Here’s something new in Arnold 5.0

Each standin (aka procedural) now has its own namespace. So you don’t have to have unique shader names in every ASS file.

For example, here’s two standins. There’s no unique shader names. Both ASS files use the exact same shader names. And there’s no naming conflicts, and each standin renders with the correct shading.

namespaces.png