Frequently-Asked Questions

What is MaterialX?

MaterialX is an open standard for transfer of 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 current lack of a common, open standard for representing 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.

MaterialX is an Open Source project released under a modified Apache license.

Why use MaterialX?

Workflows at Computer Graphics production studios require multiple software tools for different parts of the production pipeline, and shared and outsourced work requires companies to hand off fully look-developed models to other divisions or studios which may use different software packages and rendering systems. There are currently high-quality solutions (e.g. USD, Alembic) for exchanging scene hierarchies and geometric data between tools, but no effective solutions for exchanging rich material content. MaterialX provides a schema for describing material networks, shader parameters, texture and material assignments, and color-space associations in a precise, application-independent, and customizable way.

In our own production experience, we’ve found MaterialX to be particularly effective for:

  • Universal material libraries
  • Interchange of material networks between DCC tools and renderers
  • Platform-independent asset archiving

In our collaborations with other companies and studios, we’re aware of compelling projects to use MaterialX in additional ways, including:

  • Universal material editors with extensible node sets
  • Shader code generation from MaterialX graphs

We believe that the presence of a robust, platform-independent standard for material content will open the door to major artistic, pipeline, and development improvements in the future, with material assets able to travel smoothly between different authoring packages, different renderers, and even different media.

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.

Are there standalone viewers or DCC plugins for MaterialX content?

Not yet, but we’ve been collaborating with companies who are in the process of developing this functionality, and it’s our hope that their work will become public in the near future. For now, it’s up to individual development teams 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.

How do you achieve visual parity between DCC packages?

In order to achieve exact visual parity between DCC packages, the following criteria must be met:

  • There must be a common representation of the BxDF shaders on which the material content is based. Most commonly, this is achieved by using a small set of agreed-upon shaders that have been implemented across the tools used in look development, with MaterialX documents simply referencing the appropriate shaders for each material asset. We’re also aware of developers working on a more general and portable approach, where a MaterialX graph is used to describe the BxDF itself, with the appropriate shader code being generated on the target system as needed.
  • All nodes referenced by the material content must be implemented in a compatible manner across the DCC packages that will be used. The MaterialX library currently provides OSL definitions for the standard nodes to make them straightforward to implement; we hope that definitions in GLSL and other common shading languages can be made available in the future.

If these criteria are met, then the transferred look should exactly match the original. But this is not the sole circumstance in which MaterialX transfer is useful: even when the target package uses a different BxDF shader, we’ve found it very useful to employ a “best match” approach when importing material content, with additional modifications being applied by the artist or an automated process to accommodate for the particular requirements of the target package. One advantage of using MaterialX documents in this role is that they 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?

Most commercial DCC packages and most studio-proprietary operator node shaders will have additional features and capabilities beyond those provided by the MaterialX Standard Nodes. The standard nodes are intentionally made simple in order to try to find a balance between "usable and useful" and "cross-package compatible".  In particular, the standard nodes attempt to provide functionality that is fairly universal among most packages.

We would discourage users and studios from creating a complete set of custom nodes mimicking the 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.

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 there is widespread demand for adding new standard nodes or new parameters/inputs to existing standard nodes, we are absolutely open to enhancing the standard node package and amending the specification.

Is there a standard BxDF shader for MaterialX?

The choice of BxDF shader, with all its various parameters and controls, is a very personal and studio-specific choice. While our industry is clearly moving in the direction toward energy-conserving physically-based shading models, there isn't a clear consensus in the adoption of any particular shader or even specific BxDFs.

Additionally, MaterialX is intended to be useful for the full spectrum of applications from offline/batch rendering content-creation tools to interactive preview rendering to real-time/game engine applications. These applications have very different requirements for surface shader functionality, and choices that are appropriate for one application may not be suitable for others.