[x3d-public] got sample X3D model for FontLibrary or Tangent? glTF conversion progress, tooltips, names, etc. EnvironmentLight
John Carlson
yottzumm at gmail.com
Mon Jan 12 19:07:40 PST 2026
Sorry for posting over you, Don.
I plan to migrate to X3D 4.1 soon, particularly X3DUOM. Can we have a
collection (zip?) of .x3d documents that implement X3D 4.1 soon?
I can probably search through the archives and create a zip, I just want to
make sure not to duplicate efforts.
Thanks!
John
On Mon, Jan 12, 2026 at 12:18 PM Don Brutzman via x3d-public <
x3d-public at web3d.org> 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/>
>>>
>>>
>>>
>> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260112/fcceec7c/attachment-0001.html>
More information about the x3d-public
mailing list