HAnim's "center of rotation" and glTF's TRS (translation/rotation/scale) are solving related but distinct problems, and conflating them causes confusion when converting rigs between the two.

HAnim's center of rotation is a semantic property of a joint node — it defines the anatomical pivot point (e.g., the elbow's true hinge axis) independent of how the mesh is authored or where the parent coordinate system happens to sit. It's declared explicitly per joint so that any animation engine can rotate the limb correctly regardless of skin/mesh offsets. Pros: anatomically meaningful, portable across engines that understand HAnim semantics, decouples "where the bone visually is" from "how the mesh deforms." Cons: it's an extra, HAnim-specific concept that generic 3D tools and formats don't natively understand — it has to be translated into local transforms to actually be used.

glTF's TRS  is purely a generic scene-graph mechanism: each node stores its own translation, rotation (quaternion), and scale relative to its parent, and rotation always happens around the node's own local origin — there's no separate "pivot" field. Pros: simple, universal, efficient for renderers/engines (three.js, Babylon, Unity importers, etc.), trivially composable into matrices. Cons: because there's no explicit pivot, an HAnim joint's center of rotation must be "baked in" by placing the node's origin exactly at that pivot point (and offsetting the mesh/skin accordingly) — if that translation is done carelessly, joints rotate around the wrong point and limbs distort.

In short: HAnim centers of rotation are a *modeling/semantic* concept for correct skeletal pivots, while glTF TRS is a *generic transform* mechanism with no innate pivot concept — so exporting an HAnim skeleton to glTF requires manually encoding each joint's center of rotation as that node's local origin/translation to preserve correct motion.