<div dir="ltr">I agree totally with Michalis on this!<div><br></div><div>John</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Feb 19, 2026 at 3:26 PM Michalis Kamburelis via X3D-Ecosystem <<a href="mailto:x3d-ecosystem@web3d.org">x3d-ecosystem@web3d.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:Arial,sans-serif;font-size:14px">Indeed you can put on "Appearance.shaders" multiple shaders, so indeed you can explore all the options, that's cool.</div><div style="font-family:Arial,sans-serif;font-size:14px"><br></div><div style="font-family:Arial,sans-serif;font-size:14px">The shaders there should be "<span>in order of preference</span>" ( <span><a rel="noreferrer nofollow noopener" href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/shape.html#Appearance" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/shape.html#Appearance</a></span> ). 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</div><div style="font-family:Arial,sans-serif;font-size:14px"><br></div><div style="font-family:Arial,sans-serif;font-size:14px"><ul style="margin-top:0px;margin-bottom:0px"><li style="list-style-type:"- ""><span>first place the shader (PackagedShader?) with MaterialX source</span></li><li style="list-style-type:"- ""><span>then shaders for GLSL (ComposedShader).</span></li></ul><div><br></div><div>I wholly support you generating the <span>GLSL (ComposedShader)</span> 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 <span>ComposedShader</span>. 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 (<span>like shadows or GPU skinning</span>).</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Michalis</div></div>
<div style="font-family:Arial,sans-serif;font-size:14px">
<div>
</div>
<div>
</div>
</div>
<div style="font-family:Arial,sans-serif;font-size:14px"><br></div><div>
On Thursday, February 19th, 2026 at 17:57, Bergstrom, Aaron <<a href="mailto:aaron.bergstrom@und.edu" target="_blank">aaron.bergstrom@und.edu</a>> wrote:<br>
<blockquote type="cite">
<div>
<p class="MsoNormal">Michalis,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I appreciate your thoughts about MaterialX.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">But I figured it out.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Anyway, I’d just leave it up to the browser developers how they want to handle an MTLX PackagedShader node.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">If everything I just said sounds ridiculous and/or wrong, please correct me.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Aaron</p>
<p class="MsoNormal"> </p>
<blockquote type="cite"><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Michalis Kamburelis <<a href="mailto:michalis@castle-engine.io" target="_blank">michalis@castle-engine.io</a>>
<br>
<b>Sent:</b> Thursday, February 19, 2026 10:19 AM<br>
<b>To:</b> X3D Ecosystem public discussion <<a href="mailto:x3d-ecosystem@web3d.org" target="_blank">x3d-ecosystem@web3d.org</a>><br>
<b>Cc:</b> Bergstrom, Aaron <<a href="mailto:aaron.bergstrom@und.edu" target="_blank">aaron.bergstrom@und.edu</a>><br>
<b>Subject:</b> Re: [X3D-Ecosystem] Maya, OpenUSD, Material X, and X3D</p>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">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. </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">Reasons and details:</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="list-style-type:"- "">
<span style="font-size:10.5pt;font-family:Arial,sans-serif">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).</span></li></ul>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="list-style-type:"- "">
<span style="font-size:10.5pt;font-family:Arial,sans-serif">Our "Effect" node in CGE is one way to address it, see <a href="https://castle-engine.io/shaders" rel="noreferrer nofollow noopener" target="_blank">https://castle-engine.io/shaders</a> 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.</span></li></ul>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="list-style-type:"- "">
<span style="font-size:10.5pt;font-family:Arial,sans-serif">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.</span></li></ul>
<ul type="disc">
<ul type="circle">
<li class="MsoNormal">
<span style="font-size:10.5pt;font-family:Arial,sans-serif">I'm not sure how to do this exactly. Maybe "PackagedShader" node with language="MaterialX"? And then PackagedShader.url would point to MaterialX input.</span></li></ul>
</ul>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">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.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">Regards,</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">Michalis</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">On Wednesday, February 18th, 2026 at 07:42, Bergstrom, Aaron via X3D-Ecosystem <<a href="mailto:x3d-ecosystem@web3d.org" rel="noreferrer nofollow noopener" target="_blank">x3d-ecosystem@web3d.org</a>> wrote:<br>
<br>
</span></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">All,</span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">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.</span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">Maya 2026 has something called the LookdevX Graph Editor (I think it’s actually been in Maya since Maya 2024).</span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">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.</span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">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.</span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">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.</span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">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.</span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">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.</span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">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.</span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">The process is actually quite simple.</span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">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.</span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">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.</span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif">Aaron</span></p>
</div>
</blockquote>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif"> </span></p>
</div>
</div>
</blockquote></div>
</blockquote><br>
</div>-- <br>
X3D-Ecosystem mailing list<br>
<a href="mailto:X3D-Ecosystem@web3d.org" target="_blank">X3D-Ecosystem@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-ecosystem_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-ecosystem_web3d.org</a><br>
</blockquote></div>