[x3d-public] got sample X3D model for FontLibrary or Tangent? glTF conversion progress, tooltips, names, etc. EnvironmentLight
John Carlson
yottzumm at gmail.com
Mon Jan 19 20:57:21 PST 2026
Indeed, I remember using Switch -1 in HAnim Blender export before. Maybe
I’ll try again.
On Mon, Jan 19, 2026 at 7:46 AM GPU Group via x3d-public <
x3d-public at web3d.org> wrote:
> Leaning toward Holger's take.
> -Doug
> freewrl isn't strict internally, it's just the xml parsing that needs help
> containerfield for some things that could be confusing / that have multiple
> fields a node could go in and type of child node doesn't discriminate.
> Forward DEFing: I've done it before in Switch choice -1 (nothing
> rendered), I modified a Blender export script to work like collada
> exporter, where most things are defined in a flat list above, and the
> transform hierarchy in the scene section. For the flat list part I defined
> everything in a Switch -1 children field, but I relied on some default
> action in the xml parsing code in freewrl. In theory there could be a
> special node for forward DEFing with only one field children, and then
> implied or stated containfield could be over-ridden in the xml parsing
> code. When parsing code can be tinkered with to make the right decision
> on containerfield, then it's simpler. For automatically generated tool
> code, generated from specifications, it would be harder.
>
> On Mon, Jan 19, 2026 at 4:11 AM Holger Seelig via x3d-public <
> x3d-public at web3d.org> 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.
>>>>>>>> <
>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260119/949347b7/attachment-0001.html>
More information about the x3d-public
mailing list