Give PhysicalBone3D continuous collision detection functionality to match RigidBody3D

[JohnTator]

Describe the project you are working on

A platforming game where the player is expected to utilize ragdoll physics.

Describe the problem or limitation you are having in your project

The current implementation of PhysicalBone3D is missing the ability to use Continuous Collision Detection. The only way to help stability otherwise is to increase the Physics Framerate to a very high number, which would come with a mountain of other issues. My game will allow the player to navigate levels via ragdoll physics, but currently the character will frequently clip into the ground and become stuck or worse when falling any notable distance. Not having the option for Continuous Collision Detection on ragdolls is a problem unique to Godot as other engines allow for this. The issue is significant enough to render the whole project unviable in Godot.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Godot users would be able to safely use PhysicalBone3D without Godot-unique-drawbacks. This flag that exists in its close cousin node RigidBody3D would help the node work as intended. I've tested this in other game engines and it works. In other words, the node would go from "unusable in a polished product" to "useable in a polished product"

Physical Bones were always meant to be a workaround for the inability to directly attach a Rigidbody to a skeleton bone as you can in other engines (Unity for example). The node is essentially a rigidbody + a joint + methods for interacting with a skeleton. it contains 90% of the rigidbody's code already, so not having CCD feels like missing an essential feature. (The same goes for several other disparities between the two nodes, impulses for example)

Adding this functionality will help bridge the functionality gap between making a ragdoll in Godot and making one in other game engines.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

To the best of my knowledge, all you would need to do is copy and paste the CCD functionality from Rigidbody3D into PhysicalBone3D. Considering how busy everyone is, I'm willing to learn how the source code operates and implement it myself if need be. If there are any guides that can assist me in getting this added to the Godot project myself it would be appreciated.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No. The node would need to be completely rebuilt from the ground up if going that route. The existing node would be useless. It would, however, only be a few lines of code in core.

Is there a reason why this should be core and not an add-on in the asset library?

The issue is that a core node is missing functionality that it rightly should have always had. It would be illogical to create an add-on rather than copy a few lines over in the engine's source.

[Calinou]

Continuous CD would need to be fixed first for this to be relevant.

If there are any guides that can assist me in getting this added to the Godot project myself it would be appreciated.

Unfortunately, there isn't any documentation for working on the physics engine itself. Physics engines are difficult topic to get into, so proficient contributors are few and far between. Note that the 3.x branch uses Bullet physics in 3D by default, but master uses a custom physics engine (called GodotPhysics) by default, which you can also choose to use in 3.x.

[JohnTator]

Continuous CD would need to be fixed first for this to be relevant.

Well darn, all the way back to 2017. Looks like physics in Godot just never worked to begin with. I wonder what other engines are doing right that Godot is doing wrong? As is, physics in Godot seem to be grossly neglected, which is a shame because they play such a vital role in 3D games. I hope it's eventually given the attention it deserves. Godot is probably the closest feature-parity alternative to commercial software like Unity and Unreal, but shortcomings like this prevent it from doing to game development what Blender did to 3D animation.