Shouldn’t damp be tick-rate independent?

[Jayman2000]

The docs for default damp values all say:

Note: Good values are in the range 0 to 1. At value 0 objects will keep moving with the same velocity. Values greater than 1 will aim to reduce the velocity to 0 in less than a second e.g. a value of 2 will aim to reduce the velocity to 0 in half a second. A value equal to or greater than the physics frame rate (physics/common/physics_ticks_per_second, 60 by default) will bring the object to a stop in one iteration.

Shouldn’t physics_ticks_per_second not matter here? Does this mean that a different amount of damping will happen if a game lags?

[Calinou]

Edit: Damping already appears to be tick rate-independent if I'm reading the description right:

e.g. a value of 2 will aim to reduce the velocity to 0 in half a second.

The "half a second" part does not change based on the value of the Physics Ticks per Second project setting, so it's tick rate-independent. Otherwise, this duration would change based on that project setting if it was tick rate-dependent.

I'll leave the older comment below for posterity.

---

Changing this behavior would break compatibility with existing projects, so it can't be done unless it's an opt-in project setting.

Does this mean that a different amount of damping will happen if a game lags?

The physics step can run up to 8 times per frame by default, so it won't affect damp speed unless your game lags severely (i.e. below 60.0 / 8.0 = 7.5 FPS by default). You can adjust how many times the physics step is allowed to run per rendered frame in the Project Settings (Max Physics Steps per Frame).

[Jayman2000]

Edit: Damping already appears to be tick rate-independent if I'm reading the description right:

e.g. a value of 2 will aim to reduce the velocity to 0 in half a second.

The "half a second" part does not change based on the value of the Physics Ticks per Second project setting, so it's tick rate-independent. Otherwise, this duration would change based on that project setting if it was tick rate-dependent.

You’re 100% right, but the fact that you’re right is making me confused. That part of the documentation does imply that damping is tick rate-independent. At the same time, the docs also say:

A value equal to or greater than the physics frame rate (physics/common/physics_ticks_per_second, 60 by default) will bring the object to a stop in one iteration.

Unless I’m missing something, it sounds like the documentation contradicts itself by first saying that damping is tick rate-independent and then saying that damping is not tick rate-independent.

I found a PR that was merged on February 9th, but hasn’t made it into any releases yet. It adds this sentence to the damp settings’s descriptions:

Warning: Godot's damping calculations are simulation tick rate dependent.

---

Changing this behavior would break compatibility with existing projects, so it can't be done unless it's an opt-in project setting.

I agree. If we change the way that this works, we should either make it an opt in setting or wait for Godot 5.

[Calinou]

Unless I’m missing something, it sounds like the documentation contradicts itself by first saying that damping is tick rate-independent and then saying that damping is not tick rate-independent.

Even if that happened, it would still be tick rate-independent. It just means that the object will stop in a single physics frame, because it's the smallest divisible unit of time for physics simulation.

That said, the documentation seemed to be wrong until godotengine/godot#82950 was merged, so it appears damping is tick rate-dependent.