Godot: Bone indexes messed up when importing COLLADA from 3DS Max (OpenCOLLADA)

[and3rson]

Godot version:
3.1-beta4

OS/device including version:
ArchLinux rolling

Issue description:

Godot should have option to force sorting of bones when importing COLLADA model to make bone indexes deterministic. We're currently having a nightmare adding rigged cosmetic items to our characters because the bone order is different all the time.

Consider this skeleton:

• Pelvis (0)
  
  
  
  • Spine
    
    
    
    
    
    • ...
    
    
    
  
  
  • L_Thigh
    
    
    
    
    
    • ...
    
    
    
  
  
  • R_Thigh
    
    
    
    
    
    • ...
    
    
    
  
  

If L_Thigh and R_Thigh XML blocks are swapped in DAE (happens for some reason; thanks 3DS Max), then their indexes will change during import into Godot. This makes imported mesh no longer compatible with the same base skeleton that was imported from a different DAE file.

TL;DR

Godot should have ability to force bone sorting by their names to preserve their indexes. I consider this a bug in Godot because DAE itself uses string identifiers internally. Thus DAE is not prone to errors when bone order is different, but Godot DAE importer degrades string identifiers into integer indexes.

Steps to reproduce:

1. Import DAE with some skeleton and mesh.
2. Import a different DAE with a different mesh rigged to the same skeleton.
3. Observe difference in bone indexes of those 2 meshes.

[fire]

After collada is converted to the in memory representation and before the internal format, the resulting list should be sorted and then the order of adding wouldn't change.

That sounds doable.

[fire]

Busy, but the idea is to sort the skeleton_bone_map after they're populated.

https://github.com/godotengine/godot/blob/70689ebffd95ab34e45bcbfdce3f6389033bfd44/editor/import/editor_import_collada.cpp#L147

Map > skeleton_bone_map;

[and3rson]

Right! _populate_skeleton is called recursively in its last lines, so we could sort p_node->children before iteration.
That would be sufficient for skeleton matching (as long as bone hierarchy remains the same.)

[fire]

You would not sort it, but use a array of nodes that have been sorted.

[akien-mga]

Can anyone still reproduce this bug in Godot 3.2.1 or any later release (e.g. 3.2.2-rc2)?

If yes, please ensure that an up-to-date Minimal Reproduction Project (MRP) is included in this report (a MRP is a zipped Godot project with the minimal elements necessary to reliably trigger the bug). You can upload ZIP files in an issue comment with a drag and drop.