Before getting too far into the details, it’s worth describing Karma’s support for MaterialX, and how that affects an artist building materials. Karma supports MaterialX shaders, but does not rely on MaterialX’s code-generation. Instead Karma reads the shader network of MaterialX nodes described in USD, and builds the material for the renderer on-the-fly. Because of this, Karma is able to supplement missing functionality in MaterialX, with Karma or USD Preview nodes.

Most of the time, artists should start with the Karma Material Builder, when rendering with Karma. When a “pure” MaterialX network, with no custom Karma nodes or conventions, the “USD MaterialX Builder” will only offer up MaterialX nodes supported in the pure spec.

Assigning materials to primitives in Solaris is straightforward. You can bind a material to a prim or GeomSubset using a Material Library or Material Assign node.

By default, the Material Binding Strength is Weaker Than Descendants. This means that bindings apply to all child prims, unless those child prims have their own material binding. Applying materials to ancestor prims, and setting the strength to Stronger than Descendants, can be used to override materials scene-wide.

Material bindings in USD can also apply to only specific Purposes (USD render purposes represent different types of renders, such as previews, map generation, and final renders). By default materials apply to any purpose, but you can set a material to only bind in final renders, for example.

USD supports Collection-based material bindings, but at this point there aren’t a lot of workflow/performance advantages to strongly recommend that method. (When USD Collections can be defined as patterns, and/or Hydra supports instance-overrides via collection-based assignments, this will become a very powerful workflow.)

• If you need a pure MaterialX shader, which works everywhere UsdMaterialX is supported, start with a USD MaterialX Builder.

• The Karma Material Builder simplifies creating Karma materials based on MaterialX. Inside this subnet, the ⇥ Tab menu is filtered to only show compatible Karma, USD Preview, and MaterialX nodes. This helps you avoid accidentally using VEX VOP nodes in your shader network.

• You can use MaterialX nodes to drive the patterns on Karma Hair or other Karma-specific shaders.

• Unlike Houdini’s Principled Shader, the MtlX Standard Surface node does not auto-bind its parameters to geometry attributes.

• MaterialX shaders with this icon , and which have the hmtlx prefix, are implemented using pure MaterialX nodes, but are not part of the MaterialX standard distribution.

• USD PrimVar reader is compatible with MaterialX nodes in Karma.

• Until UsdMaterialX is supported by more render delegates, the USD Preview shaders are the most common/universal way to define a material.

• For a strict USD Preview-only material, use the USD Preview Material Builder.

• VEX shaders only work with Karma CPU (not Karma XPU).

• Instead of binding directly to Cd, use the Surface Color node in your shaders. This will fall back to displayColor primvars if Cd isn’t found on the geometry. This makes VEX shaders easier to port from Mantra to Karma.

• Point Cloud or other geometry-lookup shaders should still work in Karma CPU, but they cannot access any primitives on the stage. They can only access .bgeo geometry files from disk.

Both Karma CPU and XPU support UDIM textures. Solaris also ships with some utility nodes, which are designed to allow artists to hijack UDIM support, to drive texture variation using primvars. These nodes are implemented as MtlX node graphs, so in theory they should work with any UsdMaterialX renderer that allows for changing UDIM tiles at render time.

Use mip-mapped .exr or .rat texture files with Karma. Karma can use other formats, but may not be as efficient or predictable (especially at production-scales) as it is with .exr or .rat. Using mip-mapped, tiled textures will improve performance, particularly time-to-first pixel.

Karma supports every image formats that Houdini supports, along with many supported via Open Image IO. The texture format affects performance and color space assumptions. See color space for more.

You can use the imaketx command-line utility to generate mip-mapped .exr and .rat files from other image formats. Note that imaketx only mip-maps 1 AOV for .exr images, while .rat supports mip-mapping all channels.

[09:02:04] Texture Disk Cache: Converting image /jobs/gramophone.usdz[Gramophone_Normal.png] to texture /tmp/houdini_temp/hfsT7MYFL
[09:02:05] Texture Disk Cache: Finished writing output file /tmp/houdini_temp/hfsT7MYFL
[09:04:11] Texture Disk Cache: Converting image /jobs/maps/mandril.jpg to texture /jobs/aces/maps/mandril.jpg.rat
[09:04:11] Texture Disk Cache: Finished writing output file /jobs/maps/mandril.jpg.rat    

Karma renders internally in scene linear colorspace, so texture maps must be transformed into linear space. Because Hydra doesn’t send through parameter metadata, Karma determines the source color space in a few ways:

1. If a color space input is “raw”, or the type is a vector, Karma does not transform the image colors.

2. If a reader node is set to “Auto”, Karma to go through a process to detect the source color space:

   1. Check for role strings embedded in the file name, such as diffuse_map.rec709.exr.

   2. Check metadata in the image file for a colorspace specification.

   3. Assume sRGB for 8-bit images, linear other formats/depths.

Because Hydra doesn’t pass through parameter metadata, MtlX Image nodes with a color3 or color4 signature are always in “auto” mode. To force MtlX Image nodes to read their images in linear format (without transformation), set the parameter’s signature to a non-Color value (such as float, vector3, or vector4).

By default Karma uses some optimizations for transmissive materials, such as glass and water.

• Fake caustics are enabled by default

• Internal reflections are also disabled.

This can look fine in many situations, and is pretty fast. However true caustics and internal reflections can also be enabled to get a more physically correct result..

Nested dielectrics can also be setup using material or geometry properties, to render nested transmissive materials correctly.

Non-light primitives can be made emissive, so they contribute illumination at render time. The following shaders support emission:

Creating an emissive shader is usually just the first step. Sampling emissive geometry isn’t as efficient as sampling an actual light primitive. Karma has special render properties, that can improve the sampling of emissive geometry. These properties can be set on the material, or on the geometry objects.

The Karma Material Properties sets render propeties on the Material. While a Render Geometry Settings node can tell Karma to treat certain geometry primitives as light sources. Some additional parameters are also available to control the look and quality of the emissive geometry.