[x3d-public] [hanim] Depreciated HAnimHumanoid.joints field?

Michalis Kamburelis michalis.kambi at gmail.com
Mon Sep 29 01:26:51 PDT 2025


> The Castle viewer confirms that the fields are duplicative by automatically creating those USE nodes if missing or incorrect. See Mantis 1512]

Please don't use my viewer's hack (which is only a workaround for
invalid X3D models and it only works to some extent) as a
justification for this change in spec :)

In Castle Model Viewer, we introduced a hack to automatically fill the
"HAnimHumanoid.joints" field (scanning the "HAnimHumanoid.skeleton"),
because there have been some incorrect X3D files (also circulating on
this mailing list) that were missing the "HAnimHumanoid.joints" field.
This doesn't mean that my hack is fool-proof, and it is not a
justification for removing the "HAnimHumanoid.joints" from spec IMHO.

Having explicit list of "HAnimHumanoid.joints" is helpful, it provides
the joints list in a ready way, and the order is then clearly defined.
Which is important, as the order must match the jointBindingPositions
etc, as Holger reports. There are many details how one could enumerate
the children looking for joints, and misalignment here could be
undetected and result in weird effects -- you may get the same number
of joints, but in different order, and then animation will look
totally wrong.

glTF skinned animation specification, and CGE Skin node, also have
explicit list of joints. For similar reasons -- we need to know
indexes of joints, because if they get mixed up, all animation goes
wrong.

Please restore these fields, and make them required, as they were in
previous spec versions.

In all real-life use-cases, this information should be auto-generated
by the X3D exporter (from Blender, Maya, etc.), which should have this
information available without any trouble.

Regards,
Michalis



More information about the x3d-public mailing list