Improve animation track optimizer

[TokageItLab]

This PR changes the key removal algorithm of the animation track optimizer using the velocity ratio as I said in godotengine/godot-proposals#4997.

For example, if there is a value A that changes 0.6/s and a value B that changes 0.5/s, the ratio can be calculated as follows:

ratio = A < B ? A / B : B / A = 0.83

The closer the value is to 1, the closer the velocity of the prev and next keys.

This eliminates the old optimizer's Max Angle and unifies it into an Max Velocity Error. For the same reason, the Max Linear Error real value comparison is also eliminated. However, since real value comparison is still necessary for removing float point precision error, so an Max Precision Error is added.

---

Below is a video preview with #53864:

raw.mp4

As the value of Max Velocity Error increases, more keys are deleted certainly.

The case of Velocity Error: 0.05, Angular Error: 0.01 looks mostly correct, but a few frames produced a slightly worrisome error.

Larger values of Angular Error will reduce more keys, but it corrupts animation larger:

raw.3.mp4

As @Calinou said in godotengine/godot-proposals#4997, the default value must be lossless in look and feel. So far, the case that can be properly called lossless is Velocity Error: 0.01, Angular Error: 0.01. I decide to use it as default values.

---

Comparison with the old Optimizer:

raw.2.mp4

The old Optimizer default values obviously remove too many keys, and the animation path is quite corrupted. I chose Velocity Error: 0.25, Angular Error: 0.01 as settings where the deletion rate is close to that, but still an acceptable animation corruption.

By the way, a comparison with the old Optimizer's minimum value setting is shown below.

The new Optimizer seems to have better results, keeping more important keys and a better deletion rate there.

---

This solves the #58968 problem as well:

raw.4.mp4

The Optimizer issues have been reported so frequently that I cannot keep track of all of them.

For now, I will only link to two issues for which there are sample project files and for which I can determine that the problem has been completely resolved.

Fixes godotengine/godot-proposals#4997.
Fixes #53864. Fixes #58968.

[fire]

We discussed that using acceleration or jerk is not necessary.

Also the unit of the 0.01 is not meters but something else.

From @TokageItLab

For example, if there is a value A that changes 0.6/s and a value B that changes 0.5/s, the ratio can be calculated as follows:
ratio = A < B ? A / B : B / A = 0.83
The closer the value is to 1, the closer the speed of the prev and next keys.

[reduz]

This seems like a very interesting approach, I guess time will tell how well it works.

[timshannon]

FWIW, this absolutely fixes my issue with the attached project on v4.0.alpha.mono.custom_build [03dc8c5].

After importing the same model with this PR, I no longer have the overlap / escaping mesh issues that was seeing before, and the animations seem to better reflect the snappyness I'm seeing in blender.

Bug.zip

[akien-mga]

Thanks!