[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 21:58:53 PST 2026
>
> Hopefully, an example is forthcoming. At this point, it’s unclear whether
> /HAnimPose is a Group/ will be handled or not.
The test example was published and reported 14 DEC 2025.
- X3D Example Archives: Humanoid Animation, Poses, HAnim Pose Example
- Define an experimental new node to simply capture a single pose for an
HAnimHumanoid model.
-
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Poses/HAnimPoseExampleIndex.html
HAnimPose is not a grouping node. HAnimPose can be contained consistently
in the children field of grouping nodes, and in HAnimHumanoid. Validation
tools, Java and Python libraries are all updated to match. All links are
available for checking in the X3D Tooltips, as usual.
- X3D Tooltips, HAnimPose
- https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimPose
To my knowledge we only have one implementation so far, an X3D prototype
using JavaScript and testable in X_ITE/Playground/Sunrize.
- X3D Example Archives: Humanoid Animation, Poses, HAnim Pose Prototype
-
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Poses/HAnimPosePrototypeIndex.html
Node design is stable. Further native-node implementations welcome. Have
fun with HAnimPose! 😀
all the best, Don
--
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting https://RelativeMotion.info
On Mon, Jan 19, 2026 at 9:06 PM John Carlson <yottzumm at gmail.com> wrote:
> Hopefully, an example is forthcoming. At this point, it’s unclear whether
> /HAnimPose is a Group/ will be handled or not.
>
> On Mon, Jan 19, 2026 at 9:26 PM Don Brutzman via x3d-public <
> x3d-public at web3d.org> wrote:
>
>> 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
>>>>>>>>> fr
>>>>>>>>>
>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260119/3efb290f/attachment-0001.html>
More information about the x3d-public
mailing list