Skeletons as a Resource

[Yuno117]

The current skeleton implementation, while being very functional, it does not allow sharing/reusing skeleton data between different meshes within different character setups/scenes. Animation libraries enable the reuse/sharing of animation data, but each character still maintains it's own Skeleton node with skeleton data baked in.

In order to truly share skeleton data I suggest separating skeleton data from the skeleton node. Similar to how mesh resources are used, skeleton data would become a resource that can be assigned to a skeleton node within a character's scene. When assigned to a skeleton node, an instance of that skeleton would be used so each character can apply it's own animation. Skeleton3D nodes would therefore become SkeletonInstance3D.

[TokageItLab]

If this were true, then simply changing the current parent-child relationship between Skeleton3DNode and MeshInstance (by simply replacing MeshInstance with another model) should work well, but it doesn't occur in real.

There are many obstacles to mesh binding, and Skeleton requires model-specific bone rest data and etc.

It would be possible to provide some API using SkeletonProfile to unify the bone names, but I think it doesn't makes sense to make the skeleton itself a resource.

[johnyc90]

Sorry if I'm late for the discussion but I would like to add a little bit further on this. While I agree that the binding provides a difficulty on its own, doesn't that come from how data is organized between the mesh and its data structures?

I know Godot isn't a 3D DCC, and as such isn't bound to the same methodologies. But if I have mesh models that could be skinned to the same skeleton (modeled from the same base mesh, with the same proportions and base pose) I can do it, and share this data across those objects.

A common use case (at least in AAA games) is to have multiple characters modeled from the same base templates, and thus fitting a body plan that allows them to share the skeleton. Similarly with body parts that can be swapped without ever touching the skeleton.

And forgive me if I'm wrong, because I haven't dabbled with this on Godot yet, but the proposal makes absolute sense to me, despite being a pain in the a** to deal with due to how data is structures now on the engine.

I found this proposal looking for this same question, and once I get into this subject, I would love to help and try implementing this. Can someone please elaborate on any reasoning to why this proposal wouldn't be fitting for Godot?

[TokageItLab]

First, you need to understand the difference between a Resource and a Node.

A resource is data that can be referenced by multiple Nodes. For example, if NodeA and NodeB reference ResourceX, changing ResourceX will cause the same change in NodeA and NodeB.

So at least it makes no sense for a Resource to be data that should be unique to a Node, such as the Pose transform.

It possibly makes sense to separate only the Rest transform and Bone name which is not changed frequently for each Node, but if there is a case that anyone want to add a unique bone for each Node that would make it complicated since to do that the Resource would have to be duplicated each time. Also if pose and rest are in different places, synchronization of bone indexes when changing the number of bones, etc. can also be a problem.

If you want to share a skeleton across multiple models as the base, you can simply Duplicate the base Skeleton. Conversely, the only case where it makes sense to use a Resource is when you want all the Duplicated Skeletons to reflect changes made to the Rest transform or bone name. However, I think that is not common case.

[johnyc90]

Sorry for the late reply. I see your point, although I don't quite agree with some of the conclusions.

It is an industry standard to use skeleton information as separate data exactly because sharing skeleton data isn't an edge case. AAA games use as little as possible skeletons for as many generic characters as possible. Doesn't that on its own make this a common use case?

Even Unreal does it, separating the skeletal mesh and skeleton mesh as separate data files.

The interesting thing with this proposal is that it effectively gives the user separation between these different kinds of data and allows the user to organize it as needed, and allowing a better memory management strategy.

If the user intends to share skeletons between meshes, today, the skeleton will be kept on a separate packed scene that will effectively be used as a resource, but without any of its benefits.

And if we want to keep the default behavior as it works today (in a node, in a scene), resources allow for that too! It's just a matter of saving it as Internal To Scene. And, if I'm not mistaken, when a skeletal mesh is imported in Godot, that's already what happens to the mesh that comes inside the gltf/fbx file being imported. It's becomes packed in the PackedScene that's generated for the file if you drag and drop it to a scene.

And again. I understand your previous points on the technical difficulties of making that change, and I'm not arguing that. Neither do I want this discussion to become uncivil. But why the push back ? There are a ton of valid reasons to make this kind of change, based on use cases:

• multiple characters sharing a skeleton (because they were rigged under the same one).
• hot swapping of skeletons if needed to create different bone hierarchies (don't know if there are other ways to do that in Godot today) for different appendages.
• even for making your mesh misbehave because you plugged the wrong skeleton data on your node, but that created a fun feature in the process.

Specially if this can be done without disrupting too much the current way of doing it.