[x3d-public] got sample X3D model for FontLibrary or Tangent? glTF conversion progress, tooltips, names, etc. EnvironmentLight
Michalis Kamburelis
michalis at castle-engine.io
Wed Jan 14 02:04:25 PST 2026
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/20260114/130d20a7/attachment-0001.html>
More information about the x3d-public
mailing list