Joint nodes have "skeleton" property, which is only used to specify which of the parent nodes is the skeleton that Joint should be related to. In current implementation the skeleton node should belong to the same hierarchy as the Joint node, which makes no room for the end user to use this property freely. Only one Skeleton node can be in one hierarchy and only this node can be set to all the children Joint nodes.

Suggestion:

1) Remove this property and deduce the skeleton node internally (i.e. without explicitly specifying it in qml). That can be done by iterating through all parents to the first Skeleton node.

2) Or make it possible to specify skeleton node which doesn't belong to the Joint hierarchy.

In 6.1.0B3, if Skeleton node from another hierarchy is set, the skeleton doesn't work. I.e. rotating/translating the Joint nodes doesn't affect the meshes which have the joints on the skin list (Is it a bug or expected behavior?).

Second option, in my opinion, is preferable as the only purpose of skeleton nodes is to provide a set of joins for matching them with inverse bind poses of the meshes. Keeping Skeleton nodes away from node hierarchies would make more sense and that would better fit glTF2.0 and FBX concepts which technically have no skeleton nodes at all (see SimplSkin.gltf by KronosGroup).

In current implementation Balsam tool on loading gltf models has to deduce where Skeleton nodes should be inserted and so do programmers who implement own loaders. It doesn't always work the expected way and the result looks incorrect (RiggedSimple example by KronosGroup). Placing skeleton nodes away from hierarchies would make the result node hierarchy identical to the hierarchizes in model files. It would make the skeleton position deducing algorithm in Balsam obsolete and not needed and simplified work for those who use QtQuick3D and implement own model viewers/editors/loaders.

Current implementation forces to analyze node hierarchies for places where skeleton nodes should be inserted. If two or more meshes share nodes from different skeletons, the skeletons have to be merged and a common root has to be found where a skeleton node should be inserted. Beside that:

• all unweighted meshes have to be moved out of the hierarchy to have them correctly rendered (+1 new node hierarchy with duplicate joins but without Skeleton node) or the skeleton property has to be set to null;
• for all weighted meshes position of each vertex has to be updated accordingly;
• all joint node indexes should be updated as well as related inverse bind posses;
• if a mesh is skinned for say only joint #100, the inverse bind pose array should consist of 99 identity matrices and 1 inverse bind pose for join #100;
• that also opens a question why there is "skeletonRoot" property if it is deduceble and can't be freely operated.

3) Another option would be to get rid of skeleton node and add another array with node indexes next to "inverseBindPoses" property, let's call it "jointIndices".  If this idea is accepted, I would also suggest that in "JointSemantic" attribute should be kept not absolute joint indices, but indices (positions) of the "jointIndices". In that case if an index of a joint is changed, it would be enought to update the "jointIndices" without updating all meshes (which is expensive in current implementation if there are a lot of heavy meshes + they have to be uploaded to graphics memory).

Positive aspects:

• no Skeleton node required;
• inverseBindPoses contain only needed matrices;
• meshes don't have to be updated if joint indices are changed.
• gltf and fbx file data doesn't have to be specifically processed before loading to Quick3D scene.