[X3D-Ecosystem] Question for X3D Browser Developers

Thu Feb 26 16:16:21 PST 2026

- 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.

- However, I have to also point out some "bad news". It's

- not as easy as using GLSL macros to normalize the names. I explain it below.
- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-ecosystem_web3d.org/attachments/20260227/b14ed63a/attachment-0001.html>