You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Skeleton.find_bone() function is too slow with complex skeletons that have many bones.
While this was always the issue with find_bone() even far back as in Godot 3 the issue with its slowness is now amplified due to other more recent changes to skeletons and the asset import.
E.g. in Godot 4 the asset importer adds extra bones for each bone attachment. You end up with a lot more bones than usual to search. If you have 100 meshes all parented to the same bone in e.g. Blender you end up with 100 extra bones in Godot.
Godot 3 did not add extra bones for each bone attachment but this was apparently changed to solve other bugs with index shuffling like #64512 and #61641.
The old workaround of using the bone index instead of the name to do e.g. runtime skeleton mods does not work well now that the bone index are shuffled still with every changed attachment that adds new bones. The current situation requires to use a custom cache for bone name to bone index instead of using the slow Skeleton find_bone() function.
The solution could possibly be to use an internal HashMap for bone_name_to_bone_index instead of the current find_bone() loop that goes over the entire bone array everytime.
Godot version
c3ed7af
System information
Windows 10
Issue description
The Skeleton.find_bone() function is too slow with complex skeletons that have many bones.
While this was always the issue with find_bone() even far back as in Godot 3 the issue with its slowness is now amplified due to other more recent changes to skeletons and the asset import.
E.g. in Godot 4 the asset importer adds extra bones for each bone attachment. You end up with a lot more bones than usual to search. If you have 100 meshes all parented to the same bone in e.g. Blender you end up with 100 extra bones in Godot.
Godot 3 did not add extra bones for each bone attachment but this was apparently changed to solve other bugs with index shuffling like #64512 and #61641.
The old workaround of using the bone index instead of the name to do e.g. runtime skeleton mods does not work well now that the bone index are shuffled still with every changed attachment that adds new bones. The current situation requires to use a custom cache for bone name to bone index instead of using the slow Skeleton find_bone() function.
The solution could possibly be to use an internal HashMap for bone_name_to_bone_index instead of the current find_bone() loop that goes over the entire bone array everytime.
Steps to reproduce
Minimal reproduction project
see steps
The text was updated successfully, but these errors were encountered: