[X3D-Ecosystem] Maya, OpenUSD, Material X, and X3D
Michalis Kamburelis
michalis at castle-engine.io
Thu Feb 19 08:19:16 PST 2026
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> 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/bce38e16/attachment.html>
More information about the X3D-Ecosystem
mailing list