How to have a `CharacterBody3D` operate with multiple `Bone` following `CollisionShape3D`s?

Godot Version

4.2.1.stable.mono

Question

Before we start! Here’s an image so you can get a better idea of what I am talking about:


Hello all! I am creating an NPC that is a, uhhh hand called a Crawler, and I have a few requirements for it.
REQUIRMENETS:
1.) I would like the root node to be of type CharacterBody3D, that way I can have collision with the environment and can control the responses to collisions within code.
2.) I need each finger tip Bone to have a CollisionShape3D “attached” to it, that way the CollisionShape3D follows the Bone around in its animation.
3.) I would like the hand to move as if it is balancing on its fingers when in the “walking animation”.

I cant make the Bone following StaticBody3Ds the collision shape children for the CharacterBody3D root Node because the CollisionShape3Ds must be DIRECT children of the CharacterBody3D and cannot be grand-children. Is there a single solution that could fulfill all three of these requirements, and is considered the standard?

I have a few more questions, I was thinking of making the StaticBody3D Nodes in the bones, into CharacterBody3D Nodes instead, could this cause unintended side affects? Would this conflict with the parent CharacterBody3D Node? Or would these children just be masked over?

Also how do CharacterBody3D Nodes act when manipulated in an animation player? Do they still fall from gravity? Or is their collision code overridden by the animation?

1 Like

First, I got to point out that your 3) point will be a hell to properly implement regardless of if there is or not any form of solution because having anything, in any game engine, reliably use multiple collisions as a source of “balance” without any form of stabilization/damping if bound to result in physics-related nightmares. For example, a car game might have 4 tire-like colliders which balance the vehicle, but such system needs each tire-like colliders to have some form of damping/spring-like adaptation to absorb the small kicks & irregularities that might sprout from the terrains’ irregularities/floats precision issues.

And here comes the simplest solution:
Don’t use the fingers as the main source of stabilization/balance.

How to do this?
Under the CharacterBody3D, uses a simple CollisionShape3D that represents the “ideal” position for the hand when standing. It doesn’t have to be the size or form of the hand as it only act as the “ground” detection.
Then animate the hand to visually balance around that “ideal” position within its own 3D space in the 3D software you use to animate it.

If you want dynamic fingers’ adaptation with the ground and environment, when it comes to simplest solution, there are 2 choices:

A) Use animations with an AnimationTree and dynamically check for collision/contact with each finger with Area3D set on each finger tips (or raycasts if you feel up to the task). This requires some understanding in maths & basics codes because you need to adapt in reverse the fingers & hands orientation based on the results from the Area3D’s of each fingers, but it’s relatively simple and with enough patience even a beginner could do it.

B) Cut the hand into its palm and set each individual fingers as separate nodes/models. Expose the bones (knuckles) from the balm and set each fingers as children of those exposed bones. Animation-wise, this is a LOT more simple than prior A) because you can animated each finger individually and without making uses of any mask or having to animated multiple states of multiple fingers. The main challenge is to set a proper “brain” function in the palm to controls the fingers or get values from it to know the state of each fingers and act upon it. This also requires proper skinning and rigging of the hands individual parts so that the fingers’ and the palm vertexes remain visually connected perfectly. An additional quality of this one is the fact that you can more easily enable and disable various checks/contact detection for each fingers if those are wasted, meaning it can be a ton more optimized for performances in the long run.

If you wonder why you can’t have exactly what you want with the CharacterBody3D, it’s because of how collisions work with that node. Each object collision have a sort of “range” (a box) from which collisions are checked. This allows the engine to avoid check for collisions between objects that are too far apart in a scene. (For example, if an apple is on a table, it doesn’t need to check if it’s touching the ceiling or the wall so the apple has a sort of box around it slightly bigger than its collider which tells the Physics engine if it’s close to another collider.) The box is generated when the physics engine initialize a new frame worth of collisions and, at that moment, any “changes” such as an animation state are not yet “loaded” in the frame. As such, at best, your fingers’ collision would only work with a single frame worth of data (the first frame of the T-pose or whatever base animation is set on the mesh). It’s possible to retain a limited amount of the previous frame worth of data for the collision on a frame, but that’s not implemented with the CharacterBody3D. For that, you will need to use a RigidBody3D instead. Using a RigidBody3D could result in what you want, but it has its own can of worms to work through because you’ll be working with pretty raw collision values. (As I previously mentioned, damping is a nightmare with raw collisions.)