Lucasfilm is developing a new open source material standard called MaterialX, in partnership with The Foundry and Autodesk. Its aim is to improve the efficiency of look development between various content creation tools.
One of the big advantages of MaterialX is that it describes materials and looks in a way that’s independent of the tools used to create them, using a standard node graph that can be re-created in any application, or archived for use in future applications. Depending on how much custom functionality you’re using in a given look, there may be some content that needs to be baked out or approximated in the target application, but for many types of material content it’s possible to reconstruct the original look exactly. This is especially true if you’re using standard, physically based shaders across tools and renderers, which is becoming more common across the industry, and is the approach we use at Lucasfilm.
MaterialX already has a specification published online and has been used on Star Wars: The Force Awakens and Rogue One with the aim of releasing its open source codebase too. MaterialX is currently the primary material format at Lucasfilm and an “integral part of the production workflows.” One area where MaterialX is especially central is in the Mari look development framework, where it represents the materials and material fragments that artists paint with and transfer between projects. There are also basic MaterialX workflows to connect tools such as Maya and Katana, and MaterialX is used to transfer material content to real-time renderers for ILMxLAB experiences such as Trials on Tatooine.
Doug Smythe, a CG supervisor at Industrial Light & Magic, and co-creator of MaterialX with Jonathan Stone from the Lucasfilm Advanced Development Group, spoke to 3D Artist to tell us a bit more about the standard.
Could you explain what MaterialX is?
MaterialX is an open standard and interchange format for transferring CG materials between content creation tools and renderers. The idea is that if you have created an asset and done the lookdev in one package, it’s currently really difficult to get that into any other package. If you’re either sharing an asset with another studio – everything in the VFX world is cross-studio it seems like – or if you have multiple tools in your own studio (like both Maya and 3ds Max, for example) and you want to transfer your asset looks from one package into another, MaterialX is a hub format that you can use for that interchange.
And what does it offer studios?
One of the big advantages of MaterialX is that it describes materials and looks in a way that’s independent of the tools used to create them, using a standard node graph that can be recreated in any application, or archived for use in future applications. Depending on how much custom functionality you’re using in a given look, there may be some content that needs to be baked out or approximated in the target application, but for many types of material content it’s possible to reconstruct the original look exactly. This is especially true if you’re using standard, physically based shaders across tools and renderers, which is becoming more common across the industry, and is the approach we use at Lucasfilm.
Where did the idea come from?
The earliest ideas on MaterialX actually came from a show that I supervised. It was the first Iron Man movie and we needed to send the look of our hero Iron Man Mark III to another studio. At the time, the only thing we could do was generate a text file that had the mappings from – you know this geometry had this texture on it, and it had these texture coordinates – and we could make a guide map for it. It was all very hand-wavy and we could send them renders of what the final look like, and even some of the diffuse and the specular channels of what those look like. But the other studios really had to do a lot of work to try and match our look, and they were never able to get 100 per cent there for many reasons – not the least of which time. But it sort of underscored the need that this was going to come up more and more often, and it’s hard work to do. It takes away time from even the company that created the original look because now you have to spend a lot of time talking through someone what you did so it’s inefficient on both sides.
Pixar’s Universal Scene Descriptor (USD) went open source this year too. How does MaterialX differ from USD?
Pixar’s USD is another great industry standard, but it’s more focused on scene layering and composition, and it doesn’t provide a mechanism for representing materials and looks in a universal way. We’ve been in close contact with the USD team for quite a while, and we’re both interested in making these two standards work well together, so that USD scene layering can be applied to MaterialX content. We haven’t yet announced a strategy for this integration, but it’s something that both of our teams believe is important for the future.
Is that one of the reasons why MaterialX is going open source then, so that it can work with other tech like USD?
That’s certainly one of the benefits, that MaterialX can be integrated with projects like USD, and we can create alignment between different standards across the industry. Additionally, though, it allows other studios to take MaterialX and extend it to new domains that we haven’t thought of. We had a lot of success with open sourcing Alembic and OpenEXR, and it led to really great improvements coming from other parts of the community, beyond what we could have developed on our own at Lucasfilm. Teams and studios can use as much or as little as they want, and they’re free to contribute their ideas back to the project. There is a lot of excitement around MaterialX right now as well, and I think that will help the project move forward more quickly.
MaterialX is being used on The Force Awakens. Are there any other studios using the standard at the moment?
So far, it’s mostly being used within the Lucasfilm family of companies, including ILM and ILMxLAB, along with a few studios with which we share material assets. As we announced on our website, we’re currently partnering with Autodesk and The Foundry, and we’re collaborating with a number of other studios and vendors that have expressed interest in helping out with the open-source project, though we’re not yet ready to announce any public partnerships beyond those two.
There’s a partnership with The Foundry and Autodesk. How did that came about? Did they just hear about it, got excited and got in touch?
Yeah basically. Those are the companies that we’ve done a lot of work with in the past, they’re among our preferred tool providers so [we’ve been] in conversation with those teams for quite a while. When we are working on something cool, if it makes sense to share it with them we will. That happened with both Autodesk and The Foundry, and in Autodesk’s case MaterialX was aligning quite a bit with one of their initiatives that they were working on internally so instead of developing on two similar, incompatible standards let’s work together… So Autodesk was very closely aligned with one of their internal initiatives, and our teams saw a great opportunity to work together on a single standard. We’ve been working with them very closely since then, and Autodesk has contributed some great ideas that we’ve incorporated into MaterialX.
What’s next for MaterialX? Will we see the release of the open source codebase?
Lucasfilm is working hard on an open-source release, with some great input from Autodesk, The Foundry, and other developers, but we haven’t yet announced a release date. Before our presentation at SIGGRAPH this year, the MaterialX codebase was focused on supporting specific production workflows at Lucasfilm, and we’re now generalizing that code to handle a broader set of use cases. There’s still a good deal of work to be done, but we’re interested in getting the code in the hands of developers as soon as possible.
[Update] Since this interview, MaterialX was made open source in July 2017 with a GitHub repository here. It has also been announced that a Pixar and Lucasfilm are working together on making USD and MaterialX fully compatible.