[X3D-Ecosystem] Question for X3D Browser Developers

[John Carlson]

I think that things might be more uniform structure-wise if GLSL model,
view, a d projection matrices are concerned.  What I’m concerned with is
the uniforms I don’t control with fields.

That might be a first attempt, I would appreciate feedback on non-MaterialX
uniforms.

Thanks!

John



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

>
>    1. To be clear, I second the idea to look at
>    https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/DeveloperGuide/ShaderGeneration.md#162-variable-naming-convention by
>    X3D browser implementors :) This proposes a standardized names for uniforms
>    / attributes to pass to shaders for MaterialX. I am enthusiastic that our
>    renderer (Castle Game Engine) could have an "alternative path" and
>    generate uniforms / attributes this way, and thus support MaterialX
>    within X3D. See https://castle-engine.io/roadmap#material_x for my
>    plans how I want to do this.
>
>
>
>    2. However, I have to also point out some "bad news". It's
>       1. not as easy as using GLSL macros to normalize the names. I
>       explain it below.
>       2. and it's not a solution for everything. MaterialX only
>       standardizes things it cares about for its use-case, see below; this is a
>       not solution to solve X3D browser incompatibilities in what uniforms /
>       attributes we accept, and I don't even think its possible to solve it --
>       browsers need special way to implement and optimize stuff on GPU, like
>       shadows and skinned animation.
>
>
> Details:
>
> IMO using #define , to "normalize" the GLSL incompatibilities between
> browsers using GLSL macros, is not going to work. It will definitely not
> work for Castle Game Engine -- the list you ask about is just impossible to
> provide from my side, as CGE author. I could only provide a very incomplete
> and thus useless version (since even i_position vs castle_Vertex has
> different type, see below).
>
> The reason is that not only the names of uniforms all renderers (including
> all X3D browsers) use is different. Also our types, and expected usage, are
> different. Everyone is passing data in different structures (and often for
> good reasons - we have different set of features, different subset of
> platforms we want to support, different optimizations we have). E.g.
>
>    - Light data, in "u_lightData" ( from
>    https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/DeveloperGuide/ShaderGeneration.md#162-variable-naming-convention )
>    is not something that any browser will have out of the box. We pass it in
>    CGE without structures, using a combination of uniforms and #define
>    conditionals, to make light computation as optimized as possible.
>    - Even simple things are incompatible. E.g. CGE has "castle_Vertex",
>    which is almost like "i_position" that MaterialX defines... but our
>    castle_Vertex are 4D (passed in homogeneous coordinates, for good reasons
>    -- we render also shadow quads for shadow volumes). While "i_position" is
>    3D. So even providing a simple rename for this most basic thing is
>    impossible. Again, for good reasons. We can have "alternative MaterialX
>    naming" in CGE, but you cannot just rename "castle_Vertex ->
>    i_position". We need our internal shaders to handle shadow quads for shadow
>    volumes.
>    - CGE doesn't pass i_bitangent as an attribute, we pass only tangent
>    (and we calculate bitangent in GLSL code).
>    - CGE provides texture coordinates using various types - vec2, vec3,
>    vec4, depending on the definition. (And for computed texture coords, in a
>    different way.) So "i_texcoord_N" as "just vec2" as defined by
>    MaterialX is not possible. MaterialX doesn't account for non-2D and/or
>    computed textures.
>    - Stuff like u_worldMatrix , u_worldInverseMatrix, u_viewMatrix etc. -
>    we have this information, passed under certain conditions. For MaterialX,
>    we would just pass it always, if shader linking stage shows we have this
>    uniform. But that's not something we do by default for internal shaders, as
>    there's no need for it.
>    - The list goes on. For pretty much variable on the
>    https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/DeveloperGuide/ShaderGeneration.md#162-variable-naming-convention
>     list:
>       - A. it is _obvious how to implement support for it_
>       - but also B. we _do not have a direct trivial equivalent for it
>       right now_. Not something you can have just renaming castle_Xxx -> into
>       standardized MaterialX name.
>    -
>
> To be clear, I think the list of MaterialX is great, and I want to have
> CGE option to "generate uniforms / attributes following this convention".
> As we talked yesterday, as I documented on
> https://castle-engine.io/roadmap#material_x . I would encourage other
> browser developers to look into this too -- to have an _option_ for this.
>
> But:
>
>    - You cannot achieve this by simple rename. The generation of
>    MaterialX-compatible names requires cooperation from the rendering code
>    (like Pascal code, in case of CGE; JavaScript code in case of X_ITE/X3DOM
>    etc.). You cannot just get it by renaming the uniforms/attributes generated
>    now.
>    - Remember this is not a panacea for all shader incompatibilities:)
>       - Material parameters (like uniform names for color, roughness
>       etc.) are not standardized. Which is correct for the MaterialX use-case --
>       MaterialX consumes the material parameters, so when you export it, you can
>       set both the material parameter names (in ComposedShader, PackagedShader)
>       and consume them (in shader code, in MarerialX XML or in GLSL).
>       - There are still unsolved things. E.g. when using ComposedShader with
>       GLSL generated -- we cannot have shadow map receiving, or skinned animation
>       on GPU, since this requires both information (uniforms) and shader code
>       which our internal shaders have, but your generated ones will not.
>
>
> Regards,
> Michalis
>
>
>
> On Thursday, February 26th, 2026 at 16:59, Bergstrom, Aaron via
> X3D-Ecosystem <x3d-ecosystem at web3d.org> wrote:
>
> X3D Browser Devs,
>
>
>
> So all… please correct me if you think I’ve over simplified what I’ve
> written below.
>
>
>
> Based on my conversation with Michalis, the existing X3D browsers
> (FreeWRL, X3DOM, X_ITE, and CGE) all have different shader naming
> conventions for their GLSL uniform, in, and out variables.
>
>
>
> Any particular browser’s naming convention may, or may not, match the list
> of MaterialX shader variable naming conventions found at the url below:
>
>
> https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/DeveloperGuide/ShaderGeneration.md
>
>
>
> However, based on my reading, it seems to me that I can inject the proper
> naming conventions into the *.frag and *.vert files as a  ‘#define’ alias
> before writing the files to disk.
>
>
>
> Then I could add your browser’s aliases to the field names of the exported
> X3D shader node.
>
>
>
> An injected alias would look something like this (just a random example of
> a GLSL shader alias):
>
>     #define vd_tangentWorld vd.tangentWorld
>
>     #define vd_normalWorld vd.normalWorld
>
>
>
> I would ask that each browser vendor provide me with a list of the naming
> conventions for their browser shader’s naming conventions that match up
> with the MaterialX naming conventions found at the link above.
>
>
>
> If I have that list, I can just add those alias’ to the GLSL file before
> writing it to disk, and write out a version of the X3D shader that matches
> your browser’s naming conventions.
>
>
>
> I just need the alias list for your browser and we should be good to go
> for supporting MaterialX shader export from Maya.
>
>
>
> 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/20260226/f9d2af19/attachment.html>