[x3d-public] BlendMode

Sun Jan 12 14:27:39 PST 2025

P.S. I placed my explanation of BlendMode into the engine docs,
"2.28.1. Blending factors (node BlendMode and field
Appearance.blendMode)" on
https://castle-engine.io/x3d_extensions.php#section_ext_blending .

Regards,
Michalis

niedz., 12 sty 2025 o 23:05 Michalis Kamburelis
<michalis.kambi at gmail.com> napisał(a):
>
> ( 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
> >
> >