[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 21:27:59 PST 2026
One question I have is, if I have Switch -1 in Blender import, do I ignore
the Switch except for DEF/USE? This might lose some important things. I
don’t know if Blender has an equivalent for Switch yet.
John
On Mon, Jan 19, 2026 at 10:57 PM John Carlson <yottzumm at gmail.com> wrote:
> 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/fe923d41/attachment-0001.html>
More information about the x3d-public
mailing list