What is MaterialX?
MaterialX is an open standard specification and library API for describing and transferring rich material and look-development content between applications and renderers. Originated at Lucasfilm in 2012, MaterialX has been used by Industrial Light & Magic in feature films such as Star Wars: The Force Awakens and Rogue One: A Star Wars Story, and real-time experiences such as Trials On Tatooine.
MaterialX addresses the need for a common, open standard to represent the data values and relationships required to transfer the complete look of a computer graphics model from one application or rendering platform to another, including shading networks, patterns and texturing, complex nested materials and geometric assignments. To further encourage interchangeable CG look setups, MaterialX also defines a complete set of data creation and processing nodes with a precise mechanism for functional extensibility.
How do I use MaterialX?
After downloading the MaterialX distribution from the MaterialX GitHub repository, follow the instructions in the Developer Guide to compile the MaterialX C++ and Python libraries for your platform and environment. The MaterialX libraries can be used to author MaterialX support for a DCC tool or standalone program, and they contain a straightforward API for generating, editing, traversing, reading, and writing MaterialX content.
What's included in the MaterialX distribution?
The MaterialX Distribution currently includes:
- Cross-platform C++ source code for the library with C++ and Python bindings:
- Core MaterialX Library for MaterialX elements, graph generation and graph traversal
- XML serialization and file accessor utilities
- ShaderGen code generators and data for GLSL and OSL
- The MaterialXRender hardware renderer
- The MaterialXView viewer
- Automated unit test suite
- CMake files supporting compilation on Windows (Microsoft Visual Studio 2015 or newer), Linux (GCC 4.8 or newer), or Mac OS X (Xcode/Clang 3.3 or newer)
- Documentation, including the current specification and developer guides
- Mtlx definition files and OSL source code for pattern and shader nodes
- Various resources for creating and rendering MaterialX content, including XML syntax example files and example materials, images, and geometry.
Are there standalone viewers or DCC plugins for MaterialX content?
Yes! The MaterialX distribution includes a standalone viewer, MaterialXView, which leverages shader generation to build GLSL shaders from MaterialX graphs, rendering the results using the NanoGUI framework.
DCC Plugins for MaterialX import and/or export have been created for Arnold and Substance Painter, and other platforms will have support soon. Individual development teams can also use the MaterialX Library to create the standalone tools and plugins they require, and we’re excited to see what the community builds (and shares) using the core functionality we’ve provided.
Is there a standard BxDF shader for MaterialX?
The choice of BxDF shader, with all its various parameters and controls, is generally a studio-specific choice. The Physically-Based Shaders specification and MaterialX's ShaderGen component provide a library of contemporary BxDF, EDF and VDF functions, as well as functions for layering, scattering, thin-film and sheen coatings, and various utility functions that can be used to create energy-conserving physically-based shading models using MaterialX nodegraphs. These can then be used in renderers, DCC Viewports, and other applications supporting OSL or GLSL shaders. The MaterialX Library also includes a full nodegraph-based implementation of the Autodesk Standard Surface, a complete, general-purpose surface shader suitable for modern rendering needs, as well as Pixar's UsdPreviewSurface.
How do you achieve visual parity between DCC packages?
In order to achieve exact visual parity between DCC packages, there must be a common representation of the BxDF shaders on which the material content is based. For renderers supporting OSL or GLSL (and perhaps other languages in the future) including the MaterialX Viewer application, a node graph representation of the shader can be created using native MaterialX nodes, and generated for appropriate targets. Alternatively, a set of agreed-upon shaders that have been implemented across the tools used in look development may be used, with MaterialX documents simply referencing the appropriate shaders for each material asset.
If these criteria are met, and careful attention is paid to matching color spaces and viewing transforms, then the transferred look should exactly match the original. But even without strict node and shader equivalence, MaterialX transfer can still be useful: even when the target package uses a different BxDF shader, we’ve found it useful to employ a “best match” approach when importing material content, with additional modifications applied by an artist or automated process to accommodate the particular requirements of the target package. One advantage of using MaterialX documents in this role is that they can faithfully capture the shading and color-space assumptions of the authoring package, giving an importer access to the full information it needs to generate a best match with its own shaders and nodes.
Why are the standard nodes so simple?
Commercial DCC packages and studio-proprietary operator node shaders will often have additional features and capabilities beyond those provided by the MaterialX Standard Nodes. The standard nodes are intentionally made simple so that they may be extended to add custom functionality as needed, or used as "building blocks" to create nodegraph-based representations of more complex functions.
We would discourage users and studios from simply creating a set of custom nodes mimicking the naming and functionality of their own proprietary node shaders and using MaterialX to express graphs of these custom nodes, as this virtually guarantees that setups will not be transportable to other packages or studios since they will generally not have access to these custom nodes.
If your application or node/shader set has extra parameters or features beyond what the standard nodes provide, there are several preferred options:
- If it's possible to describe the functionality of a proprietary node using a combination of standard nodes, you can create a nodegraph implementation of it and "wrap" that nodegraph with a nodedef to describe the functional interface for your node. This will be completely portable across any MaterialX-compliant application.
- If it's not possible to do the above, but your node is a superset of the functionality of a standard node, it is recommended that you use standard MaterialX nodes and add custom parameters into invocations of those standard nodes as needed. While this will not be completely transportable to other packages without the same implementation, one would at least get "something", and the presence of the custom parameter(s) would give a clue about what might be needed to get a full match.
- If your node has similar functionality to a standard MaterialX node but uses a different name and/or differently-named parameters and inputs, you can define your node as an implementation of the standard node specifically for your "target" application, and use "implname" attributes to define the names on your node which differ from the standard one.
If there is widespread demand for adding new standard nodes or new parameters/inputs to existing standard nodes, we are open to expanding the standard node package and amending the specification. We also would encourage the community to submit new node definitions and implementations.