[x3d-public] got sample X3D model for FontLibrary or Tangent? glTF conversion progress, tooltips, names, etc.

Don Brutzman don.brutzman at gmail.com
Sat Jan 10 19:45:07 PST 2026


[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


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/20260110/78fdbd59/attachment-0001.html>


More information about the x3d-public mailing list