[x3d-public] got sample X3D model for FontLibrary or Tangent? glTF conversion progress, tooltips, names, etc. EnvironmentLight
Don Brutzman
don.brutzman at gmail.com
Thu Jan 15 14:33:25 PST 2026
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
> <environmentalTexturing.html#ImageCubeMapTexture> and Texture3D
> <texture3D.html#ImageTexture3D> 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
> <../bibliography.html#RAMAMOORTHI>).
>
> A description of the *global* field is in 17.2.1.2 Scoping of lights
> <#ScopingOfLights>. 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
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
>
>
> 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
>>
>>
>> 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
>>>
>>>
>>> On Mon, Jan 12, 2026 at 2:21 AM Holger Seelig <holger.seelig at yahoo.de>
>>> wrote:
>>>
>>>> A. There is a LICENCE file in the original folder:
>>>> https://github.com/KhronosGroup/glTF-Sample-Assets/blob/main/Models/SheenCloth/LICENSE.md
>>>>
>>>> C. Yes CannonExterior.avif can be deleted. I tested an EnvironmentLight
>>>> node, and removed it again because it’s still not supported by Castle. But
>>>> an EnvironmentLight is very important for PhysicalMaterial to see
>>>> reflections, metallic effects, brighter textures, and so on, otherwise
>>>> these material parts remain black or darker.
>>>>
>>>> D. Seems X_ITE should also switch to X3D4.1? 😃
>>>>
>>>> Best regards,
>>>> Holger
>>>>
>>>> —
>>>> Holger Seelig
>>>> holger.seelig at yahoo.de
>>>>
>>>> Am 12.01.2026 um 06:07 schrieb Don Brutzman <don.brutzman at gmail.com>:
>>>>
>>>> Thanks Holger.
>>>>
>>>> a. I was not able to figure out who the original creator was from the
>>>> README files or github history - "Microsoft" perhaps? Appreciate your
>>>> upgrading this.
>>>>
>>>> b. Commented out undefined field in ImageTexture: <!--
>>>> colorSpaceConversion='false' -->
>>>>
>>>> c. Was CannonExterior.avif used in this model, or should it be deleted?
>>>>
>>>> -
>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/CannonExterior.avif
>>>>
>>>> d. Changed X3D version to 4.1 since Tangent node is present
>>>>
>>>> e. Once again looks identical in X_ITE and Castle. 👍
>>>>
>>>> f. This was an important example to finally get added because it
>>>> revealed important gaps in X3D XML Schema and DOCTYPE. Now updated, along
>>>> with X3DUOM, X3DJSAIL, and X3D Ontology with X3DPSAIL x3d.py to follow.
>>>>
>>>> 11 JAN 2026, brutzman, seelig
>>>>> - (v4.0, v4.1) MultiTextureTransform can also contain
>>>>> TextureTransform3D and
>>>>> TextureTransformMatrix3D in addition to TextureTransform
>>>>
>>>>
>>>> - X3D Specifications: Schema and DOCTYPE Validation
>>>> - https://www.web3d.org/specifications
>>>>
>>>> g. Hopefully the publication efforts and metadata look good. Published
>>>> in version control and online at
>>>>
>>>> - X3D Example Archives: X3D4AM, X3D for Advanced Modeling, Gltf
>>>> Sample Models, Sheen Cloth
>>>> - MultiTexture model converted from glTF
>>>> -
>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/SheenClothIndex.html
>>>>
>>>> Have fun with advanced rendering using X3D! 😀
>>>>
>>>> all the best, Don
>>>> --
>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>> Relative Motion Consulting https://RelativeMotion.info
>>>> <https://relativemotion.info/>
>>>>
>>>>
>>>> On Sun, Jan 11, 2026 at 12:30 PM Holger Seelig <holger.seelig at yahoo.de>
>>>> wrote:
>>>>
>>>>> Here is a very simple example with only one shape that uses
>>>>> MultiTextureTransform (two different TextureTransformMatrix3D nodes) and
>>>>> MultiTextureCoordinate (where both TextureCoordinate node are actually the
>>>>> same). I have added a SheenCloth.x3d, converted with X_ITE. I have modified
>>>>> the original conversion file to make it work in Castle Model Viewer
>>>>> (removed the SheenMaterialExtension node, added proper NavigationInfo and
>>>>> Viewpoint, added MultiTextureCoordinate because Castle needs this, X_ITE
>>>>> uses the last TextureCoordinate if a mapping does not match). I attached
>>>>> the whole folder with all textures and the converted file SheenCloth.x3d.
>>>>>
>>>>> This file is originally from the glTF-Sample-Assets from Khronos:
>>>>>
>>>>> https://github.com/KhronosGroup/glTF-Sample-Assets/tree/main/Models/SheenCloth
>>>>>
>>>>> Best regards,
>>>>> Holger
>>>>>
>>>>> Am Sonntag, 11. Januar 2026 um 04:45:19 MEZ hat Don Brutzman <
>>>>> don.brutzman at gmail.com> Folgendes geschrieben:
>>>>>
>>>>>
>>>>> [cc: x3d-public since this topic has ballooned to be much bigger than
>>>>> originally expected]
>>>>>
>>>>> Background: working on putting two of Michalis' Castle Model Viewer
>>>>> examples for X3D 4.1 Tangent node into the X3D Example Archives.
>>>>>
>>>>> - X3D Example Archives: X3D4AM, X3D for Advanced Modeling, Gltf
>>>>> Sample Models, Cat By Muru
>>>>> -
>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/CatByMuruIndex.html
>>>>> -
>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/CatByMuruX_ITE.html
>>>>>
>>>>> and
>>>>>
>>>>> - X3D Example Archives: X3D4AM, X3D for Advanced Modeling, Gltf
>>>>> Sample Models, Halloween Pumpkin Lantern Knight
>>>>> -
>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/HalloweenPumpkinLanternKnightIndex.html
>>>>> -
>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/HalloweenPumpkinLanternKnightX_ITE.html
>>>>>
>>>>> =================
>>>>>
>>>>> Continuing, mostly finishing this long thread:
>>>>>
>>>>> Thanks Holger for the TextureTransform technique. I have applied that
>>>>> change in two models (CatByMuru.x3d and HalloweenPumpkinLanternNight.x3d to
>>>>> good effect.
>>>>>
>>>>> Have also added the following tooltip.
>>>>>
>>>>> - X3D Tooltips: TextureTransform
>>>>> -
>>>>> https://www.web3d.org/x3d/content/X3dTooltips.html#TextureTransform
>>>>>
>>>>> Hint: image flip horizontal <TextureTransform DEF='FlipHorizontal'
>>>>> scale='-1 1' translation='-1 0'/>
>>>>> Hint: image flip vertical <TextureTransform DEF='FlipVertical'
>>>>> scale='1 -1' translation='0 -1'/>
>>>>>
>>>>> Noticed that when you apply such a TextureTransform, it is a child of
>>>>> the parent Appearance node, and not part of each ImageTexture (like the CGE
>>>>> attribute). When there is an associated PhysicalMaterial and no mapping
>>>>> field is defined, that means the TextureTransform applies to all of the
>>>>> ImageTexture fields (baseTexture, emissiveTexture,
>>>>> metallicRoughnessTexture, normalTexture, occlusionTexture). Similarly for
>>>>> UnlitMaterial.
>>>>>
>>>>> Michalis, should I leave mapping="" blank throughout, or else apply a
>>>>> value there (perhaps mapping='flipVertical' throughout)?
>>>>>
>>>>> We don't appear to mention this case explicitly in the specification,
>>>>> but I think the prose is OK and does not allow any other interpretation.
>>>>> (We can add more words for clarity if anyone wants to.)
>>>>>
>>>>> - X3D Architecture version 4.1 draft, clause 12 Shape
>>>>> component12.2.2 Appearance characteristics
>>>>> -
>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shape.html#AppearanceCharacteristics
>>>>>
>>>>> Also thanks Michalis, I have added generateMipMaps='true' to
>>>>> TextureProperties nodes, and handled DEF/USE.
>>>>>
>>>>> - <TextureProperties DEF='AveragePixel' generateMipMaps='true'
>>>>> magnificationFilter='AVG_PIXEL' minificationFilter='AVG_PIXEL_AVG_MIPMAP'/>
>>>>>
>>>>> HalloweenPumpkinLanternKnight.x3d model is too large for X3DJSAIL to
>>>>> load, unfortunately (currently 2.6MB) and so I was not able to reduce the
>>>>> extra-long floats in there (no more than 7 digits of precision are needed).
>>>>>
>>>>> Michalis, the character
>>>>> dollar; $ <https://en.wikipedia.org/wiki/$> U+
>>>>> <https://en.wikipedia.org/wiki/Basic_Latin_(Unicode_block)>0024is not
>>>>> within the range allowed for XML NMTOKEN (name token) data type, and so it
>>>>> is not recommended for X3D model interoperability across all file encodings
>>>>> and programming-language bindings. See
>>>>>
>>>>> - XML Recommendation, v1.1 (Second edition), World Wide Web
>>>>> Consortium (W3C), 2.3 Common Syntactic Constructs, Names and Tokens
>>>>> - https://www.w3.org/TR/xml11/#sec-common-syn
>>>>>
>>>>> DEF/USE, proto and other names in X3D Example Archive models are
>>>>> always conservative for best interoperability, additional suggestions
>>>>> always welcome. Further details are maintained at
>>>>>
>>>>> - X3D Scene Authoring Hint, NamingConventions
>>>>> -
>>>>> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#NamingConventions
>>>>>
>>>>> Giving a node DEF='head' is legal, but it is confusing for the XML
>>>>> encoding, so I usually change things like that for clarity... which is
>>>>> often essential in the X3D Example Archives. Not sure if we should add
>>>>> 'head' to the list of reserved words.
>>>>>
>>>>> *Both the CatByMuru and HalloweenPumpkinLanternKnight models are
>>>>> looking good and looking consistent, both for Castle Model Viewer and
>>>>> X_ITE/Playground/Sunrize. Bravo!*
>>>>>
>>>>> X3DOM looks quite different (perhaps differing application of PBR
>>>>> textures in Physical Material node). Perhaps someone wants to work on that
>>>>> open-source codebase... examples in the X3dForAdvancedModeling
>>>>> GltfSampleModels directly provide a lot of excellent test cases for glTF
>>>>> compatibility, with many others working already.
>>>>>
>>>>> New issue: since multiple TextureTransform nodes might be needed
>>>>> within an Appearance, should we allow multiple TextureTransform nodes in
>>>>> Appearance? Right now that is an SFNode field. If you think there is a use
>>>>> case that an author (or converter) would want more than one
>>>>> TextureTransform in the Appearance node, please advise.
>>>>>
>>>>> - 12.4.2 Appearance
>>>>> -
>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shape.html#Appearance
>>>>>
>>>>> Appearance : X3DAppearanceNode {
>>>>> SFNode [in,out] acousticProperties NULL [AcousticProperties]
>>>>> SFFloat [in,out] alphaCutoff 0.5 [0,1]
>>>>> SFString [in,out] alphaMode "AUTO" ["AUTO", "OPAQUE", "MASK", "BLEND"]
>>>>> SFNode [in,out] backMaterial NULL [X3DOneSidedMaterialNode]
>>>>> SFNode [in,out] fillProperties NULL [FillProperties]
>>>>> SFNode [in,out] lineProperties NULL [LineProperties]
>>>>> SFNode [in,out] material NULL [X3DMaterialNode]
>>>>> SFNode [in,out] metadata NULL [X3DMetadataObject]
>>>>> SFNode [in,out] pointProperties NULL [PointProperties]
>>>>> MFNode [in,out] shaders [] [X3DShaderNode]
>>>>> SFNode [in,out] texture NULL [X3DTextureNode]
>>>>> SFNode [in,out] textureTransform NULL [X3DTextureTransformNode]
>>>>> }
>>>>>
>>>>> Have fun using glTF models in X3D! 😀
>>>>>
>>>>> all the best, Don
>>>>> --
>>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>>> Relative Motion Consulting https://RelativeMotion.info
>>>>> <https://relativemotion.info/>
>>>>>
>>>>>
>>>>> On Sun, Jan 4, 2026 at 1:11 PM Holger Seelig <holger.seelig at yahoo.de>
>>>>> wrote:
>>>>>
>>>>> Instead of a flipVertically field, it is also possible to achieve this
>>>>> with a TextureTransform node
>>>>>
>>>>> DEF FlipVertically TextureTransform {
>>>>> translation 0 -1
>>>>> scale 1 -1
>>>>> }
>>>>>
>>>>> Another solution is to flip all texture coordinates (y’ = 1 - y).
>>>>>
>>>>> After all investigations I think that Castle and X_ITE are on the
>>>>> right way representing glTF textures, but all the examples miss a
>>>>> flipVertically in either way.
>>>>>
>>>>> Best regards,
>>>>> Holger
>>>>>
>>>>> —
>>>>> Holger Seelig
>>>>> holger.seelig at yahoo.de
>>>>>
>>>>>
>>>>> Am 04.01.2026 um 01:32 schrieb Michalis Kamburelis <
>>>>> michalis.kambi at gmail.com>:
>>>>>
>>>>> Hello Don,
>>>>>
>>>>> Great, thanks for the analysis of the file and tests on other
>>>>> browsers! Answers:
>>>>>
>>>>> 1. flipVertically:
>>>>>
>>>>> - This is documented on
>>>>> https://castle-engine.io/x3d_implementation_texturing_extensions.php#section_flip_vertically
>>>>> , with reasons why.
>>>>>
>>>>> - We talked about it in the past on x3d-public already.
>>>>>
>>>>> - No, I don't think now that it deserves to be added to spec. Let it
>>>>> remain CGE extension. CGE should export with TextureTransform making this
>>>>> "flipVertically" unnecessary, and the files spec-conforming. Implementing
>>>>> this by "flipVertically" in CGE is just an optimization (see link above),
>>>>> effectively, since it's zero overhead to flip at loading. I feel it can
>>>>> remain CGE extension, actually.
>>>>>
>>>>> - So, give me time, I'll fix these models to not use flipVertically :)
>>>>>
>>>>> 2. $ in name:
>>>>>
>>>>> - I was under impression that $ is actually OK inside name in X3D. We
>>>>> use it in special situations (when "encoding" names with arbitrary chars
>>>>> from other formats) deliberately.
>>>>>
>>>>> - Spec
>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/grammar.html
>>>>> about "IdRestChars" implies $ is OK. ("$" is 0x24), from what I can tell.
>>>>>
>>>>> - CGE code derived from this is
>>>>> https://github.com/castle-engine/castle-engine/blob/7dccdbb455d544e3659d6f049cde9bcf428c3c86/src/scene/load/x3dloadinternalutils.pas#L82
>>>>> .
>>>>>
>>>>> - So: Are you sure "$" is not valid in X3D name? Where is this
>>>>> mentioned in spec? If that's the case -> no problem, I'll fix our code, and
>>>>> the test models.
>>>>>
>>>>> 3. """Wondering why you have those EXPORT statements"""
>>>>>
>>>>> - Our glTF->X3D converter EXPORTs some named nodes, to allow animation
>>>>> of them by the outer X3D file.
>>>>>
>>>>> - In short, it doesn't matter for these particular examples, these
>>>>> EXPORTS are not used in this case.
>>>>>
>>>>> 4. """<Transform DEF='head'/> has DEF name that illegally overrides a
>>>>> reserved word from the X3D Specification"""
>>>>>
>>>>> - I was not aware that such names are disallowed.
>>>>>
>>>>> - "head" is not mentioned as keyword on
>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/grammar.html
>>>>> .
>>>>>
>>>>> - It's not used by classic encoding, it's only an element name in X3D
>>>>> XML. I don't see how node name "head" could be really confused with element
>>>>> <head> in X3D?
>>>>>
>>>>> - That said, we could fix the model (and CGE converter). Can you show
>>>>> me where in the specification is the "head" for node name disallowed? I can
>>>>> add a logic to our converter to avoid "head" name then.
>>>>>
>>>>> 5. """<TextureProperties DEF=''/> requires generateMipMaps='true'
>>>>> since minificationFilter='AVG_PIXEL_AVG_MIPMAP""""
>>>>>
>>>>> - I'll fix it, indeed spec says "Mipmaps are required for filtering
>>>>> modes with MIPMAP in their value."
>>>>>
>>>>> - Note that CGE ignores this field. Only the filtering determines
>>>>> whether we need mipmaps... so to us, generateMipMaps field is actually not
>>>>> useful.
>>>>>
>>>>> - (And it could be confusing in case of files like DDS or KTX, where
>>>>> mipmaps are part of the image. In such case, we have mipmaps, we use them
>>>>> -> but we don't "generate" them).
>>>>>
>>>>> - Anyhow, that's all minor notes :) We can just place
>>>>> generateMipMaps='true'.
>>>>>
>>>>> 6. About the float precision: We have a --float-precision option to
>>>>> Castle Model Converter, it was just not used for this. I can indeed
>>>>> reexxport this with smaller precision.
>>>>>
>>>>> Summary: Give me time :) and I'll fix
>>>>>
>>>>> - AD 1 - flipVertically
>>>>> - AD 5- generateMipMaps
>>>>> - AD 6 - float precision
>>>>>
>>>>> in the models.
>>>>>
>>>>> For 2 other questions, I'll appreciate a link to spec :), but of
>>>>> course we could also adjust to them, nothing problematic there :) This
>>>>> applies to:
>>>>>
>>>>> - AD 2 - $ in name
>>>>> - AD 4 - "head" in name
>>>>>
>>>>> Regards,
>>>>> Michalis
>>>>>
>>>>> sob., 3 sty 2026 o 07:11 Don Brutzman <don.brutzman at gmail.com>
>>>>> napisał(a):
>>>>>
>>>>> Thank you very much for recovering those, Michalis!
>>>>>
>>>>> I copied all three and put originals in version control, and began
>>>>> work on first. Next step, ran/committed .x3d version through X3D
>>>>> Canonicalization (C14N) so that any changes which occur are evident. Also
>>>>> added a variety of meta tags.
>>>>>
>>>>> Validation diagnostics quickly found the following errors:
>>>>>
>>>>> - Attribute "flipVertically" must be declared for element type
>>>>> "ImageTexture". (now omitted, may look funny)
>>>>> - Attribute value "CastleEncoded_Pose_scene$46$fbx" of type IDREF
>>>>> must be an NCName when namespaces are enabled. (changed $ character to
>>>>> underscore _ character)
>>>>>
>>>>> If you would like to add *flipVertical *and *flipHorizontal *attributes
>>>>> to ImageTexture, or to interface X3DSingleTextureNode (ImageTexture,
>>>>> MovieTexture, PixelTexture), please propose that on x3d-public mail list.
>>>>> Seems plausible to me, if glTF has something like that then let's do it
>>>>> consistently. No need to add "ly" suffix to names of such boolean fields.
>>>>> If everyone reaches consensus (or interest at least) then I can add them to
>>>>> XML DOCTYPE and Schema for draft version 4.1.
>>>>>
>>>>> Continued work on other diagnostics...
>>>>>
>>>>> Wondering why you have those EXPORT statements?
>>>>>
>>>>> Got illegal DEF name warning, renamed 'head' to 'modelHead'
>>>>>
>>>>> - <Transform DEF='head'/> has DEF name that illegally overrides a
>>>>> reserved word from the X3D Specification
>>>>> [/X3D/Scene/Transform/Transform/Transform/Transform[1], error]
>>>>>
>>>>> Got several X3D Schematron warnings like this, do you agree?
>>>>>
>>>>> - <TextureProperties DEF=''/> requires generateMipMaps='true'
>>>>> since minificationFilter='AVG_PIXEL_AVG_MIPMAP' mode indicates MIPMAP
>>>>> rendering
>>>>> [/X3D/Scene/Transform/Transform/Transform/Transform[1]/Transform/Group/Shape/Appearance/PhysicalMaterial/ImageTexture[4]/TextureProperties,
>>>>> error]
>>>>> - looks like those three nodes are identical might be single DEF
>>>>> with one USE
>>>>>
>>>>> Got a Schematron warning to take advantage of DEF/USE, and so did that.
>>>>>
>>>>> - <ImageTexture DEF=''/> url array address(es) duplicate the url
>>>>> definition found in a preceding node, consider DEF/USE to reduce download
>>>>> delays and memory requirements for url content
>>>>> (url='"textures/lambert2_metallicRoughness.png" "
>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/textures/lambert2_metallicRoughness.png"')
>>>>> [/X3D/Scene/Transform/Transform/Transform/Transform[1]/Transform/Group/Shape/Appearance/PhysicalMaterial/ImageTexture[4],
>>>>> warning]
>>>>> - provided DEF, USE ='MetallicRoughness' while preserving
>>>>> containerField values
>>>>>
>>>>> Gave it a white background for better visibility.
>>>>>
>>>>> Added identifying WorldInfo.
>>>>>
>>>>> When I ran the model through X3DJSAIL to reduce precision from 15
>>>>> digits to 8 digits after decimal point, file size went from 867KB to 471KB.
>>>>> I think we can safely go down to 6 digits (micrometer resolution). Such
>>>>> reduction is valuable for large models, converters can have a switch for
>>>>> lossless/lossy conversion as an option.
>>>>>
>>>>> Now online at
>>>>>
>>>>> - X3D Example Archives: X3D4AM, X3D for Advanced Modeling, Gltf
>>>>> Sample Models, Cat By Muru Scene
>>>>> - Converted glTF model showing use of Tangent node
>>>>> -
>>>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/CatByMuruSceneIndex.html
>>>>>
>>>>> Castle and X_ITE look similar, X3DOM looks quite different (likely
>>>>> differing application of PBR textures).
>>>>>
>>>>> <image.png>
>>>>> <image.png>
>>>>>
>>>>> <image.png>
>>>>>
>>>>> all the best, Don
>>>>> --
>>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>>> Relative Motion Consulting https://RelativeMotion.info
>>>>> <https://relativemotion.info/>
>>>>>
>>>>>
>>>>> On Fri, Jan 2, 2026 at 5:05 PM Michalis Kamburelis <
>>>>> michalis.kambi at gmail.com> wrote:
>>>>>
>>>>> I provided 3 sample models using Tangent in my answer to Don in
>>>>> thread "[x3d-public] Specification review progress: PNG3, Tangent
>>>>> node, HAnim weekly progress" on July :)
>>>>>
>>>>> See
>>>>> https://github.com/castle-engine/demo-models/tree/master/bump_mapping/tangents
>>>>> . It's probably easiest to "git clone" the whole repository
>>>>> https://github.com/castle-engine/demo-models to have all additional
>>>>> files (like textures).
>>>>>
>>>>> Details:
>>>>>
>>>>> - They look pretty and have been created by actual artists :) Original
>>>>> versions obtained in glTF format from Sketchfab.
>>>>>
>>>>> - They are on versions of Creative Commons licenses. So it's OK to
>>>>> reuse them, if you credit the authors. 2 of them on CC-BY-4.0 (so even
>>>>> commercial usage is allowed, you just need to credit the authors). 1
>>>>> of them on CC-BY-NC-SA-4.0, so no commercial usage allowed (don't know
>>>>> if it's a problem for X3D Examples Archive).
>>>>>
>>>>> - They were created by converting glTF versions to X3D using Castle
>>>>> Model Viewer.
>>>>>
>>>>> - I removed some CGE extensions from them (they don't contain
>>>>> animation in any way, including Skin), but admittedly I didn't test
>>>>> them in other browsers. Reports about compatibility with other X3D
>>>>> browsers are welcome. If there's anything non-spec-complaint in these
>>>>> examples -> let me know and I'll fix it.
>>>>>
>>>>> - Note that the models only make sense together with all the textures,
>>>>> they have textures in "textures/" subdirectory.
>>>>>
>>>>> - They are also larger files. I recall I tried to create some "more
>>>>> minimal" test, but from what I recall they just looked ugly /
>>>>> non-sensical :)
>>>>>
>>>>> Regards and have a great 2026 everyone ! :),
>>>>> Michalis
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> pt., 2 sty 2026 o 07:33 Don Brutzman <don.brutzman at gmail.com>
>>>>> napisał(a):
>>>>> >
>>>>> > happy 2026! i hope everyone is well.
>>>>> >
>>>>> > FYI i have deployed updates and support for draft x3d 4.1
>>>>> development and will announce soon...
>>>>> >
>>>>> > X3D Specifications: Schema and DOCTYPE Validation
>>>>> > https://www.web3d.org/specifications
>>>>> >
>>>>> > I was looking back through prior mail and had trouble finding some
>>>>> examples...
>>>>> >
>>>>> > If any of you have a simple X3D example for FontLibrary, or for
>>>>> Tangent node, I'd be happy to add it to our X3D Examples Archive. This will
>>>>> help me test/confirm all the tools are working OK.
>>>>> >
>>>>> > Appreciate your considering this request, and all your many efforts.
>>>>> >
>>>>> > all the best, Don
>>>>> > --
>>>>> > X3D Graphics, Maritime Robotics, Distributed Simulation
>>>>> > Relative Motion Consulting https://RelativeMotion.info
>>>>> <https://relativemotion.info/>
>>>>>
>>>>>
>>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260115/3db120c7/attachment-0001.html>
More information about the x3d-public
mailing list