Since joint resources are created by joint nodes and also they take care of freeing them, the physics server doesn't need to free bodies' joints explicitly.
The logic for clearing the constraints map/set is still relevant as there may be collision pairs and in their case its the server itself the one creating them and therefore releasing them.
(cherry picked from commit fbeb27b01d)
- Use `NOTIFICATION_ENTER`/`EXIT_WORLD` for `Area` (intead of `*_TREE`).
- Now both bodies' and areas' constraints are cleaned up.
- And now also that happens as soon as the space is set to null (i.e., when exiting the tree) instead of only at freeing time.
- When clearing constraints, the loop goes on to the next if the current is already released, instead of breaking.
- When one has been already released, no error is shown from now on, as it's something expected, since a pair (our kind of constraint of interest) can be freed by any of its involved collision objects and the other will try again.
- Implement index shifting (or marking as -1) for shapes indices in collision pairs shapes are removed.
- Standarize behavior of bodies and areas so that anything that invalidates a given pair gives the same result (collision mask, actual collision, etc); for instance, triggering area enter/exit signals.
- Add missing member initializations.
- Extend the new-space-equals-area/body-current-space test to every case.
- Fix 3D ray-casts early accepting Areas (skipping the mask check).
- Fix unpairing of large elements (2D's `BroadPhase2DHashGrid`).
Some of these prevent random crashes caused by constraints with dangling pointers to involved objects.
Fixes#8856.
Fixes#7589.
Fixes#6676.
And maybe others.
Also, change the explanation of the one-way collision direction in the docs to reflect how it is actually used by the engine and clear up the usage of the "max depth" property.
Got part of the fix from 5fc084c28e
Added an engine setting to enable the fix (physics_2d/motion_fix_enabled) which is false by default so the default behavior is the same as always
Added motion methods with a from parameter, the same as 3.0 does
That year should bring the long-awaited OpenGL ES 3.0 compatible renderer
with state-of-the-art rendering techniques tuned to work as low as middle
end handheld devices - without compromising with the possibilities given
for higher end desktop games of course. Great times ahead for the Godot
community and the gamers that will play our games!
(cherry picked from commit c7bc44d5ad)
You can't set this value very well, since it's automatically computed
from the mass and the collision shapes. But since the values are higher
than many people might suspect, so being able to read it helps estimate
the amount of torque you might need to apply.
