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