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

[John Carlson]

I agree totally with Michalis on this!

John

On Thu, Feb 19, 2026 at 3:26 PM Michalis Kamburelis via X3D-Ecosystem <
x3d-ecosystem at web3d.org> wrote:

> Indeed you can put on "Appearance.shaders" multiple shaders, so indeed you
> can explore all the options, that's cool.
>
> The shaders there should be "in order of preference" (
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/shape.html#Appearance ).
> Which means that, while some browsers may analyze the list and "pick the
> one they like best", in general browsers will just "pick the first one that
> seems to work". So you should first place the versions that are "harder to
> support, but closer to truth", and further on the list "easier to support,
> but potentially not so true". So
>
>
>    - first place the shader (PackagedShader?) with MaterialX source
>    - then shaders for GLSL (ComposedShader).
>
>
> I wholly support you generating the GLSL (ComposedShader) versions, I'm
> just warning: you will have trouble getting a shader that actually works in
> all browsers even on desktops (due to uniform name differences). It will be
> even harder/impossible to generate shaders that e.g. include
> browser-internal things like shadows and skinning -- since your GLSL code
> will have to do reinvent them all, that's a trouble with shader approach
> like ComposedShader. So you will likely end up with per-browser GLSL
> versions (e.g. X_ITE shader, CGE shader, X3DOM shader, FreeWRL shader...)
> that achieve some functionality  but also miss some (like shadows or GPU
> skinning).
>
> If you're ready for this task, then by all means go for it, amazing :) And
> if you provide a MaterialX source as first on "Appearance.shaders", then
> browsers can always use that version to generate "a perfect shader"
> integrated with our rendering needs, so we can have the best situation from
> both sides.
>
> Regards,
> Michalis
>
> On Thursday, February 19th, 2026 at 17:57, Bergstrom, Aaron <
> aaron.bergstrom at und.edu> wrote:
>
> 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> 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
>
>
>
>
> --
> X3D-Ecosystem mailing list
> X3D-Ecosystem at web3d.org
> http://web3d.org/mailman/listinfo/x3d-ecosystem_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-ecosystem_web3d.org/attachments/20260219/4c215f12/attachment-0001.html>