COLLADA2GLTF does not enforce top-level skeleton node must be top-level glTF node

[pjcozzi]

See RiggedSimple.gltf and #624 (comment).

[lasalvavida]

@lexaknyazev Is there a compelling reason to force a top level skeleton node to be a top level node?

If not, it may be better to remove what seems like an arbitrary restriction to me.

[lexaknyazev]

Here's example layout:

• node_4
  • Armature
  • Bone
    • Bone_001
  • Bone2
    • Bone2_001
  • Cylinder

Skinned node (Cylinder) references Bone as its skeleton:

"Cylinder": {
  "meshes": [
    "Cylinder-mesh"
  ],
  "skeletons": [
    "Bone"
  ],
  "skin": "Armature_Cylinder-skin"
},

Since we've decided to forbid mixing skeleton nodes with non-skeleton nodes in one tree, we need to move Armature out of node4:

• node_4
  • Cylinder
• Armature
• Bone
  • Bone_001
• Bone2
  • Bone2_001

@pjcozzi said, that jointName has skeleton-tree scope. So how many skeleton-tree scopes are here:

• Two: (Bone + its children) and (Bone2 + its children), or
• One: (Armature + its children)?

With actual skeletons being top-level, we could also avoid extra parent transformations: Armature matrix could be pre-applied to Bone and Bone2.

[lexaknyazev]

@pjcozzi Could you confirm this restriction or should it be reconsidered?

[lasalvavida]

If this is something we want to do, I can pretty easily throw something into gltf-pipeline in the short term to correct the sampleModels. However, a collada2gltf fix is going to be a lot more involved.

[pjcozzi]

I am open to reconsidering this if it makes exporters/converters complicated. I don't like the idea of putting workarounds in gltf-pipeline ("output an invalid glTF then let gltf-pipeline fix it" is not the foundation we want to build on).

@lexaknyazev what does this improve for loaders? Is it significant? Perhaps the tradeoff isn't worth keeping it.

[lexaknyazev]

See my comment above. It's about defining local scope for jointName.

[pjcozzi]

Ah, OK.

@lasalvavida what is hard about updating COLLADA2GLTF?

One non-ideal solution could be to:

• Update the sample model by hand
• Have a COLLADA2GLTF issue and mark it as a known limitation, https://github.com/KhronosGroup/glTF/wiki/converter-limitations, perhaps with a workaround of how to update the source COLLADA model before conversion if possible.

[lasalvavida]

@lasalvavida what is hard about updating COLLADA2GLTF?

I'll see what I can do with COLLADA2GLTF. It just isn't super consistent with its memory management, so adding post-processing stages usually involves digging through SEGFAULTS.

[lexaknyazev]

Continuation:
KhronosGroup/COLLADA2GLTF#16