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.)