[X3D-Ecosystem] Castle-model-converter HAnim glTF to X3D

[John Carlson]

I suggest you add an option, if possible, to either export glTF or HAnim
compatible animation.   Then everyone should be happy.

John
On Tue, Sep 2, 2025 at 7:33 AM Michalis Kamburelis <michalis.kambi at gmail.com>
wrote:

> Castle Game Engine, Castle Model Viewer, Castle Model Converter
> naturally can convert glTF to X3D, in general :)
>
> Such conversion is actually our only way we handle any 3D format. That
> is, we handle all 3D formats (glTF, IFC, Collada, OBJ...) by
> internally converting their contents to X3D nodes (but with some
> CGE-specific extensions sometimes). So, a nice side-effect of this
> approach, is that when we can display some format -> then we
> necessarily can also convert from that format to X3D (but, again, it
> can be "X3D with some CGE-specific extensions"). Of course, when we
> directly load X3D or VRML files, then there's no conversion.
>
> However, I understand you ask specifically about converting "glTF
> skinned animation" to X3D, and more specifically to X3D H-Anim.
>
> Answer with all the details is on
> https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D
> , please read section "Skinned mesh animation" there. In short:
>
> 1. What we currently do on CGE master branch is: We precalculate glTF
> skinned animation -> X3D coordinate interpolators at loading.
>
>    It "does the job", it practically works for a "normal" use case
> (user loads glTF and wants to run skinned animation designed there),
> but it was never our "final" solution :) It costs memory, it costs
> loading time, and it doesn't enable run-time joint transformation
> (like for inverse kinematics). So we work on a better solution, see AD
> 2:
>
> 2. We have a much better solution in a branch (not yet merged into
> master) and documented in https://castle-engine.io/skin . This is
> converting glTF skinned animation into new "Skin" node, documented on
> https://castle-engine.io/skin , which is "skinned animation approach
> perfectly aligned with glTF". It is not yet finished, I must fix some
> issues before merging, but on a branch results are already great -- we
> have super-fast skinned animation, loaded fast, animation is performed
> on GPU (CPU only updates joints, not vertexes), and conversion from
> glTF skinned animation -> to this Skin node is trivial.
>
>     This was also used for a (not open-source, done for one company)
> import of their motion capture format into Castle Game Engine. So we
> kind of proved that this approach A. works nicely to express glTF
> skinned animation, B. works nicely to express motion capture data.
>
>     This will also be an immediate answer to
> https://github.com/castle-engine/castle-model-viewer/issues/60 , once
> it will be merged. The Skin node and skinWeights0 / skinJoints0 etc.
> define all animation details.
>
>     The reason why we chose to convert glTF skinned animation -> to
> "Skin" node, and not to H-Anim, are better described on both above
> pages, read them :) https://castle-engine.io/skin ,
> https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D
> .
>
> So, above is our current (AD 1) and very-near-future (AD 2) state.
>
> 3. In the long run, we may also enable converting Skin node -> H-Anim
> nodes, just for the sake of converting glTF skinned animation into
> other X3D browsers (that will not support Skin, naturally, as it is,
> at least for now, CGE-specific extension).
>
>     Admittedly, this is not something that will happen immediately.
> Because practically speaking, conversion to our "Skin" node fills our
> primary need, which is to support glTF skinned animation, in a perfect
> way, for gamedev/3D visualization users who want perfect glTF support.
> It gives us efficient, GPU-based animation. It gives us per-shape
> weights/joints, so it's not limited to animating a single Coordinate
> node (see details in the linked https://castle-engine.io/skin ).
>
> So... that's our state :) AD 1 is "we have this right now", AD 2
> (Skin) is "we almost have it, it's in a branch", AD 3 (conversion glTF
> to H-Anim) is more long term.
>
> I fear there's a lot of opportunity for misunderstanding here, and I'm
> not making it easier on you by describing something that isn't
> testable on "master" branch yet :) So everyone please read the above
> webpages before questions "why did you just convert glTF skinned
> animation to H-Anim" :) It's also not merged yet, not available for
> testing using Castle Model Viewer snapshots, so I understand it's not
> easy for you to "see" it working.
>
> Please note that this is unrelated to glTF avatars and VRM. We don't
> handle them yet. Whether we will support them, and how, remains an
> open question. In practice, we have to see how popular / useful they
> are. For gamedev/3D visualization needs we have, current glTF skinned
> animation capabilities (including the fact that Blender armature can
> be perfectly exported to it) is actually already very much what we
> need.
>
> Regards,
> Michalis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-ecosystem_web3d.org/attachments/20250902/efc6f745/attachment.html>