SpringArm(3D) can tunnel into objects with Godot physics but doesn't with Bullet

[Wolfe2x7]

Godot version:
3.2.2 stable, now 3.2.3 stable, up to 3.2.4 rc5

OS/device including version:
Linux Mint 20.1 Cinnamon
Lenovo Y540

Issue description:
EDIT: See this comment below for an updated description.

Original description:
This might seem weird, but I have been building a car simulation using SpringArm nodes in place of a raycast-type model. I've had three very good reasons for this:

1. It offers the ability to cast a shape out of the box with no code; a SphereShape is preferable to a RayCast.
2. It sidesteps issues I've had with bumpy collisions ([Bullet] 3D RigidBody collisions with static collision shapes still bumpy #46596 for example); it is perfectly smooth over all surfaces.
3. It automatically positions its children at the point of collision, which is totally convenient for the wheels (especially when displaced by the SphereShape with a matching radius).

(On a sidenote, in light of item two above, maybe the SpringArm's collision code could inspire a fix for bumpy collisions? I dunno. It just plain works.)

However, to do this, I have been forced to use Bullet physics. Godot physics fails to produce the same result. With the recent news touting the performance of Godot physics, I just tried it again in 3.2.4 rc5 and it still acts strange.

In 3.2.3, the SphereShape just sinks into the ground and no suspension force is generated from my code. It's worth mentioning that I also have a RayCast as a child of each SpringArm, which checks for a collision before applying any force (among other things).

In 3.2.4 rc5, my model now appears to work some of the time with Godot physics, but occasionally one or more wheels will sink and my framerate gets slammed from 144fps to around 10fps!! I could not reliably reproduce that in a minimal project, but in 3.2.3 the attached project demonstrates the problem 100% of the time.

(EDIT: See comment below for why the framerate dropped. It's because the sunken wheel allowed the collision shape to make contact.)

I took a screenshot of the issue affecting my project in 3.2.4 rc5:

Steps to reproduce:
Place SpringArms under a RigidBody with a SphereShape for a shape, point them down, and use its get_hit_length() and spring_length values to apply Hooke's law. It's so convenient. :)

The project below has a simplified car arranged to drop onto a ramp. Toggle the physics engines and observe the difference.

Minimal reproduction project:
springarm_springs.zip

[Wolfe2x7]

Good news! I have successfully isolated the problem with the severe framerate drop -- it is related to #41522 or something, because it is caused by the single convex collision shape Godot generates from a simplified version of my car body mesh. I always knew the collision shape was very messy, but something already being worked on.

This is what 3.2.3 generates:

This is generated by 3.2.4rc5:

Replacing the shape with either a built-in shape or a multiple convex collision shape (generated in 3.2.4rc5) eliminates that terrible spike, and recreates the behavior seen in 3.2.3. So the reproduction project I submitted isolates the specific issue here.

Furthermore, using a "debug jump jet" on the car to lift it and gently set it down, the wheels can sometimes remain above ground for a short time. But they really prefer to pass through in Godot physics, and they snag on some triangle edges. I imagine this could affect the SpringArm's intended use as a parent of a camera, like #38037.

I am at a complete loss for how 3.2.4rc5 actually allowed me to drive around a little bit with a single convex shape and Godot
physics, behaving almost like my sim does in Bullet. It won't cooperate anymore.

EDIT: I have re-discovered the framerate drop back in 3.2.3 stable, and in Bullet physics. It is not as severe, dipping from 144fps to 80-100fps with the same bad single convex shape when it makes contact. I will use a multiple convex shape now. The single has always printed the errors in #45946. The multiple does not.

[Wolfe2x7]

Godot version:
4.0 Beta 5

Hello again! I have now figured out the nature of this issue, up to the brand new Beta 5. I'm checking out Godot 4, and it only has Godot physics, which means poking around with Godot physics. 🐺

I also know more of what I'm doing now. 😅

Here's the specific issue and the difference. With Godot Physics, when a SpringArm(3D) is assigned a shape, the spring extends to its full length if the shape is still in contact with anything when it is pressed to the origin of the SpringArm(3D) node. If the shape is protected from contact, the node works better (still flickering in and out of contact/tunneling within some hundredths of units), otherwise, the collision detection quits responding and even tunnels into thick convex shapes.

Bullet doesn't do that; for this kind of a use case Bullet produces more of an "elastic" effect when the shape is pinned to the origin; it only ever pops through when the SpringArm's origin point passes beyond a flat static mesh.

I've prepared a new minimal reproduction project for Godot 4:
SpringArm3DTunneling.zip

Collisions for this node aren't as dependable with Godot physics as with Bullet physics. Fortunately, Godot 4 has ShapeCast3D, so I'm not out of luck yet.

[Wolfe2x7]

I'm back again. I did not get around to experimenting with ShapeCast3D until now.

I have discovered in 4.0 RC1 that the ShapeCast3D node exhibits the same behavior as the SpringArm(3D), apparently for the same reason. The actual problem is much clearer now than this issue makes it out to be, so I have elected to close this issue and open a new one with a better explanation: #72995

It is not my intention to reopen the issue only because it has not been answered. The results from the ShapeCast3D node lead me to believe this could be relatively easy to fix, and that a fresh issue would be more helpful.