[x3d-public] got sample X3D model for FontLibrary or Tangent? glTF conversion progress, tooltips, names, etc. EnvironmentLight
Don Brutzman
don.brutzman at gmail.com
Mon Jan 19 19:25:06 PST 2026
For HAnimPose, we expect to build libraries of poses that are usable across
multiple different HAnimHumanoid models
So yes, we do we do want HAnimPose able to be a children node of things
like Group. EXPORT/IMPORT will likely be the easiest way to accomplish
such re-use.
all the best, Don
--
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting https://RelativeMotion.info
On Mon, Jan 19, 2026 at 3:10 AM Holger Seelig <holger.seelig at yahoo.de>
wrote:
> I don’t see why HAnimPose nodes should be child of a Group or
> X3DGroupingNode, they fulfill no purpose there, they are no visible
> nodes, nor a sensor or something else. HAnimPose nodes make only sense as
> part of a HAnimHumanoid, and should have a containerField ‚poses‘. We have
> already some similar node: HAnimMotion, why isn’t HAnimMotion not a
> X3DChildNode, because I want to put them in a Group and I want to clone
> them only in the HAnimHumanoid, and I want that the containerField of the
> HAnimMotion is ‚children‘, That would be exactly the same case as for
> HAnimPose, and it doesn't make sense. Another case, what if there will be a
> HAnimXXX node in the future we want them to be child of a Group and part of HAnimHumanoid,
> do we all put them in the HAnimHumanoid.children field? Sounds silly.
>
> The KISS principle may work, but there are other rules of thumb that can
> be applied as well: "Make everything as simple as possible, but not
> simpler.“ Albert Einstein.
>
> Best regards,
> Holger
>
> —
> Holger Seelig
> holger.seelig at yahoo.de
>
>
> Am 17.01.2026 um 01:29 schrieb Don Brutzman <don.brutzman at gmail.com>:
>
> 1. I don’t see why a EnvironmentLight.diffuse field is needed. If it is
>> only there for loading a .DDS file, which in turn unpacks to an environment
>> texture, then a ImageCubeMapTexture would be the right choice for loading
>> such files and then the EnvironmentTexture.diffuseTexture field is
>> sufficient.
>
>
> I share some confusion about these fields too.
>
> My working assumptions (which may well have some incorrect ideas) are that
>
> - *diffuseTexture *field and *specularTexture* field are for providing
> precomputed irradiance maps,
> - *diffuseCoefficients *field is for coefficients for a spherical
> harmonics function that provides a precomputed computational irradiance map,
> - *diffuse *field is for a texture to apply if computing the
> environment light by inspecting the surrounding scene
>
> Looking forward to some illumination by Michalis on such assumptions and
> draft specification definitions... better definitions are needed, working
> together always helps.
>
> If there are indeed variations in how an EnvironmentLight is initialized
> at run time, we should have examples of each. Hopefully there are a few
> such examples already provided in the Khronos glTF archives.
>
>
>> 2. Why is now the HAnimHumanoid.poses field renamed to
>> HAnimHumanoid.children? I can understand that HAnimPose.children field now
>> exists, because the default containterField of a HAnimJoint is ‚children‘,
>> but for the new HAnimPose a containterField can be as it was before ‚poses‘.
>>
>
> Another good question, again thank you.
>
> a. If we called the field 'poses' well that can work fine while the
> HAnimPose node is a child of the HAnimHumanoid. However, since scenes
> might typically have DEF/USE copies, the DEF and USE node definitions will
> each have different containerField values. Example:
>
> <Group>
> <HAnimPose DEF='MyPose1' containerField='children'>
> <!-- set of HAnimJoint nodes with nonoverlapping name values -->
> </HAnimPose>
> <HAnimPose DEF='MyPose2' containerField='children'/>
> <HAnimPose DEF='MyPose3' containerField='children'/>
>
> <HAnimHumanoid>
> <HAnimPose USE='MyPose1' containerField='poses'/>
> <HAnimPose USE='MyPose2' containerField='poses'/>
> <HAnimPose USE='MyPose3' containerField='poses'/>
> </HAnimHumanoid>
> </Group>
>
> b. However if we call the field 'children' throughout, there are no
> differences in containerField and everything is much terser, using a single
> default containerField value throughout.
>
> <Group>
> <HAnimPose DEF='MyPose1'>
> <!-- set of HAnimJoint nodes with nonoverlapping name values -->
> </HAnimPose>
> <HAnimPose DEF='MyPose2'/>
> <HAnimPose DEF='MyPose3''/>
>
> <HAnimHumanoid>
> <HAnimPose USE='MyPose1'/>
> <HAnimPose USE='MyPose2'/>
> <HAnimPose USE='MyPose3'/>
> </HAnimHumanoid>
> </Group>
>
> This terser approach is much simpler, less confusing for authors, and less
> error-prone as well.
>
> We applied several simplifications like this in X3D 4.0, always striving
> to minimize the need for non-default containerField values.
>
> - X3D Scene Authoring Hints: containerField
> -
> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField
>
> including
>
> - Field name changes for improved consistency in X3D4
> -
> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges
>
> Thus have tuned it for simplicity, option b, using 'children' field. Hope
> you think so too.
>
> p.s. Perhaps a good example of the KISS Principle (Keep It Simple
> Smartypants)! 😀
>
> all the best, Don
> --
> X3D Graphics, Maritime Robotics, Distributed Simulation
> Relative Motion Consulting https://RelativeMotion.info
> <https://relativemotion.info/>
>
>
> On Fri, Jan 16, 2026 at 3:54 AM Holger Seelig <holger.seelig at yahoo.de>
> wrote:
>
>> 1. I don’t see why a EnvironmentLight.diffuse field is needed. If it is
>> only there for loading a .DDS file, which in turn unpacks to an environment
>> texture, then a ImageCubeMapTexture would be the right choice for loading
>> such files and then the EnvironmentTexture.diffuseTexture field is
>> sufficient.
>>
>> 2. Why is now the HAnimHumanoid.poses field renamed to
>> HAnimHumanoid.children? I can understand that HAnimPose.children field now
>> exists, because the default containterField of a HAnimJoint is ‚children‘,
>> but for the new HAnimPose a containterField can be as it was before ‚poses‘.
>>
>> Best regards,
>> Holger
>>
>> —
>> Holger Seelig
>> holger.seelig at yahoo.de
>>
>>
>> Am 15.01.2026 um 23:33 schrieb Don Brutzman <don.brutzman at gmail.com>:
>>
>> Sounds super Michalis, glad you like it. Keeping concepts separate for
>> computation and presentation of the light seems helpful, avoiding
>> ambiguities.
>>
>> I worked on the specification prose to more correctly express what you
>> and others have written. Continuing refinements and improvements are
>> welcome.
>>
>> - X3D Architecture draft v4.1, clause 17 Lighting component, 17.4.2
>> EnvironmentLight
>> -
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/lighting.html#EnvironmentLight
>>
>> 17.4.2 EnvironmentLight
>>>
>>> Editors note. This preliminary node definition indicates intent to implement Image Based Lighting (IBL) <https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Vendor/EXT_lights_image_based> consistently with Khronos glTF specification <https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0> and the KHR_lights_environment extension <https://github.com/KhronosGroup/glTF/pull/1956> (older EXT_lights_image_based <https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Vendor/EXT_lights_image_based>). Renewed activity by X3D practitioners is focused on converged design, implementation and evaluation using the open-source Castle Model Viewer <https://github.com/michaliskambi/x3d-tests/wiki/Image-Based-Lighting-(EnvironmentLight-node)>, X_ITE <https://create3000.github.io/x_ite/components/lighting/environmentlight/> and X3DOM <https://doc.x3dom.org/author/Lighting/PhysicalEnvironmentLight.html> X3D browsers. Further improvements are possible. This work is tracked by issue Mantis 1336 <https://mantis.web3d.org/view.php?id=1336>.
>>>
>>> Editors note: for further information see
>>>
>>> - Image Based Lighting (EnvironmentLight node) <https://github.com/michaliskambi/x3d-tests/wiki/Image-Based-Lighting-(EnvironmentLight-node)> (Kamburelis),
>>> - A unified GLTF/X3D extension to bring physically-based rendering to the web <https://dl.acm.org/doi/10.1145/2945292.2945293> (Sturm et al.), and
>>> - Realtime Image Based Lighting using Spherical Harmonics <https://metashapes.com/blog/realtime-image-based-lighting-using-spherical-harmonics>.
>>>
>>> EnvironmentLight : X3DLightNode {
>>> SFFloat [in,out] ambientIntensity 0 [0,1]
>>> SFColor [in,out] color 1 1 1 [0,1]
>>> SFNode [in,out] diffuse NULL [X3DSingleTextureNode] # .DDS format
>>> SFNode [in,out] diffuseTexture NULL [X3DEnvironmentTextureNode]
>>> MFFloat [in,out] diffuseCoefficients []
>>> SFBool [in,out] global FALSE
>>> SFFloat [in,out] intensity 1 [0,∞)
>>> SFNode [in,out] metadata NULL [X3DMetadataObject]
>>> SFBool [in,out] on
>>> SFVec3f [in,out] origin 0 0 0 (-∞,∞)
>>> SFFloat [in,out] rotation 0 (-∞,∞)
>>> SFBool [in,out] shadows FALSE
>>> SFFloat [in,out] shadowIntensity 1 [0,1]
>>> SFNode [in,out] specularTexture NULL [X3DEnvironmentTextureNode]
>>> }
>>>
>>> Environment maps can represent incident illumination at a point, and can
>>> be used to show reflections of distant objects. The EnvironmentLight node
>>> supports Image Based Lighting (IBL) techniques by specifying light-source
>>> intensity around a given location (*i.e.*, the environment) as a cube
>>> map. EnvironmentLight defines both specular radiance and diffuse
>>> irradiance, converting an environment map into an irradiance map that shows
>>> how much light comes from any particular direction.
>>>
>>> When applying diffuseColor for this light node, the contained *diffuse* texture
>>> provides modulation for each pixel.
>>> TODO confirm definition for this field, seems unclear. Also consider
>>> relevance of .DDS format
>>> <https://learn.microsoft.com/en-us/windows/win32/direct3ddds/dx-graphics-dds> here,
>>> it is already mentioned in Environmental texturing and Texture3D components.
>>> What about .hdr format used in the Castle examples?
>>>
>>> The *diffuseTexture* and *specularTexture* fields define explicit
>>> precomputed X3DEnvironmentTextureNode (ComposedCubeMapTexture,
>>> GeneratedCubeMapTexture, ImageCubeMapTexture) nodes as the image source for
>>> the EnvironmentLight, rather than computing the surrounding light-source
>>> intensities from the scene.
>>>
>>> The *diffuseCoefficients* field provides a 3 x 9 array of float values
>>> providing spherical harmonic coefficients for low-frequency characteristics
>>> of the environment map to produce an irradiance map, corresponding to glTF
>>> *irradianceCoefficients* field (see RAMAMOORTHI).
>>>
>>> A description of the *global* field is in 17.2.1.2 Scoping of lights.
>>> The *global* field affects the scope of lighting effects produced by
>>> the EnvironmentLight node, and has no effect on the computation of
>>> environment textures.
>>>
>>> The *origin* field defines the relative position for observing the
>>> surrounding scene to create an environment texture. Input illumination to
>>> the EnvironmentLight node reflects all scene illumination visible at the
>>> node *origin*.
>>>
>>> EXAMPLE An author might set the *origin* field above the roof of a
>>> building, in order to provide outside environmental lighting shining
>>> through the doors and windows of an enclosed room inside that building.
>>>
>>> The *rotation* field... TODO define this field, likely needed for glTF
>>> compatibility. Presumably applied to textures, thus type SFFloat rather
>>> than SFRotation.
>>>
>>> Also updated validation tools and corresponding APIs: X3D XML Schema
>> <https://www.web3d.org/specifications/X3dSchemaDocumentation4.1/x3d-4.1_EnvironmentLight.html#Link108>
>> and DOCTYPE
>> <https://www.web3d.org/specifications/X3dDoctypeDocumentation4.1.html#EnvironmentLight>,
>> XML Tooltips
>> <https://www.web3d.org/x3d/tooltips/X3dTooltips.html#EnvironmentLight>,
>> X3DUOM <https://www.web3d.org/specifications/X3DUOM.html>, Java X3DJSAIL
>> <https://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Lighting/EnvironmentLight.html>
>> , Python X3DPSAIL
>> <https://www.web3d.org/x3d/stylesheets/python/x3d.html#EnvironmentLight>,
>> and X3D Ontology
>> <https://www.web3d.org/x3d/content/semantics/documentation/owldoc/index.html>
>> .
>>
>> Have fun with X3D draft v4.1 EnvironmentLight and physically based
>> rendering! 😀
>>
>> all the best, Don
>> --
>> X3D Graphics, Maritime Robotics, Distributed Simulation
>> Relative Motion Consulting https://RelativeMotion.info
>> <https://relativemotion.info/>
>>
>>
>> On Thu, Jan 15, 2026 at 6:08 AM Michalis Kamburelis <
>> michalis at castle-engine.io> wrote:
>>
>>> Thanks Don:
>>>
>>>
>>> - I agree. I think you make a great point with the
>>> "EnvironmentLight.origin" field. Thank you! :)
>>>
>>>
>>>
>>> - And yes, I like the name "origin", which makes it clear it's
>>> something quite different from "position / location" of the light source.
>>>
>>>
>>>
>>> - Because you don't need to know this "origin" when there's just one "EnvironmentLight"
>>> in your entire scene and when it has been just "provided explicitly by a
>>> set of textures" -- it just affects everything, from infinitely large
>>> sphere around the scene, conceptually. This "simplest case" is typical in
>>> glTF model viewers, and then this "origin" is useless... but we have to
>>> consider situations beyond this "simplest case".
>>>
>>>
>>>
>>> - 2 arguments I see for having "EnvironmentLight.origin", addressing
>>> also use-cases you mention:
>>>
>>>
>>>
>>> - What if the "EnvironmentLight" is actually a generated texture? "
>>> EnvironmentLight.specularTexture" is a X3DEnvironmentTextureNode ,
>>> deliberately, so you can place there "GeneratedCubeMapTexture" as
>>> well as (explicit) ImageCubeMapTexture or ComposedCubeMapTexture .
>>> And the "GeneratedCubeMapTexture" doesn't have an "origin" field
>>> itself (GeneratedCubeMapTexture spec says """The viewpoint of the
>>> generated texture is based on the location and orientation of the
>>> associated geometry in world space.""" but this will have to be updated
>>> when it's possible to be used in EnvironmentLight ). So that's 1
>>> argument for having "EnvironmentLight.origin", it would guide the
>>> way "GeneratedCubeMapTexture" inside
>>> "EnvironmentLight.specularTexture" is made.
>>>
>>>
>>>
>>> - Another point of view is usage. Looking at Unity light probes in
>>> HDR (
>>> https://docs.unity3d.com/560/Documentation/Manual/LightProbes.html ),
>>> they probe the lighting at multiple points of the scene and at runtime, you
>>> interpolate between these light probes to choose "the best" (which may be
>>> an interpolation of a few closest cubemaps). I very much want to have a
>>> system like this in CGE :) And having multiple "EnvironmentLight",
>>> with different "origins", each with "GeneratedCubeMapTexture",
>>> would be a natural way to express this in X3D.
>>>
>>>
>>> So, I like it, thanks again :) Let me experiment with this. I already
>>> extended my
>>> https://github.com/michaliskambi/x3d-tests/wiki/Image-Based-Lighting-(EnvironmentLight-node) to
>>> remember this.
>>>
>>> Regards,
>>> Michalis
>>> On Thursday, January 15th, 2026 at 04:32, Don Brutzman <
>>> don.brutzman at gmail.com> wrote:
>>>
>>> Sounds good, thanks Michalis.
>>>
>>> I have changed default global value to FALSE and begun rippling out
>>> deployments.
>>>
>>> I am still not sure if we ought to add a field for position (perhaps a
>>> better name is "origin" for where the light map is computed. It seems there
>>> are two locations of interest: the origin point where the EnvironmentLight
>>> node computes the environment lighting, and possibly another point where it
>>> might be providing that active lighting... perhaps even providing active
>>> lighting in more than one place if DEF/USE references to that node are
>>> applied.
>>>
>>> Here is a use case of possible value. A room exists in a house within a
>>> larger city block, and the DirectionalLight source represents the sun
>>> overhead. Late in the day it might be rather low, and much brighter on the
>>> sides of surrounding shapes facing the sun.
>>>
>>> Let's say the room had doors and windows, and the modeler wants to show
>>> lighting effects within the room from the outside. Can we use
>>> EnvironmentLight to represent that?
>>>
>>> - For instance if the origin location (computing lighting) is above
>>> to roof of the house, it is getting all of the global illumination for its
>>> computation.
>>> - If the EL is positioned just outside a door frame, and similarly
>>> USED outside each window frame, will the external lighting effects be
>>> affecting objects inside the room, but not through walls or separately
>>> scoped objects when global="false"?
>>>
>>> Thanks for considering the possibilities.
>>>
>>> all the best, Don
>>> --
>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>> Relative Motion Consulting https://RelativeMotion.info
>>> <https://relativemotion.info/>
>>>
>>>
>>> On Wed, Jan 14, 2026 at 2:04 AM Michalis Kamburelis <
>>> michalis at castle-engine.io> wrote:
>>>
>>>> It's great to hear X_ITE implements EnvironmentLight ! I will look at
>>>> it ASAP :), and this should bump my enthusiasm for finishing it (in spec,
>>>> and in CGE implementation) :)
>>>>
>>>> I will try to renew my efforts around it -- admittedly it's just my
>>>> failure to not finishing EnvironmentLight spec, and not finishing
>>>> EnvironmentLight implementation in CGE.
>>>>
>>>> For what it's worth, my current knowledge is on
>>>> https://github.com/michaliskambi/x3d-tests/wiki/Image-Based-Lighting-(EnvironmentLight-node)
>>>> . I will update it as I go.
>>>>
>>>> To answer some Don questions:
>>>>
>>>>
>>>> - It should have global=TRUE by default, since that's the "most
>>>> common" usage of it, the light should affect everything.
>>>> - Some others who define it do not even have a non-global option
>>>> for it:
>>>> - glTF (including EXT_lights_image_based, KHR_environment_map,
>>>> see links from above) does not have such option, light affects everything.
>>>> - Unity environment lighting (
>>>> https://docs.unity3d.com/Packages/com.unity.render-pipelines.high-definition@12.0/manual/Environment-Lighting.html
>>>> ), which is kind of close to it, also doesn't have any control here to
>>>> include/exclude particular shapes. The light shines on everything.
>>>> - We also happened to talk yesterday at the X3D Ecosystem
>>>> meeting about it, and I think we had consensus that A. there are use-cases
>>>> when EnvironmentLight wih global=FALSE makes sense (Aaron
>>>> mentioned "you have inside a factory with it's EnvironmentLight + outside
>>>> of factory in one X3D"), B. ... but these use-cases are rare.
>>>> - So it's nice to have an option "global" for EnvironmentLight
>>>> (as we do for all lights in X3D)... but default should be global=TRUE, IMHO.
>>>>
>>>>
>>>>
>>>> - The EnvironmentLight should not have any location / position.
>>>> It's not how it works, it has no location / position for computations. The
>>>> EnvironmentLight defines a surrounding that is "infinitely away from your
>>>> defined 3D objects". In this sense, it's closer to a DirectionalLight (and
>>>> not to PointLight or SpotLight), that also doesn't have location /
>>>> position .
>>>>
>>>>
>>>> Regards,
>>>> Michalis
>>>> On Tuesday, January 13th, 2026 at 23:40, Don Brutzman via x3d-public <
>>>> x3d-public at web3d.org> wrote:
>>>>
>>>> The originally proposed section on EnvironmentLight is again exposed
>>>> and linked in the X3D Architecture draft version 4.1 specification.
>>>>
>>>> - X3D Architecture draft version 4.1, clause 17 Lighting component,
>>>> 17.4.2 EnvironmentLight
>>>> -
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/lighting.html#EnvironmentLight
>>>>
>>>> I gave us a TODO in the specification, please advise if you know the
>>>> answer or reference:
>>>>
>>>> - TODO explain the nature of the 3 x 9 array for
>>>> diffuseCoefficients field.
>>>>
>>>> I assume that we do want default value global='false' so that rendering
>>>> of EnvironmentLight rendering effects are limited to the current group. Of
>>>> note is that X3DLightingNode *global* field can have different values
>>>> in implementing nodes (DirectionLight is different, default global='false').
>>>>
>>>> - 17.3.1 X3DLightNode
>>>> -
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/lighting.html#X3DLightNode
>>>> -
>>>>
>>>> SFBool [in,out] global [TRUE | FALSE] FALSE
>>>>
>>>> - Implementing nodes may have different default values.
>>>>
>>>> For clarity, am wondering if the following prose is helpful in
>>>> EnvironmentLight definitions:
>>>>
>>>> - A description of the *global* field is in 17.2.1.2 Scoping of
>>>> lights
>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/lighting.html#ScopingOfLights>.
>>>> The *global* field affects the scope of lighting effects produced
>>>> by the EnvironmentLight node. Input illumination to the EnvironmentLight
>>>> node reflects all rendering visible at the node *location*.
>>>>
>>>> For consistency with PointLight and SpotLight, shouldn't there be a *location
>>>> *field?
>>>>
>>>> -
>>>>
>>>> SFVec3f [in,out] location 0 0 0 (-∞,∞)
>>>>
>>>> - The *location* field defines the relative position for observing
>>>> the surrounding environment.
>>>>
>>>> All four of the currently proposed nodes for X3D draft 4.1 are
>>>> conveniently linked at the top of the following specification index page.
>>>>
>>>> - X3D Architecture draft version 4.1, Node, abstract node type, and
>>>> abstract interface index
>>>> -
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/nodeIndex.html
>>>> - New nodes in X3D 4.1 draft: EnvironmentLight
>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/nodeIndex.html#EnvironmentLight>,
>>>> FontLibrary
>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/nodeIndex.html#FontLibrary>,
>>>> HAnimPose
>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/nodeIndex.html#HAnimPose>,
>>>> Tangent
>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/nodeIndex.html#Tangent>
>>>>
>>>> Have also added EnvironmentLight node to X3D XML DOCTYPE, XML Schema,
>>>> X3D Tooltips, X3DUOM, X3DJSAIL, X3DPSAIL, X3D Ontology for Semantic Web.
>>>> (Much of the work was done during X3D 4.0 and I just had to carefully
>>>> uncomment and adjust.)
>>>>
>>>> So test validation is now fully available, and if any changes are
>>>> needed, they can be quickly accomplished.
>>>>
>>>> Repeating once again, enthusiastically: implementation and evaluation
>>>> using example models is welcome.
>>>>
>>>> all the best, Don
>>>> --
>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>> Relative Motion Consulting https://RelativeMotion.info
>>>> <https://relativemotion.info/>
>>>>
>>>>
>>>> On Mon, Jan 12, 2026 at 10:16 AM Don Brutzman <don.brutzman at gmail.com>
>>>> wrote:
>>>>
>>>>> A. I have added the khronos license link to the model meta
>>>>> information, which also includes a local copy + link of the license
>>>>> provided earlier.
>>>>>
>>>>> - X3D4AM, X3D for Advanced Modeling Examples Archive, Gltf Sample
>>>>> Models, Sheen Cloth
>>>>> <https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/SheenClothIndex.html>
>>>>>
>>>>> C. CannonExterior.avif deleted.
>>>>>
>>>>> Glad to hear of your interest in EnvironmentLight !
>>>>>
>>>>> Dick Puk and I welcome readiness of draft specification for
>>>>> EnvironmentLight node - prior work with Michalis got it pretty close to
>>>>> completion already in X3D 4.0, but we were at deadline and there were not 2
>>>>> independent implementations.
>>>>>
>>>>> Following review and potential improvement of the below draft by
>>>>> everyone interested, I will integrate the node definition into X3D v4.1
>>>>> draft specification and add it to all of the validation tools. This is a
>>>>> deferred action from X3D 4.0 standardization efforts.
>>>>>
>>>>> - Mantis issue tracker #1336: 17.4.2 EnvironmentLight - Khronos
>>>>> glTF extension for image based lighting
>>>>> - https://mantis.web3d.org/view.php?id=1336
>>>>> - *copy of Mantis issue attached, most recent node signature and
>>>>> prose follows, all review comments welcome.*
>>>>>
>>>>> 17.4.2 EnvironmentLight
>>>>>>
>>>>>> Editors NOTE This preliminary node definition indicates intent to
>>>>>> implement Image Based Lighting (IBL) as defined by Khronos glTF
>>>>>> specification. Current activity by X3D practitioners is focused on
>>>>>> converged design, implementation and evaluation using the open-source
>>>>>> Castle Game Engine, X_ITE, and X3DOM X3D browsers. Further improvements are
>>>>>> expected.
>>>>>>
>>>>>> EnvironmentLight : X3DLightNode {
>>>>>> SFFloat [in,out] ambientIntensity 0 [0,1]
>>>>>
>>>>> SFColor [in,out] color 1 1 1 [0,1]
>>>>>
>>>>> SFNode [in,out] diffuse NULL [X3DSingleTextureNode] # .DDS format
>>>>>
>>>>> SFNode [in,out] diffuseTexture NULL [X3DEnvironmentTextureNode]
>>>>>
>>>>> MFFloat [in,out] diffuseCoefficients []
>>>>>
>>>>> SFBool [in,out] global FALSE
>>>>>
>>>>> SFFloat [in,out] intensity 1 [0,inf)
>>>>>
>>>>> SFNode [in,out] metadata NULL [X3DMetadataObject]
>>>>>
>>>>> SFBool [in,out] on TRUE
>>>>>
>>>>> SFRotation [in,out] rotation 0 0 1 0 [-1,1] or (-inf,inf)
>>>>>
>>>>> SFBool [in,out] shadows FALSE
>>>>>> SFFloat [in,out] shadowIntensity 1 [0,1]
>>>>>
>>>>> SFNode [in,out] specularTexture NULL [X3DEnvironmentTextureNode]
>>>>>
>>>>> }
>>>>>> The EnvironmentLight node supports Image Based Lighting (IBL) by
>>>>>> specifying light-source intensity around a given location (i.e., the
>>>>>> environment) as a cube map. EnvironmentLight defines both specular radiance
>>>>>> and diffuse irradiance.
>>>>>>
>>>>>> The diffuseTexture and specularTexture fields define diffuse and
>>>>>> specular lighting modifications, respectively.
>>>>>>
>>>>>> The diffuseCoefficients field provides a 3 x 9 array of float values
>>>>>> that declares spherical harmonic coefficients for irradiance up to l=2,
>>>>>> corresponding to glTF irradianceCoefficients field. The diffuseCoefficients
>>>>>> field overrides the diffuseTexture field if both are provided.
>>>>>>
>>>>>> A description of the global field is in 17.2.1.2 Scoping of lights
>>>>>
>>>>>
>>>>> Looks like we have begun executing the next steps. Looking forward to
>>>>> continuing progress.
>>>>>
>>>>> TODO
>>>>>> * prepare draft specification prose for X3D 4.1
>>>>>> * share examples in X3D Examples Archives
>>>>>> * encourage adoption by authors and tool builders
>>>>>
>>>>>
>>>>> D. X3D v4.0 is stable, approved, and an excellent default version for
>>>>> new models. X3D v4.1 is draft and development is now fully supported, as
>>>>> reported in my 2026 New Year blog post.
>>>>>
>>>>> - X3D and HAnim Assets Update, 2 JAN 2026
>>>>> - https://relativemotion.info/x3d-and-hanim-assets-update
>>>>>
>>>>> I recommend using X3D 4.1 for any scene containing FontLibrary,
>>>>> HAnimPose, Tangent, or EnvironmentLight nodes. Otherwise 4.0 is just fine;
>>>>> whatever people prefer is fine by me, the "X" in X3D is Extensible.
>>>>>
>>>>> Have fun with X3D v4.1 draft! 🤔
>>>>>
>>>>> all the best, Don
>>>>> --
>>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>>> Relative Motion Consulting https://RelativeMotion.info
>>>>> <https://relativemotion.info/>
>>>>>
>>>>>
>>>>> On Mon, Jan 12, 2026 at 2:21 AM Holger Seelig <holger.seelig at yahoo.de>
>>>>> wrote:
>>>>>
>>>>>> A. There is a LICENCE file in the original folder:
>>>>>> https://github.com/KhronosGroup/glTF-Sample-Assets/blob/main/Models/SheenCloth/LICENSE.md
>>>>>>
>>>>>> C. Yes CannonExterior.avif can be deleted. I tested an
>>>>>> EnvironmentLight node, and removed it again because it’s still not
>>>>>> supported by Castle. But an EnvironmentLight is very important for
>>>>>> PhysicalMaterial to see reflections, metallic effects, brighter textures,
>>>>>> and so on, otherwise these material parts remain black or darker.
>>>>>>
>>>>>> D. Seems X_ITE should also switch to X3D4.1? 😃
>>>>>>
>>>>>> Best regards,
>>>>>> Holger
>>>>>>
>>>>>> —
>>>>>> Holger Seelig
>>>>>> holger.seelig at yahoo.de
>>>>>>
>>>>>> Am 12.01.2026 um 06:07 schrieb Don Brutzman <don.brutzman at gmail.com>:
>>>>>>
>>>>>> Thanks Holger.
>>>>>>
>>>>>> a. I was not able to figure out who the original creator was from the
>>>>>> README files or github history - "Microsoft" perhaps? Appreciate your
>>>>>> upgrading this.
>>>>>>
>>>>>> b. Commented out undefined field in ImageTexture: <!--
>>>>>> colorSpaceConversion='false' -->
>>>>>>
>>>>>> c. Was CannonExterior.avif used in this model, or should it be
>>>>>> deleted?
>>>>>>
>>>>>> -
>>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/CannonExterior.avif
>>>>>>
>>>>>> d. Changed X3D version to 4.1 since Tangent node is present
>>>>>>
>>>>>> e. Once again looks identical in X_ITE and Castle. 👍
>>>>>>
>>>>>> f. This was an important example to finally get added because it
>>>>>> revealed important gaps in X3D XML Schema and DOCTYPE. Now updated, along
>>>>>> with X3DUOM, X3DJSAIL, and X3D Ontology with X3DPSAIL x3d.py to follow.
>>>>>>
>>>>>> 11 JAN 2026, brutzman, seelig
>>>>>>> - (v4.0, v4.1) MultiTextureTransform can also contain
>>>>>>> TextureTransform3D and
>>>>>>> TextureTransformMatrix3D in addition to TextureTransform
>>>>>>
>>>>>>
>>>>>> - X3D Specifications: Schema and DOCTYPE Validation
>>>>>> - https://www.web3d.org/specifications
>>>>>>
>>>>>> g. Hopefully the publication efforts and metadata look good.
>>>>>> Published in version control and online at
>>>>>>
>>>>>> - X3D Example Archives: X3D4AM, X3D for Advanced Modeling, Gltf
>>>>>> Sample Models, Sheen Cloth
>>>>>> - MultiTexture model converted from glTF
>>>>>> -
>>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/SheenClothIndex.html
>>>>>>
>>>>>> Have fun with advanced rendering using X3D! 😀
>>>>>>
>>>>>> all the best, Don
>>>>>> --
>>>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>>>> Relative Motion Consulting https://RelativeMotion.info
>>>>>> <https://relativemotion.info/>
>>>>>>
>>>>>>
>>>>>> On Sun, Jan 11, 2026 at 12:30 PM Holger Seelig <
>>>>>> holger.seelig at yahoo.de> wrote:
>>>>>>
>>>>>>> Here is a very simple example with only one shape that uses
>>>>>>> MultiTextureTransform (two different TextureTransformMatrix3D nodes) and
>>>>>>> MultiTextureCoordinate (where both TextureCoordinate node are actually the
>>>>>>> same). I have added a SheenCloth.x3d, converted with X_ITE. I have modified
>>>>>>> the original conversion file to make it work in Castle Model Viewer
>>>>>>> (removed the SheenMaterialExtension node, added proper NavigationInfo and
>>>>>>> Viewpoint, added MultiTextureCoordinate because Castle needs this, X_ITE
>>>>>>> uses the last TextureCoordinate if a mapping does not match). I attached
>>>>>>> the whole folder with all textures and the converted file SheenCloth.x3d.
>>>>>>>
>>>>>>> This file is originally from the glTF-Sample-Assets from Khronos:
>>>>>>>
>>>>>>> https://github.com/KhronosGroup/glTF-Sample-Assets/tree/main/Models/SheenCloth
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Holger
>>>>>>>
>>>>>>> Am Sonntag, 11. Januar 2026 um 04:45:19 MEZ hat Don Brutzman <
>>>>>>> don.brutzman at gmail.com> Folgendes geschrieben:
>>>>>>>
>>>>>>>
>>>>>>> [cc: x3d-public since this topic has ballooned to be much bigger
>>>>>>> than originally expected]
>>>>>>>
>>>>>>> Background: working on putting two of Michalis' Castle Model Viewer
>>>>>>> examples for X3D 4.1 Tangent node into the X3D Example Archives.
>>>>>>>
>>>>>>> - X3D Example Archives: X3D4AM, X3D for Advanced Modeling, Gltf
>>>>>>> Sample Models, Cat By Muru
>>>>>>> -
>>>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/CatByMuruIndex.html
>>>>>>> -
>>>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/CatByMuruX_ITE.html
>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>> - X3D Example Archives: X3D4AM, X3D for Advanced Modeling, Gltf
>>>>>>> Sample Models, Halloween Pumpkin Lantern Knight
>>>>>>> -
>>>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/HalloweenPumpkinLanternKnightIndex.html
>>>>>>> -
>>>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/HalloweenPumpkinLanternKnightX_ITE.html
>>>>>>>
>>>>>>> =================
>>>>>>>
>>>>>>> Continuing, mostly finishing this long thread:
>>>>>>>
>>>>>>> Thanks Holger for the TextureTransform technique. I have applied
>>>>>>> that change in two models (CatByMuru.x3d and
>>>>>>> HalloweenPumpkinLanternNight.x3d to good effect.
>>>>>>>
>>>>>>> Have also added the following tooltip.
>>>>>>>
>>>>>>> - X3D Tooltips: TextureTransform
>>>>>>> -
>>>>>>> https://www.web3d.org/x3d/content/X3dTooltips.html#TextureTransform
>>>>>>>
>>>>>>> Hint: image flip horizontal <TextureTransform DEF='FlipHorizontal'
>>>>>>> scale='-1 1' translation='-1 0'/>
>>>>>>> Hint: image flip vertical <TextureTransform DEF='FlipVertical'
>>>>>>> scale='1 -1' translation='0 -1'/>
>>>>>>>
>>>>>>> Noticed that when you apply such a TextureTransform, it is a child
>>>>>>> of the parent Appearance node, and not part of each ImageTexture (like the
>>>>>>> CGE attribute). When there is an associated PhysicalMaterial and no mapping
>>>>>>> field is defined, that means the TextureTransform applies to all of the
>>>>>>> ImageTexture fields (baseTexture, emissiveTexture,
>>>>>>> metallicRoughnessTexture, normalTexture, occlusionTexture). Similarly for
>>>>>>> UnlitMaterial.
>>>>>>>
>>>>>>> Michalis, should I leave mapping="" blank throughout, or else apply
>>>>>>> a value there (perhaps mapping='flipVertical' throughout)?
>>>>>>>
>>>>>>> We don't appear to mention this case explicitly in the
>>>>>>> specification, but I think the prose is OK and does not allow any other
>>>>>>> interpretation. (We can add more words for clarity if anyone wants to.)
>>>>>>>
>>>>>>> - X3D Architecture version 4.1 draft, clause 12 Shape
>>>>>>> component12.2.2 Appearance characteristics
>>>>>>> -
>>>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shape.html#AppearanceCharacteristics
>>>>>>>
>>>>>>> Also thanks Michalis, I have added generateMipMaps='true' to
>>>>>>> TextureProperties nodes, and handled DEF/USE.
>>>>>>>
>>>>>>> - <TextureProperties DEF='AveragePixel' generateMipMaps='true'
>>>>>>> magnificationFilter='AVG_PIXEL' minificationFilter='AVG_PIXEL_AVG_MIPMAP'/>
>>>>>>>
>>>>>>> HalloweenPumpkinLanternKnight.x3d model is too large for X3DJSAIL to
>>>>>>> load, unfortunately (currently 2.6MB) and so I was not able to reduce the
>>>>>>> extra-long floats in there (no more than 7 digits of precision are needed).
>>>>>>>
>>>>>>> Michalis, the character
>>>>>>> dollar; $ <https://en.wikipedia.org/wiki/$> U+
>>>>>>> <https://en.wikipedia.org/wiki/Basic_Latin_(Unicode_block)>0024is
>>>>>>> not within the range allowed for XML NMTOKEN (name token) data type, and so
>>>>>>> it is not recommended for X3D model interoperability across all file
>>>>>>> encodings and programming-language bindings. See
>>>>>>>
>>>>>>> - XML Recommendation, v1.1 (Second edition), World Wide Web
>>>>>>> Consortium (W3C), 2.3 Common Syntactic Constructs, Names and Tokens
>>>>>>> - https://www.w3.org/TR/xml11/#sec-common-syn
>>>>>>>
>>>>>>> DEF/USE, proto and other names in X3D Example Archive models are
>>>>>>> always conservative for best interoperability, additional suggestions
>>>>>>> always welcome. Further details are maintained at
>>>>>>>
>>>>>>> - X3D Scene Authoring Hint, NamingConventions
>>>>>>> -
>>>>>>> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#NamingConventions
>>>>>>>
>>>>>>> Giving a node DEF='head' is legal, but it is confusing for the XML
>>>>>>> encoding, so I usually change things like that for clarity... which is
>>>>>>> often essential in the X3D Example Archives. Not sure if we should add
>>>>>>> 'head' to the list of reserved words.
>>>>>>>
>>>>>>> *Both the CatByMuru and HalloweenPumpkinLanternKnight models are
>>>>>>> looking good and looking consistent, both for Castle Model Viewer and
>>>>>>> X_ITE/Playground/Sunrize. Bravo!*
>>>>>>>
>>>>>>> X3DOM looks quite different (perhaps differing application of PBR
>>>>>>> textures in Physical Material node). Perhaps someone wants to work on that
>>>>>>> open-source codebase... examples in the X3dForAdvancedModeling
>>>>>>> GltfSampleModels directly provide a lot of excellent test cases for glTF
>>>>>>> compatibility, with many others working already.
>>>>>>>
>>>>>>> New issue: since multiple TextureTransform nodes might be needed
>>>>>>> within an Appearance, should we allow multiple TextureTransform nodes in
>>>>>>> Appearance? Right now that is an SFNode field. If you think there is a use
>>>>>>> case that an author (or converter) would want more than one
>>>>>>> TextureTransform in the Appearance node, please advise.
>>>>>>>
>>>>>>> - 12.4.2 Appearance
>>>>>>> -
>>>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shape.html#Appearance
>>>>>>>
>>>>>>> Appearance : X3DAppearanceNode {
>>>>>>> SFNode [in,out] acousticProperties NULL [AcousticProperties]
>>>>>>> SFFloat [in,out] alphaCutoff 0.5 [0,1]
>>>>>>> SFString [in,out] alphaMode "AUTO" ["AUTO", "OPAQUE", "MASK", "BLEND"]
>>>>>>> SFNode [in,out] backMaterial NULL [X3DOneSidedMaterialNode]
>>>>>>> SFNode [in,out] fillProperties NULL [FillProperties]
>>>>>>> SFNode [in,out] lineProperties NULL [LineProperties]
>>>>>>> SFNode [in,out] material NULL [X3DMaterialNode]
>>>>>>> SFNode [in,out] metadata NULL [X3DMetadataObject]
>>>>>>> SFNode [in,out] pointProperties NULL [PointProperties]
>>>>>>> MFNode [in,out] shaders [] [X3DShaderNode]
>>>>>>> SFNode [in,out] texture NULL [X3DTextureNode]
>>>>>>> SFNode [in,out] textureTransform NULL [X3DTextureTransformNode]
>>>>>>> }
>>>>>>>
>>>>>>> Have fun using glTF models in X3D! 😀
>>>>>>>
>>>>>>> all the best, Don
>>>>>>> --
>>>>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>>>>> Relative Motion Consulting https://RelativeMotion.info
>>>>>>> <https://relativemotion.info/>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Jan 4, 2026 at 1:11 PM Holger Seelig <holger.seelig at yahoo.de>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Instead of a flipVertically field, it is also possible to achieve
>>>>>>> this with a TextureTransform node
>>>>>>>
>>>>>>> DEF FlipVertically TextureTransform {
>>>>>>> translation 0 -1
>>>>>>> scale 1 -1
>>>>>>> }
>>>>>>>
>>>>>>> Another solution is to flip all texture coordinates (y’ = 1 - y).
>>>>>>>
>>>>>>> After all investigations I think that Castle and X_ITE are on the
>>>>>>> right way representing glTF textures, but all the examples miss a
>>>>>>> flipVertically in either way.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Holger
>>>>>>>
>>>>>>> —
>>>>>>> Holger Seelig
>>>>>>> holger.seelig at yahoo.de
>>>>>>>
>>>>>>>
>>>>>>> Am 04.01.2026 um 01:32 schrieb Michalis Kamburelis <
>>>>>>> michalis.kambi at gmail.com>:
>>>>>>>
>>>>>>> Hello Don,
>>>>>>>
>>>>>>> Great, thanks for the analysis of the file and tests on other
>>>>>>> browsers! Answers:
>>>>>>>
>>>>>>> 1. flipVertically:
>>>>>>>
>>>>>>> - This is documented on
>>>>>>> https://castle-engine.io/x3d_implementation_texturing_extensions.php#section_flip_vertically
>>>>>>> , with reasons why.
>>>>>>>
>>>>>>> - We talked about it in the past on x3d-public already.
>>>>>>>
>>>>>>> - No, I don't think now that it deserves to be added to spec. Let it
>>>>>>> remain CGE extension. CGE should export with TextureTransform making this
>>>>>>> "flipVertically" unnecessary, and the files spec-conforming. Implementing
>>>>>>> this by "flipVertically" in CGE is just an optimization (see link above),
>>>>>>> effectively, since it's zero overhead to flip at loading. I feel it can
>>>>>>> remain CGE extension, actually.
>>>>>>>
>>>>>>> - So, give me time, I'll fix these models to not use flipVertically
>>>>>>> :)
>>>>>>>
>>>>>>> 2. $ in name:
>>>>>>>
>>>>>>> - I was under impression that $ is actually OK inside name in X3D.
>>>>>>> We use it in special situations (when "encoding" names with arbitrary chars
>>>>>>> from other formats) deliberately.
>>>>>>>
>>>>>>> - Spec
>>>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/grammar.html
>>>>>>> about "IdRestChars" implies $ is OK. ("$" is 0x24), from what I can tell.
>>>>>>>
>>>>>>> - CGE code derived from this is
>>>>>>> https://github.com/castle-engine/castle-engine/blob/7dccdbb455d544e3659d6f049cde9bcf428c3c86/src/scene/load/x3dloadinternalutils.pas#L82
>>>>>>> .
>>>>>>>
>>>>>>> - So: Are you sure "$" is not valid in X3D name? Where is this
>>>>>>> mentioned in spec? If that's the case -> no problem, I'll fix our code, and
>>>>>>> the test models.
>>>>>>>
>>>>>>> 3. """Wondering why you have those EXPORT statements"""
>>>>>>>
>>>>>>> - Our glTF->X3D converter EXPORTs some named nodes, to allow
>>>>>>> animation of them by the outer X3D file.
>>>>>>>
>>>>>>> - In short, it doesn't matter for these particular examples, these
>>>>>>> EXPORTS are not used in this case.
>>>>>>>
>>>>>>> 4. """<Transform DEF='head'/> has DEF name that illegally overrides
>>>>>>> a reserved word from the X3D Specification"""
>>>>>>>
>>>>>>> - I was not aware that such names are disallowed.
>>>>>>>
>>>>>>> - "head" is not mentioned as keyword on
>>>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/grammar.html
>>>>>>> .
>>>>>>>
>>>>>>> - It's not used by classic encoding, it's only an element name in
>>>>>>> X3D XML. I don't see how node name "head" could be really confused with
>>>>>>> element <head> in X3D?
>>>>>>>
>>>>>>> - That said, we could fix the model (and CGE converter). Can you
>>>>>>> show me where in the specification is the "head" for node name disallowed?
>>>>>>> I can add a logic to our converter to avoid "head" name then.
>>>>>>>
>>>>>>> 5. """<TextureProperties DEF=''/> requires generateMipMaps='true'
>>>>>>> since minificationFilter='AVG_PIXEL_AVG_MIPMAP""""
>>>>>>>
>>>>>>> - I'll fix it, indeed spec says "Mipmaps are required for filtering
>>>>>>> modes with MIPMAP in their value."
>>>>>>>
>>>>>>> - Note that CGE ignores this field. Only the filtering determines
>>>>>>> whether we need mipmaps... so to us, generateMipMaps field is actually not
>>>>>>> useful.
>>>>>>>
>>>>>>> - (And it could be confusing in case of files like DDS or KTX, where
>>>>>>> mipmaps are part of the image. In such case, we have mipmaps, we use them
>>>>>>> -> but we don't "generate" them).
>>>>>>>
>>>>>>> - Anyhow, that's all minor notes :) We can just place
>>>>>>> generateMipMaps='true'.
>>>>>>>
>>>>>>> 6. About the float precision: We have a --float-precision option to
>>>>>>> Castle Model Converter, it was just not used for this. I can indeed
>>>>>>> reexxport this with smaller precision.
>>>>>>>
>>>>>>> Summary: Give me time :) and I'll fix
>>>>>>>
>>>>>>> - AD 1 - flipVertically
>>>>>>> - AD 5- generateMipMaps
>>>>>>> - AD 6 - float precision
>>>>>>>
>>>>>>> in the models.
>>>>>>>
>>>>>>> For 2 other questions, I'll appreciate a link to spec :), but of
>>>>>>> course we could also adjust to them, nothing problematic there :) This
>>>>>>> applies to:
>>>>>>>
>>>>>>> - AD 2 - $ in name
>>>>>>> - AD 4 - "head" in name
>>>>>>>
>>>>>>> Regards,
>>>>>>> Michalis
>>>>>>>
>>>>>>> sob., 3 sty 2026 o 07:11 Don Brutzman <don.brutzman at gmail.com>
>>>>>>> napisał(a):
>>>>>>>
>>>>>>> Thank you very much for recovering those, Michalis!
>>>>>>>
>>>>>>> I copied all three and put originals in version control, and began
>>>>>>> work on first. Next step, ran/committed .x3d version through X3D
>>>>>>> Canonicalization (C14N) so that any changes which occur are evident. Also
>>>>>>> added a variety of meta tags.
>>>>>>>
>>>>>>> Validation diagnostics quickly found the following errors:
>>>>>>>
>>>>>>> - Attribute "flipVertically" must be declared for element type
>>>>>>> "ImageTexture". (now omitted, may look funny)
>>>>>>> - Attribute value "CastleEncoded_Pose_scene$46$fbx" of type
>>>>>>> IDREF must be an NCName when namespaces are enabled. (changed $ character
>>>>>>> to underscore _ character)
>>>>>>>
>>>>>>> If you would like to add *flipVertical *and *flipHorizontal *attributes
>>>>>>> to ImageTexture, or to interface X3DSingleTextureNode (ImageTexture,
>>>>>>> MovieTexture, PixelTexture), please propose that on x3d-public mail list.
>>>>>>> Seems plausible to me, if glTF has something like that then let's do it
>>>>>>> consistently. No need to add "ly" suffix to names of such boolean fields.
>>>>>>> If everyone reaches consensus (or interest at least) then I can add them to
>>>>>>> XML DOCTYPE and Schema for draft version 4.1.
>>>>>>>
>>>>>>> Continued work on other diagnostics...
>>>>>>>
>>>>>>> Wondering why you have those EXPORT statements?
>>>>>>>
>>>>>>> Got illegal DEF name warning, renamed 'head' to 'modelHead'
>>>>>>>
>>>>>>> - <Transform DEF='head'/> has DEF name that illegally overrides
>>>>>>> a reserved word from the X3D Specification
>>>>>>> [/X3D/Scene/Transform/Transform/Transform/Transform[1], error]
>>>>>>>
>>>>>>> Got several X3D Schematron warnings like this, do you agree?
>>>>>>>
>>>>>>> - <TextureProperties DEF=''/> requires generateMipMaps='true'
>>>>>>> since minificationFilter='AVG_PIXEL_AVG_MIPMAP' mode indicates MIPMAP
>>>>>>> rendering
>>>>>>> [/X3D/Scene/Transform/Transform/Transform/Transform[1]/Transform/Group/Shape/Appearance/PhysicalMaterial/ImageTexture[4]/TextureProperties,
>>>>>>> error]
>>>>>>> - looks like those three nodes are identical might be single DEF
>>>>>>> with one USE
>>>>>>>
>>>>>>> Got a Schematron warning to take advantage of DEF/USE, and so did
>>>>>>> that.
>>>>>>>
>>>>>>> - <ImageTexture DEF=''/> url array address(es) duplicate the url
>>>>>>> definition found in a preceding node, consider DEF/USE to reduce download
>>>>>>> delays and memory requirements for url content
>>>>>>> (url='"textures/lambert2_metallicRoughness.png" "
>>>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/textures/lambert2_metallicRoughness.png"')
>>>>>>> [/X3D/Scene/Transform/Transform/Transform/Transform[1]/Transform/Group/Shape/Appearance/PhysicalMaterial/ImageTexture[4],
>>>>>>> warning]
>>>>>>> - provided DEF, USE ='MetallicRoughness' while preserving
>>>>>>> containerField values
>>>>>>>
>>>>>>> Gave it a white background for better visibility.
>>>>>>>
>>>>>>> Added identifying WorldInfo.
>>>>>>>
>>>>>>> When I ran the model through X3DJSAIL to reduce precision from 15
>>>>>>> digits to 8 digits after decimal point, file size went from 867KB to 471KB.
>>>>>>> I think we can safely go down to 6 digits (micrometer resolution). Such
>>>>>>> reduction is valuable for large models, converters can have a switch for
>>>>>>> lossless/lossy conversion as an option.
>>>>>>>
>>>>>>> Now online at
>>>>>>>
>>>>>>> - X3D Example Archives: X3D4AM, X3D for Advanced Modeling, Gltf
>>>>>>> Sample Models, Cat By Muru Scene
>>>>>>> - Converted glTF model showing use of Tangent node
>>>>>>> -
>>>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/CatByMuruSceneIndex.html
>>>>>>>
>>>>>>> Castle and X_ITE look similar, X3DOM looks quite different (likely
>>>>>>> differing application of PBR textures).
>>>>>>>
>>>>>>> <image.png>
>>>>>>> <image.png>
>>>>>>>
>>>>>>> <image.png>
>>>>>>>
>>>>>>> all the best, Don
>>>>>>> --
>>>>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>>>>> Relative Motion Consulting https://RelativeMotion.info
>>>>>>> <https://relativemotion.info/>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 2, 2026 at 5:05 PM Michalis Kamburelis <
>>>>>>> michalis.kambi at gmail.com> wrote:
>>>>>>>
>>>>>>> I provided 3 sample models using Tangent in my answer to Don in
>>>>>>> thread "[x3d-public] Specification review progress: PNG3, Tangent
>>>>>>> node, HAnim weekly progress" on July :)
>>>>>>>
>>>>>>> See
>>>>>>> https://github.com/castle-engine/demo-models/tree/master/bump_mapping/tangents
>>>>>>> . It's probably easiest to "git clone" the whole repository
>>>>>>> https://github.com/castle-engine/demo-models to have all additional
>>>>>>> files (like textures).
>>>>>>>
>>>>>>> Details:
>>>>>>>
>>>>>>> - They look pretty and have been created by actual artists :)
>>>>>>> Original
>>>>>>> versions obtained in glTF format from Sketchfab.
>>>>>>>
>>>>>>> - They are on versions of Creative Commons licenses. So it's OK to
>>>>>>> reuse them, if you credit the authors. 2 of them on CC-BY-4.0 (so
>>>>>>> even
>>>>>>> commercial usage is allowed, you just need to credit the authors). 1
>>>>>>> of them on CC-BY-NC-SA-4.0, so no commercial usage allowed (don't
>>>>>>> know
>>>>>>> if it's a problem for X3D Examples Archive).
>>>>>>>
>>>>>>> - They were created by converting glTF versions to X3D using Castle
>>>>>>> Model Viewer.
>>>>>>>
>>>>>>> - I removed some CGE extensions from them (they don't contain
>>>>>>> animation in any way, including Skin), but admittedly I didn't test
>>>>>>> them in other browsers. Reports about compatibility with other X3D
>>>>>>> browsers are welcome. If there's anything non-spec-complaint in these
>>>>>>> examples -> let me know and I'll fix it.
>>>>>>>
>>>>>>> - Note that the models only make sense together with all the
>>>>>>> textures,
>>>>>>> they have textures in "textures/" subdirectory.
>>>>>>>
>>>>>>> - They are also larger files. I recall I tried to create some "more
>>>>>>> minimal" test, but from what I recall they just looked ugly /
>>>>>>> non-sensical :)
>>>>>>>
>>>>>>> Regards and have a great 2026 everyone ! :),
>>>>>>> Michalis
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> pt., 2 sty 2026 o 07:33 Don Brutzman <don.brutzman at gmail.com>
>>>>>>> napisał(a):
>>>>>>> >
>>>>>>> > happy 2026! i hope everyone is well.
>>>>>>> >
>>>>>>> > FYI i have deployed updates and support for draft x3d 4.1
>>>>>>> development and will announce soon...
>>>>>>> >
>>>>>>> > X3D Specifications: Schema and DOCTYPE Validation
>>>>>>> > https://www.web3d.org/specifications
>>>>>>> >
>>>>>>> > I was looking back through prior mail and had trouble finding some
>>>>>>> examples...
>>>>>>> >
>>>>>>> > If any of you have a simple X3D example for FontLibrary, or for
>>>>>>> Tangent node, I'd be happy to add it to our X3D Examples Archive. This will
>>>>>>> help me test/confirm all the tools are working OK.
>>>>>>> >
>>>>>>> > Appreciate your considering this request, and all your many
>>>>>>> efforts.
>>>>>>> >
>>>>>>> > all the best, Don
>>>>>>> > --
>>>>>>> > X3D Graphics, Maritime Robotics, Distributed Simulation
>>>>>>> > Relative Motion Consulting https://RelativeMotion.info
>>>>>>> <https://relativemotion.info/>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260119/9ff30084/attachment-0001.html>
More information about the x3d-public
mailing list