[X3D-Ecosystem] Maya, OpenUSD, Material X, and X3D

[Bergstrom, Aaron]

Michalis,

I appreciate your thoughts about MaterialX.

Spent a good chunk of time last evening writing functions to get Maya to write MaterialX XML files to disk (*.mtlx). Even though it is super easy to do via the Maya GUI, it’s not so easy to do programmatically once the export has been kicked off.

But I figured it out.

In Maya, MaterialX works with other Maya supported shaders to embed them in a MaterialXSurfaceShader node. The whole MaterialX implementation within Maya is heavily tied to how Autodesk implements OpenUSD in Maya.

As a guy writing the export, and not writing Browsers/Viewers, there would be no reason why I couldn’t offer the option to export the MaterialXSurfaceShader either as a ComposedShader or a PackagedShader, or both.

When it comes to a PackagedShader, I could set the “language” field to “MTLX”, and put a url or a dataURI to the MaterialX file in the “url” field and call it good. I suppose I could pre-parse the MaterialX at export time and add the appropriate “field” tags as well.

Adding the fields would allow for routing to different parts of the shader, and I suppose it is technically necessary for PackagedShader nodes to properly interpret the MTLX info.

Anyway, I’d  just leave it up to the browser developers how they want to handle an MTLX PackagedShader node.

I’m not entirely sure how the Appearance.shaders field works… I’m assuming that a browser would chose the shader in the shaders field that it likes the best?

If that’s how it works, I suppose I could add an MTLX PackagedShader and a ComposedShader (generated by the MTLX info) to that field, and the browser could just pick which one it would want to use.

I’d probably need some guidance from X_ITE and CGE developers on how to interpret MTLX info as field tags for both the ComposedShader and the PackagedShader.

Of course, I’d like to support X3DOM as well, that’s kind of a different beast as from what I can tell it’s Material and Shader support uses a pre-4.0 methodology.

If everything I just said sounds ridiculous and/or wrong, please correct me.

Aaron

From: Michalis Kamburelis <michalis at castle-engine.io>
Sent: Thursday, February 19, 2026 10:19 AM
To: X3D Ecosystem public discussion <x3d-ecosystem at web3d.org>
Cc: Bergstrom, Aaron <aaron.bergstrom at und.edu>
Subject: Re: [X3D-Ecosystem] Maya, OpenUSD, Material X, and X3D

I would be happy to have MaterialX support in X3D. Though admittedly, I recommend a bit different approach: give MaterialX input to the X3D browsers.

Reasons and details:


  *   Generating complete GLSL code of a shader, which ComposedShader requires, unfortunately has drawbacks. Every browser has a bit different way of how data to shaders are provided (how uniforms are laid out, and it may also depend on platform, on browser version; and we do have good reasons why every browser invents different uniforms ! browsers implement+optimize things  differently on GPU). Moreover, you have to then reimplement _everything_ in a ComposedShader. E.g. however browser does shadows, or GPU skinning, or fog -- your shader will need to do _everything_, because ComposedShader replaces the browser shaders. This gets even more complicated because of small differences in GLSL and what needs to be done between OpenGL / OpenGLES / WebGL / Vulkan etc. (not to mention rendering engines that don't use GLSL).


  *   Our "Effect" node in CGE is one way to address it, see https://castle-engine.io/shaders and links from it. It allows to write GLSL code that enhances browser built-in shaders, rather than replacing them. However, that's a complicated extension, right now only in CGE and FreeWRL.


  *   My recommendation: if you have shaders in MaterialX, then give MaterialX to the X3D browser. Rendering engine, like Castle Game Engine or anything else, can then convert the MaterialX in an optimal way to the final shader. This implies more work on the browser side (processing of MaterialX -> to whatever we need), less on the exporter side, and we can have optimal shading if the browser (aka "rendering engine") will control the conversion MaterialX -> shaders.

     *   I'm not sure how to do this exactly. Maybe "PackagedShader" node with language="MaterialX"? And then PackagedShader.url would point to MaterialX input.

Naturally, all these options can also be explored in parallel :) "shaders" is MFNode, you can provide multiple shaders versions, trying to account for various browsers, and also provide MaterialX version as an alternative.

Regards,
Michalis


On Wednesday, February 18th, 2026 at 07:42, Bergstrom, Aaron via X3D-Ecosystem <x3d-ecosystem at web3d.org<mailto:x3d-ecosystem at web3d.org>> wrote:

All,

I went off on a tangent today after attending the AOUSD web working group, when I realized that it’s probably possible for RawKee to fully support MaterialX shading/material export to X3D.

Maya 2026 has something called the LookdevX Graph Editor (I think it’s actually been in Maya since Maya 2024).

This is essentially a new shading network editor designed by Autodesk to eventually replace the Hypershade editor, and their new preferred method setting up high quality shading networks for meshes/models in Maya so that it can fully support OpenUSD and Material X in the future.

Based on what I’ve been reviewing today, I fully expect Maya artists to migrate away from the old way of setting up Materials, and move fully toward LookdevX/MaterialX methods of shading their models in the future.

Material X is primarily a portable XML schema for defining the inputs to shading languages. There are converters/loaders (whatever you want to call them) for every shading language.

The intent is that you write out your shader using Material X, and whatever shader language and renderer that you are using, your shading network should render the same.

However, Material X is not just an XML schema, it’s an ecosystem that includes a bunch of python libraries, and those libraries are now packaged with Maya 2026.

A Maya content developer can create complex shading networks using the LookdevX Graph Editor, and then export them as GLSL (or any of your other favorite shading languages) using these MaterialX python libraries.

The process is actually quite simple.

As such, in addition to the robust PhysicalMaterial support that I’ve been working on lately, it appears that it really should be no problem to export complex shading networks from Maya as X3D ComposedShader nodes using the MaterialX methodology.

This will take some additional work to implement, but I think it’ll definitely be worth it, and something to show off at Siggraph this year.

Aaron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-ecosystem_web3d.org/attachments/20260219/7fb6a399/attachment-0001.html>