godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.16k stars 97 forks source link

Unify Angular Damping Defaults #8018

Open thygrrr opened 1 year ago

thygrrr commented 1 year ago

Describe the project you are working on

A 3D game about a lone dog on a space ship, who gets treats from the ship's computer if it keeps the crew alive and the ship from exploding.

A 3D game about tactical space battles between ships, somewhere between World of Warships and Sid Meier's Pirates!

2D games as prototypes, jams etc.

Describe the problem or limitation you are having in your project

In Proposal https://github.com/godotengine/godot-proposals/issues/98 4 years ago, decisions were made to multiply various default values for 2D pyhsics by a factor of 10 to map the unit meters to pixels and improve the out-of-the-box feel of Godot. While this leads to non-SI-values such as 980 px/s² for gravitational acceleration, this is a sensible modification.

However, in the wake of these modifications, an inadvertent change was introduced by also multiplying the angular damp default value by 10:

PhysicsServer2D::PhysicsServer2D() {
//...
GLOBAL_DEF(PropertyInfo(Variant::FLOAT, "physics/2d/default_angular_damp", PROPERTY_HINT_RANGE, "-1,100,0.001,or_greater"), 1.0);
//...

This is a common typo; rotations are still measured in radians/degrees, not "pixels", and as such bear no relation to uniform scale changes of the space the object lives in. Rotations are distance-preserving transforms. (see: special orthogonal group, etc.)

The change has resulted in physics out of the box feeling quite different for 2D and 3D, even though they could feel the same!

Godot-1000.webm

I propose the SAME VALUES to be applied to 2D and 3D physics.

Regardless of the intent behind the original change, since Godot has more prevalent 2D than 3D projects, and the 2D physics actually feel better for it, let's apply the same default_angular_damp = 1.0 to 3D. (fixing the error, i.e. setting the 2D default back to 0.1, would likely affect too many existing 2D projects - what do you think?)

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

Change the default_angular_damp for 3D physics to the same value.

This will result in 3D physics feeling more equivalent to 2D physics by default.

Increasing 3D's value to 1.0 will also result in less bouncy / floaty 3D physics, and possibly excessively so. A more robust fix would indeed be changing the default for 2D back to 0.1. This could impact a great many projects, but would also allow "throwing" mechanics and falling of objects to feel better out of the box.

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

index d523f4b1ec..b4cf3d08e7 100644
--- a/servers/physics_server_3d.cpp
+++ b/servers/physics_server_3d.cpp
@@ -1060,7 +1060,7 @@ PhysicsServer3D::PhysicsServer3D() {
        GLOBAL_DEF_BASIC("physics/3d/default_gravity", 9.8);
        GLOBAL_DEF_BASIC("physics/3d/default_gravity_vector", Vector3(0, -1, 0));
        GLOBAL_DEF(PropertyInfo(Variant::FLOAT, "physics/3d/default_linear_damp", PROPERTY_HINT_RANGE, "0,100,0.001,or_greater"), 0.1);
-       GLOBAL_DEF(PropertyInfo(Variant::FLOAT, "physics/3d/default_angular_damp", PROPERTY_HINT_RANGE, "0,100,0.001,or_greater"), 0.1);
+       GLOBAL_DEF(PropertyInfo(Variant::FLOAT, "physics/3d/default_angular_damp", PROPERTY_HINT_RANGE, "0,100,0.001,or_greater"), 1.0);

        // PhysicsServer3D
        GLOBAL_DEF("physics/3d/sleep_threshold_linear", 0.1);

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

A workaround is to manually set the default values. However, this is a proposal that aims to unify the Developer Experience and behaviour of the Engine for everyone.

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

It's a project settings default.

Caveat: This changes existing projects, which may be undesirable. This could be handled by a migration feature. I would consider having to change all future projects and experiencing inconsistent behaviour to be the greater evil than changing a few projects from previous versions that still need the old default but want to run on the newer version of Godot.

Calinou commented 1 year ago

As suggested in https://github.com/godotengine/godot-proposals/issues/4834, compatibility-breaking changes could be applied to new projects only by modifying the project.godot file generated by the project manager.

thygrrr commented 1 year ago

As suggested in #4834, compatibility-breaking changes could be applied to new projects only by modifying the project.godot file generated by the project manager.

Thank you for clarifying, this is precisely the type of "migration" approach I had in mind.