Add a project setting to adjust the number of physics solver iterations to fix CCD issues

[andyfreer]

Describe the project you are working on:

Describe the problem or limitation you are having in your project:

Various Github issues relating to CCD problems e.g. #16505

Describe how this feature / enhancement will help you overcome this problem or limitation:

Allow increased accuracy without increasing physics fps to v. high values... users can tweak solver iterations as part of the physics tuning for their particular config/requirements

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

Describe implementation detail for your proposal (in code), if possible:

Moving hardcoded settings to Godot UI e.g. here

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

no but you can change the hardcoded setting and recompile :)

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

[Calinou]

Out of curiosity, which value do other Bullet-using games typically use? Maybe we could tweak the default value to fit more use cases.

[DimitriyPS]

Maybe we could tweak the default value

There is no and cannot be a standard value. In one game, there is enough signal to fix the collision, and in another, and all the capabilities of the Bullet is not enough. Only the project author can determine the priority: performance or accuracy.

I’ve been in Godot since version 2.x, now it’s already on the horizon 4.0 ... There used to be a physical engine of Godot, now it’s a physical engine of Bullet ... Forgive me if I’m rude, but I’ll say as it is ..., the physics in all versions of Godot is invariably large a piece of shit. For show - yes, for a more or less serious project - it is impossible to use. I'm not talking about fashionable "features", it’s at least about the normal processing of solids ... it's a real pain ...

I'm Please, pray, adjure... include this in Godot 4.0!

[woodbyte]

I do believe having both global and per-rigid solver iteration values is indeed a must for any general purpose game engine, and seeing how little attention this issue garnered here is, I'll admit, quite disheartening.

Godot 3.x has many shortcomings when it comes to making 3D applications, but there's usually some way to get around them and still get the result one is looking for. That is, until you need to simulate a physics system of any complexity. Time and time again I've run into issues that have no solution outside of recompiling the engine itself.

Mind you, no real-time physics engine is perfect, they all have their quirks and that's OK. It's why other engines expose so much of the inner workings to the end user, so that it is possible to reach a reasonable compromise between performance and accuracy, depending on the specific requirements of the application you are making.

Godot is just too opaque in this regard, and therefore unusable for a large amount of use cases. Sadly, if the current state of Godot 4.0 (and its roadmap) is anything to go by, physics are not due for a significant upgrade in that release, either.

I'm begrudgingly moving on (or should I say back) to Unity for the time being, but I hope one day to return to this gem of an engine. It really is a pleasure to work with Godot (fastest iteration speed bar none!), at least when it's not trying to tie your hands behind your back.

[Calinou]

Sadly, if the current state of Godot 4.0 (and its roadmap) is anything to go by, physics are not due for a significant upgrade in that release, either.

We have a contributor working full-time on physics now: https://godotengine.org/article/camille-mohr-daurat-hired-work-physics

If you are having trouble implementing a character controller, look into reading Shifty's Godot Character Movement Manifesto.

Also, it is now possible to change the number of physics iterations in 2D: godotengine/godot#48827 (3.x counterpart: godotengine/godot#38387)
The feature isn't available in 3.3.2, but it will be starting from 3.4beta1.

A similar pull request is welcome for the 3D physics engines (Bullet and GodotPhysics).
Edit: Working on a PR for 3D GodotPhysics: godotengine/godot#50255

[woodbyte]

@Calinou Thanks for the quick reply and PR, that should be of help in some use cases.
I should add that my particular issue is actually not velocity/collision related at all, but rather on the constraint solver side.

Basically, both Bullet in 3.x and GodotPhysics3D (in the master branch), have trouble finding good solutions when a system has more than just a handful of interacting joints. The first few added joints (or those of higher priority) are stable and able to maintain their relative positions, but later ones quickly drift apart, leading to unexpected behavior. This is something that might be greatly mitigated with just a few more solver iterations, set either globally or for the problematic rigids.

Sample project demonstrating the issue (Godot 4):
physics_test.zip

Beyond that, there is a general lack of transparency as to what the physics solver is doing at any given step. Implementing simple functionality, such as breakable joints or resource consuming motors, becomes unnecessarily contrived and performance intensive when the current forces and torques being applied by the solver are not readily available to scripts.