[x3d-public] BlendMode
Michalis Kamburelis
michalis.kambi at gmail.com
Sun Jan 12 14:05:27 PST 2025
( I'm changing the subject, because the original topic "X3D Standards
Working Group list of standards under revision" got busy with multiple
subthreads. )
This is in particular to Don and Vincent,
I think there was a mistake in recent communication --- I understand
that Don asked for "functional description" of the BlendMode, and how
it connects to glTF and Blender. I'm afraid Vincent answer about
Color/ColorRGBA is *unrelated* to what the BlendMode node is doing.
I completely understand why this mistake happened, because in both
cases one could use the English word "blending" (though it means a
different operation in a different context). And we also talked with
Vincent about Color/ColorRGBA recently. And I see that if one searches
glTF spec ( https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html
) for the word "blending", one can find both these meanings of the
word "blending" used...
To clear things up, these 2 things are *absolutely unrelated tasks*,
though both deserve consideration for future X3D version:
1. First, *unrelated to BlendMode*, and this is what Vincent described:
It would be nice to add functionality to per-vertex colors (from
Color, ColorRGBA nodes) to multiply material colors, not replace them.
Why?
- IMHO, because multiplication is more useful in various practical
cases. Current X3D spec says that colors from Color/ColorRGBA should
*replace* relevant material color (like Material.diffuseColor /
PhysicalMaterial.baseColor / UnlitMaterial.emissiveColor), but it
would be just more useful to allow to multiply them, and say that
Color/ColorRGBA multiplies effective Material.diffuseColor / etc. This
way you could use e.g. Color to express "ambient occlusion" (some
parts of object are darker), and use Material.diffuseColor to give a
"general color tint" (like reddish) to your object. I often find 3D
objects using this technique in Blender and glTF.
- glTF specification says that per-vertex colors multiply, not
replace. So I guess glTF authors agree that multiplication is useful.
- In Blender nodes you can express various things (both "multiply
and "replace"). It would be nice to support both.
To address this, I propose a (backward-compatible) field "mode" to
Color/ColorRGBA that allows to specify should it replace or multiply.
Details on https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#per-vertex-colors
.
2. Now, BlendMode is something completely unrelated to point 1:
BlendMode node determines what happens at a different moment of rendering.
The real-time 3D rendering APIs (like OpenGL) have a way to render
partially transparent objects (like "blueish glass") in a particular
way: the software first renders opaque objects, and then it renders
partially transparent objects "on top" of the opaque objects.
Rendering the partially transparent objects is done when "blending"
mode is active, which means that incoming color (like blue from
"blueish glass" example) is mixed with the screen color (like color of
the thing that was behind the glass).
( Forget for a second about the problem "what should be the
rendering order". It is indeed something to take care of, because
Z-buffer works for opaque objects, and you need to sort
partially-transparent objects, and this sorting is never perfect for
non-convex meshes. Forget about it here. Assume you have good order
for each screen pixel. )
Now, when rendering a partially-transparent object over something
underneath, the color of the partially-transparent is mixed with the
existing screen color. How is it mixed?
- The standard operation is to do
new_screen_color :=
old_screen_color * (1 - object_opacity)
object_rgb_color * object_opacity
This is effectively a lerp (linear interpolation) between
screen color and incoming color, using new object's opacity (aka
"alpha", aka "1 - transparency") as a factor.
Is this correct? Not fully, but there is no *fully correct*
equation. What we do is a poor approximation of how "partially
transparent" objects work in reality. There's no equation that will be
"fully correct".
But it does the job, most of the time. A thin (very transparent
glass) would have transparency=0.9, so opacity=alpha=0.1. So the
equation implies that color behind the glass mostly stays visible (it
is only multiplied by 0.9) and the color of the glass mostly doesn't
disappears (it is multiplied by 0.1).
In contrast,a "thick" glass could have transparency=0.1, so
opacity=alpha=0.1. Follow the equation to see what happens -- just
like it should in reality, color of the glass will now be prominent,
and the thing behind will almost become invisible.
Is this problematic? Sometimes. It requires the
partially-transparent objects to be sorted. (because imagine what
happens when the object is seen through multiple layers of
differently-colored glass.)
Is this standard? Yes.
- BlendMode is X3D allows to configure this equation. All the
BlendMode modes directly correspond to the glBlendFunc parameters of
OpenGL, https://registry.khronos.org/OpenGL-Refpages/gl4/html/glBlendFunc.xhtml
.
- How is this related to Blender exporter? It's not. Blender
doesn't allow to specify things like that. And realistic Blender
renderer doesn't do partial transparency this way, either. (But
real-time Blender renderer probably does, using standard equation
shown above.)
- How is this related to glTF? It's not. glTF doesn't allow to
configure this. All glTF real-time browsers I know use the standard
equation I shown above. The
https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html has rather
"we guarantee nothing" note: """BLEND - Support for this mode varies.
There is no perfect and fast solution that works for all cases. Client
implementations should try to achieve the correct blending output for
as many situations as possible. .... """
I hope this helps :)
Regards,
Michalis
niedz., 12 sty 2025 o 17:31 vmarchetti at kshell.com
<vmarchetti at kshell.com> napisał(a):
>
> Blending data to get a rendered appearance of a mesh has come up in the recent work toward Blender support of X3D. To address Don's question about references for blending, one reference is the section of glTF specification for physically based rendering, in particular for what glTF call "Metallic Roughness" material, see Section 3.9.2 fo the glTF 2.0 specification
> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#metallic-roughness-material
>
> The penultimate paragraph of section 3.9.2 specifies how a material base color is blended with color-per-vertex values:
> "In addition to the material properties, if a primitive specifies a vertex color using the attribute semantic property COLOR_0, then this value acts as an additional linear multiplier to base color."
>
> This form of blending is a problem for export to X3D from Blender, as X3D does not support this blending, rather in X3D color-per-vertex data in a ColorRGB or ColorRGBA node overrides color expressed in a Material or PhysicalMaterial node. This problem is relevant to converting a glTF file as generated through the QGIS (geographic information system) code to x3D using Blender.
>
> I think of the ladder of material and appearance complexity from simplest to most complex, as:
>
> 1. X3D Specification at v 3.3
> 2. X3D Specification at v 4.0, adds Physically based rendering but not blending
> 3. The extensions to X3D 4.0 that Michalis and Holger have implemented in their viewers, and are proposing for X3D 4.1
> 4. glTF specification 2.0 which support multiple blending methods (see Section 3.9.2)
> 5. Blender, which through the material node tree allows implementation of a wide variety of blending. Keep in mind though that Blender does not do 'real time' rendering, at least not on my computer.
>
> Corrections or extensions on my ladder from 1 to 5 are appreciated.
>
> Vince Marchetti
>
>
> On Jan 12, 2025, at 3:15 AM, Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> wrote:
>
> Thanks for multiple efforts and thoughtful posts.
>
> We certainly have more options for X3D extensibility than ever before, now that we've achieved the X3D 4.0 Architecture. It is also much easier for Web3D Consortium to consider recommendations for incremental improvements to our specifications.
>
> Some questions please:
>
> Looks like functional descriptions and technical references aren't listed? There must be something you are each referring to...
>
> Wondering what is the relationship to glTF?
>
> Wondering what is relationship and potential value for Blender export to X3D?
>
> (of possible relevance) Blender 4.2 LTS: EEVEE
> "Shading Modes. Material > Blend Mode was replaced by Material > Render Method. Blended corresponds to the former Alpha Blend. Material > Shadow Mode was replaced by Object > Visibility > Ray Visibility > Shadow at the object level.
> https://developer.blender.org/docs/release_notes/4.2/eevee
>
> all the best, Don
> --
> Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman
>
>
>
>
> ________________________________
> From: x3d-public <x3d-public-bounces at web3d.org> on behalf of Michalis Kamburelis via x3d-public <x3d-public at web3d.org>
> Sent: Saturday, January 11, 2025 9:42 AM
> To: Holger Seelig <holger.seelig at yahoo.de>
> Cc: Michalis Kamburelis <michalis.kambi at gmail.com>; X3D <x3d-public at web3d.org>; Web3D Consortium <consortium at web3d.org>; bod at web3d.org <bod at web3d.org>
> Subject: Re: [x3d-public] X3D Standards Working Group list of standards under revision
>
> As for BlendMode: Note that Castle Game Engine / Castle Model Viewer
> also support it:
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-engine.io%2Fx3d_extensions.php%23section_ext_blending&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749340649%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=938deY3k4NOMUuJw1eYJ1tZ59Hw0BPyYm903R%2BqrazA%3D&reserved=0 .
>
> I agree BlendMode is worth adding to the spec, but *not* with all the
> enums. The enums currently available match all OpenGL / OpenGLES /
> WebGL capabilities, but it implies a lot of possibilities and I think
> only a few are really practically useful for users. I would like to
> research what is supported in this regard by Vulkan, Direct3D, and
> choose a "common subset" for the spec.
>
> Of course particular browsers could still extend allowed options to enable more.
>
> Regards,
> Michalis
>
>
> pt., 10 sty 2025 o 16:53 Holger Seelig <holger.seelig at yahoo.de> napisał(a):
> >
> > As an additional proposal I would like to mention here BlendMode and DepthMode node as child of an Appearance node, which are more or less implemented the same in X3DOM and X_ITE:
> >
> > * https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Fcomponents%2Fx-ite%2Fblendmode%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749493727%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=8UyMDMx9h5q%2Flknb0mEgLClmMXVQRHhOmkSjt2cZ9Pc%3D&reserved=0
> > * https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.x3dom.org%2Fauthor%2FShape%2FBlendMode.html&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749507751%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=gC%2B%2BSv2J1swEPn0AijqQj8pH%2BdIaS17O%2F4urAhhgZ24%3D&reserved=0
> >
> > * https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Fcomponents%2Fx-ite%2Fdepthmode%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749519941%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=Z%2BDAhZwwW923qMoy5jNAX54G5ae3lGkM4Me6zxhCu6Y%3D&reserved=0
> > * https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.x3dom.org%2Fauthor%2FShape%2FDepthMode.html&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749531861%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=Jq%2Br3mVAZJeLFl7wotZxBkusp8KyrMFpUVFi5T3Bqk8%3D&reserved=0
> >
> > These nodes require each an additional field in the Appearance node:
> >
> > * https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Fcomponents%2Fshape%2Fappearance%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749543455%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=NmlKlM9qUkd94GvqzPZadjFe7UEZfalLZkuKEtaHMB8%3D&reserved=0
> > * https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.x3dom.org%2Fauthor%2FShape%2FAppearance.html&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749554995%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=34rN1xbKSUbesNFsRBtcW6mOuRrDr6HjVLbMMQ09XiY%3D&reserved=0
> >
> > X_ITE implementation of these node are a bit more complete to handle all WebGL possibilities, X3DOM is somehow limited in that.
> >
> > Best regards,
> > Holger
> >
> > --
> > Holger Seelig
> > Leipzig, Germany
> >
> > holger.seelig at yahoo.de
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749566589%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=zruiAPzGZV%2F2nbWkNGMqXX11EDn2RRuCOScwfosffAQ%3D&reserved=0
> >
> > Am 10.01.2025 um 16:32 schrieb Holger Seelig <holger.seelig at yahoo.de>:
> >
> > I would also like to thank Don and everyone here for the wonderful cooperation.
> >
> > Here are some wishes that may be relevant for X3D 4.1.
> >
> > * Definitely much need for EnvironmentLight as Michalis proposed it,
> > glTF can't live without it.
> > * https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Fwiki%2FImage-Based-Lighting-&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749577874%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=XTiSoAiVT1erfLyoqtusANv1EPEtWoRNZSME78vqItA%3D&reserved=0(EnvironmentLight-node)
> >
> > * PhysicalMaterial extensions to get all the glTF material stuff working,
> > * https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Fcomponents%2Foverview%2F%23x_ite&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749591142%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=FLPvbD855MSVAYw8SZaXeJeLRk%2BRJm4fjh2AdnNuSVM%3D&reserved=0
> >
> > * InstancedShape, useful anywhere but in special for glTF compatibility,
> > * https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Fcomponents%2Fx-ite%2Finstancedshape%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749602557%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=925G%2F2Iyf0pY2SwGvNHtCnAUvJJCD087xbgibXN4bNs%3D&reserved=0
> > * https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2F192.168.178.35%3A4000%2Fx_ite%2Flaboratory%2Fgltf-sample-viewer%2F%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2FKhronosGroup%2FglTF-Sample-Assets%2Fmaster%2FModels%2FSimpleInstancing%2FglTF%2FSimpleInstancing.gltf&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749613849%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=%2FsUqKHSX%2BJb83pF5d0RnoNMUqettvVnHhXdrL0174fM%3D&reserved=0
> >
> > The links contain examples and documentation of the nodes.
> >
> > Best regards,
> > Holger
> >
> > --
> > Holger Seelig
> > Leipzig, Germany
> >
> > holger.seelig at yahoo.de
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749625393%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=1aBftBv8hEOAkGaEpxPnjBOdLrrmo5KAyxRRbTQj9Vo%3D&reserved=0
> >
> > Am 10.01.2025 um 13:11 schrieb Michalis Kamburelis via x3d-public <x3d-public at web3d.org>:
> >
> > Thank you enormously for everything you're doing to keep this
> > coordinated. Onward we go!
> >
> > From my side, things I'd like to design as X3D extensions and propose
> > to be included in the next version of X3D standard, hopefully some time in 2025:
> >
> > - An (optional of course) way to specify mesh data as binary blobs, in
> > a way compatible with glTF:
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Fwiki%2FBinary-meshes&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749636710%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=I8HvTGYqIzjuy0gzb4jeh00CUIIp3wBcxtA976S6blo%3D&reserved=0
> >
> > - EnvironmentLight node:
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Fwiki%2FImage-Based-Lighting-&data=05%7C02%7Cbrutzman%40nps.edu%7C95a96744dabd43abd37808dd326799e4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638722145749647950%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=%2FfAGtfHbH5rAMXwlizmXR7U4liHqiMpq8g2XHerpfTY%3D&reserved=0(EnvironmentLight-node)
> >
> > The pages above contain information about the details - why I think
> > it's useful+important, what I know, what I don't know and need to
> > learn (including experimenting with implementation) to make it happen.
> >
> > Let's have a productive 2025 :)
> > Michalis
> >
> > czw., 9 sty 2025 o 21:21 Brutzman, Donald (Don) (CIV) via x3d-public
> > <x3d-public at web3d.org> napisał(a):
> >
> >
> >
> > X3D Standards Working Group meets regularly to review continuing progress.
> > Primary work is by Dr. Dick Puk and myself as editors for these International Standards jointly reviewed and published with International Standards Organization (ISO), as members of U.S. National Standards Body INCITS.
> > Here are relevant specifications being revised.
> > Assets
> >
> > X3D Graphics Standards Relationships diagram provides "big picture"
> > Mantis Issue Tracker (Web3D member access)
> > Github specifications archive (Web3D member access)
> > ISO/IEC SC24 Computer Graphics, image processing and environmental data representation
> > INCITS H3 Graphics and Imaging
> >
> > Draft specifications in progress
> >
> > X3D XML Encoding 4.0
> > X3D Classic VRML Encoding 4.0
> > X3D Architecture 4.1 maintenance
> > X3D Scene Authoring Interface 4.0
> >
> > Expected 2025 future work
> >
> > X3D Compressed Binary Encoding (CBE)
> >
> > Includes Fast Infoset, gzip, zip algorithms
> > Add Efficient XML Interchange, glTF binary (.glb)
> >
> > Humanoid Animation (HAnim) potential revisions version 2.1
> > X3D JSON Encoding (implemented)
> > X3D Java Programming (X3DJSAIL implementation)
> > X3D Python Programming (X3DPSAIL x3d.py implementation)
> > X3D JavaScript Programming
> > X3D C, C++, C# Programming
> > X3D Semantic Web Turtle Encoding 4.0 (implemented)
> >
> > All inputs are always welcome. Issues can be discussed on Web3D mailing lists or submitted via Mantis issue tracker.
> > We have had a productive year (29 years of forward progression, actually) and look forward to even greater progress in 2025.
> > Have fun with X3D stability and versatility! 🙂
> >
> > all the best, Don
> >
> > --
> >
> > Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
> >
> > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
> >
> > X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman
> >
> >
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
> >
> >
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> _______________________________________________
> consortium mailing list
> consortium at web3d.org
> http://web3d.org/mailman/listinfo/consortium_web3d.org
>
>
More information about the x3d-public
mailing list