# MaterialX is a shading network, not a file format for one renderer > MaterialX is an Apache-2.0 open standard from the Academy Software Foundation for describing rich material and look-development content in a renderer-neutral way, and the clearest evidence is the Open Chess Set, one .mtlx file plus a glTF asset rendered in both Arnold for Maya and Karma XPU for Houdini. The library around the standard is a C++17 codebase with Python bindings, a viewer that generates GLSL through NanoGUI, and eight console scripts. **AcademySoftwareFoundation/MaterialX** — MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. - Repository: https://github.com/AcademySoftwareFoundation/MaterialX - Website: http://www.materialx.org/ - Stars: 2,267 · Forks: 465 - Language: C++ - License: Apache-2.0 - Published: 2026-09-29 · Updated: 2026-09-29 · Language: en - Canonical page: https://hysenlabs.com/projects/academysoftwarefoundation-materialx ## The proof of portability is one asset, two renderers MaterialX describes itself as an open standard for representing rich material and look-development content in computer graphics, with a platform-independent description that can be exchanged across applications and renderers. The most persuasive evidence in the repository is the Open Chess Set, an open reference asset consisting of a MaterialX file in the Standard Surface shading model and a glTF geometry file. It was authored by Moeen Sayed and Mujtaba Sayed and contributed by Side Effects, and the README shows the same set rendered in Arnold for Maya and again in Karma XPU for Houdini. Two renderers with different shader models producing the same asset from the same source is the claim made concrete, and it is a much better argument than a specification document. The history explains how the standard got broad enough for that to be possible: launched at Industrial Light and Magic in 2012, used in feature films and real-time experiences since Star Wars: The Force Awakens and Millennium Falcon: Smugglers Run, released as open source in 2017, then developed with contributions from Sony Pictures Imageworks, Pixar, Autodesk, Adobe and SideFX, and hosted by the Academy Software Foundation as its seventh project in 2021. ## Three CMake switches decide what you build The build is CMake, and the quick start is short: install CMake, point it at the root of the library, and generate projects for your compiler. What you get is decided by three options. MATERIALX_BUILD_PYTHON adds the Python bindings. MATERIALX_BUILD_VIEWER builds the MaterialX Viewer. MATERIALX_BUILD_GRAPH_EDITOR builds the graph editor, which is the authoring tool for the networks themselves. If you are integrating rather than authoring, the first is the one you need and the other two are optional. The toolchain requirements are stated precisely: C++17 support is required, with Visual Studio 2017 or newer, GCC 8 or newer, or Clang 5 or newer, and the Python bindings are built on PyBind11 and support Python 3.9 and later. Those floors are conservative in the useful direction, which means the library still builds on a five-year-old workstation, and the Python floor matches what pyproject declares. If you need something newer in the standard library, the C++ side is the constraint. ## Prebuilt packages name their exact toolchains Before you install a compiler, there is a zip per platform on the latest release, and the naming is the useful part because it tells you what these binaries were built with. The Windows package is Visual Studio 2022 on x64 with Python 3.13, the macOS package is Xcode 16 with Python 3.13, and the Linux package is GCC 14 with Python 3.13: ```bash https://github.com/AcademySoftwareFoundation/MaterialX/releases/latest/download/MaterialX_Linux_GCC_14_Python313.zip ``` All three contain the MaterialX viewer, the Python libraries and the example assets, which means the shortest possible evaluation is to unzip one and run the viewer. The specific versions also tell you what to expect from the release pipeline: three maintained platform configurations, each pinned to a current toolchain, rebuilt per release rather than shipped once. If your production build is on an older compiler than those, you are compiling from source against the documented floor, and the prebuilt package is for evaluation rather than deployment. ## The viewer works by generating GLSL from a graph The MaterialX Viewer is the smallest honest demonstration of what the library does, and the README says how it works: it leverages shader generation to build GLSL shaders from MaterialX graphs and renders the results with the NanoGUI framework. That is the whole mechanism of the project in one sentence. A graph of nodes is a platform-independent description; a renderer needs a shader; the translation between them is the code. The figures in the README are grouped in a way that shows the range the standard covers, with procedural and uniform materials on one row, including marble, copper, plastic and carpaint, and textured, color-space-managed materials on another, including tiled brass and tiled wood. Colour space management appearing in the standard's own reference images tells you the exchange format carries colour metadata rather than leaving it to each application. The Graph Editor is the authoring counterpart, and between them they are why the format has survived a decade of renderer changes. ## Eight console scripts are the API most users will touch pyproject declares eight entry points, and reading their names is the fastest way to understand what the project expects you to automate. mxvalidate validates MaterialX documents, which is the one to put in continuous integration before anything else. generateshader and translateshader go in opposite directions, turning a graph into a shader and taking an existing shader back into a graph, which is the migration path for a studio with an existing shader library. genmdl generates the MaterialX Description Language representation. writenodegraphs writes out the node graphs, which is what you use to produce the diagrams in documentation. baketextures backs up the textures a document references. mxdoc generates documentation and mxupdate updates content. The Python package itself is where the rest of the work happens, with standalone examples in the python/Scripts folder and a separate javascript folder for building JavaScript bindings. Two of those scripts, generateshader and translateshader, are the reason a studio can adopt this incrementally rather than all at once. ## The Python build pins a backend for an experimental feature The packaging is scikit-build-core with a fixed version, and the comment explaining why is unusually candid. The build system requires scikit-build-core at 0.10.7 or later, and the note says a fixed version is used because the project relies on an experimental feature, a custom plugin, and that functionality currently carries no compatibility promises. Two other details in the same file are worth knowing. The wheel configuration specifies the package location manually, with a comment explaining that the Python package does not live in a standard source directory like src or the root, and the minimum CMake version is read from CMakeLists.txt rather than repeated, so the C++ and Python build requirements cannot drift apart. The build type is Release with verbose output off and debug logging on. Read together, this is a project that has solved a real packaging problem and is candid that its solution rides on an unstable feature of its build backend, which is the kind of thing to check when you next upgrade the toolchain. ## Apache-2.0, foundation governance, and releases twice a year The licence is Apache-2.0, which for a library meant to be embedded in commercial renderers and DCC tools is the decisive practical fact, since there is no copyleft obligation on a tool that links it. The project sits under the Academy Software Foundation, and the repository carries the files that show what that means in practice: GOVERNANCE.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, THIRD-PARTY.md and a CHANGELOG.md, alongside a .clang-format and a .gitmodules for the parts that arrive from elsewhere. The release cadence is slower than a typical library's, with 1.39.3 on 2025-03-07, 1.39.4 on 2025-09-15 and 1.39.5 on 2026-05-22, and the last push to main on 2026-09-28. For a standard that means a long-lived, stable format with periodic additions, which is what a studio wants and what a product team should plan around. The project also points to the Developer Guide for API documentation and to the ASWF Open Source Days material and the SIGGRAPH physically based rendering course for the roadmap. ## Against USD, and against a format that only your renderer reads The other interchange standard in the same ecosystem is USD, Pixar's scene description, and the two solve different problems at different altitudes. USD describes a whole scene, geometry, hierarchy, references and variants, so it is the right tool for moving a shot between applications. MaterialX describes the shading network itself, the nodes, the parameters and the textures that make a surface, and it is the right tool for moving a look between renderers. A studio normally needs both, and the boundary between them is where a pipeline gets interesting. The other realistic option is to keep an in-house material format pinned to one renderer and translate at export, which is cheaper to start and quietly expensive later, because every renderer change and every new node type becomes your problem. The reason MaterialX survives that comparison is the reference assets and the conformance tooling: a format nobody can validate is a format nobody trusts, and mxvalidate is the tool that makes a shared library workable across a team. ## Conclusion Adopt MaterialX if you hand materials between applications, ship look development to a client, or support more than one renderer, because the same source graph can target several of them and the project publishes a prebuilt binary per platform to get you there in minutes. Do not adopt it to store scene geometry, which is USD's job, or to replace a proprietary pipeline that already round-trips cleanly. Verify four things before you commit a production asset library: that mxvalidate passes on your documents in CI, since that is the check the standard's conformance rests on, that the shading model your studio uses, Standard Surface in the reference asset, maps onto the nodes you rely on rather than forcing a rewrite, that the build backend version you inherit still works, because pyproject pins scikit-build-core for an experimental feature with no compatibility promises, and which release you standardise on, given 1.39.3 from 2025-03-07, 1.39.4 from 2025-09-15 and 1.39.5 from 2026-05-22, with the last push on 2026-09-28. ## FAQ ### What is MaterialX used for? It is an open standard for representing rich material and look-development content so that it can be exchanged between applications and renderers in a platform-independent way. The Open Chess Set reference asset is shipped as a .mtlx file in the Standard Surface shading model plus a glTF geometry file, and is shown rendered in both Arnold for Maya and Karma XPU for Houdini. ### What do I need to build MaterialX? CMake, a compiler with C++17 support, meaning Visual Studio 2017 or newer, GCC 8 or newer, or Clang 5 or newer, and Python 3.9 or later if you want the bindings, which are based on PyBind11. Prebuilt packages for Windows, macOS and Linux are published with each release. ### Which MaterialX CMake options should I turn on? MATERIALX_BUILD_PYTHON builds the Python bindings, MATERIALX_BUILD_VIEWER builds the viewer that generates GLSL from MaterialX graphs and renders with NanoGUI, and MATERIALX_BUILD_GRAPH_EDITOR builds the authoring tool for those graphs. ### What console commands does the MaterialX Python package install? Eight: baketextures, generateshader, genmdl, mxdoc, mxupdate, mxvalidate, translateshader and writenodegraphs. mxvalidate checks documents, generateshader and translateshader convert in both directions between graphs and shaders, and writenodegraphs produces the diagrams used in documentation. ### Which organisations are behind MaterialX? It was launched at Industrial Light and Magic in 2012, released as open source in 2017 with contributions from Sony Pictures Imageworks, Pixar, Autodesk, Adobe and SideFX, and became the seventh hosted project of the Academy Software Foundation in 2021. The licence is Apache-2.0. ## Sources - [AcademySoftwareFoundation/MaterialX on GitHub](https://github.com/AcademySoftwareFoundation/MaterialX) - [License: Apache-2.0](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/LICENSE) - [Project website](http://www.materialx.org/) - [README](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/README.md) - [Releases](https://github.com/AcademySoftwareFoundation/MaterialX/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/academysoftwarefoundation-materialx