Physics nodes reorganization

[pouleyKetchoupp]

Implements godotengine/godot-proposals#2184 for 2D and 3D physics.

Named things a bit differently from the original proposal in order to alleviate possible confusion reported by the community (more details in godotengine/godot-proposals#2184 (comment)).

The general idea is to keep consistent naming all over the API to make documentation easier, with names that match standards from physics engines:
Dynamic = can move, receive forces and be pushed around
Kinematic = can't be pushed, can move and push dynamic bodies along the path
Static = can't be pushed, can move by teleport only
Character = specific kinematic character controller functionalities

Changes are in separate commits to make review easier, but I can squash everything in the end if needed.

1. KinematicBody functionalities split between PhysicsBody and new node CharacterBody
-KinematicBody renamed CharacterBody, using same icons
-PhysicsBody now has methods move_and_collide/test_move and needed properties for these methods: safe margin, locked axes (3D only).
-Moved collision_exceptions from StaticBody to PhysicsBody for 3D (now same as 2D, and conforms to documentation).
-RigidBody doesn't have test_motion() method anymore, since it's now redundant with PhysicsBody.test_move().

2. Properties instead of parameters for move_and_slide and remove move_and_slide_with_snap
-snap property to replace move_and_slide_with_snap()
-floor_max_angle, stop_on_slope, infinite_inertia, max_slides, up_direction properties to replace arguments from move_and_slide()
-Default values haven't changed, except for up_direction which is now Vector3.UP and Vector2.UP since it's the most common use case (it was previously zero, and would consider everything a wall by default)
-Possiblity to add more properties in the future to support different character controller use cases

3. More explanatory names for RigidBody modes
-MODE_DYNAMIC instead of MODE_RIGID (to avoid confusion with RigidBody node)
-MODE_DYNAMIC_LOCKED instead of MODE_CHARACTER (to avoid confusion with CharacterBody node)
-No more special case for sleeping behavior for MODE_DYNAMIC_LOCKED (MODE_CHARACTER was forcing the body not to sleep, which is redundant with can_sleep and wasn't done in Bullet).

4. Support for kinematic_motion in StaticBody
-Does the same thing as simulate motion from RigidBody in Kinematic mode, and CharacterBody (previously KinematicBody).
-Added support for constant linear/angular velocity with kinematic_motion in StaticBody, which moves the body in physics (as opposed to just moving bodies in contact)
-Updated documentation for StaticBody and CharacterBody to describe their functionalities more accurately.

[Zireael07]

BTW can we get docs telling us how to convert move_and_slide() to move_and_collide() - I tried passing the velocity * delta to move and collide, which most tutorials seem to recommend, and got completely different behavior than move_and_slide(), do they use different parameters other than one having the delta baked in and the other not?

[KoBeWi]

@Zireael07 If you mean that move_and_collide will stop on obstacles, that's because you need to slide the body manually. Something like

var col = move_and_collide(velocity * delta)
if col:
    move_and_collide(col.remainder.slide(col.normal))

[Zireael07]

No, I do want it to stop on obstacles. I mean I get completely different behavior, almost as though the velocities were much larger...

[pouleyKetchoupp]

@Zireael07 That seems strange. Could you open an issue with a MRP so I or someone else can have a look to your use case? It's a bit off-topic to discuss it here.

[reduz]

I know this kind of is a nitpick, but safe margin exists as a hack because of Bullet. If Bullet is being removed, I think we should probably just get rid of it, and pass the margin as a default parameter of move_and_collide. this way we also pollute the base class less.

[ShalokShalom]

Since you are going to remove Bullet now, I guess you like to reread this.

(I assume that decision hasn't been taken at the time)

[reduz]

Err, sorry, approved by accident, but it looks fanastic so i guess its ok anyway.

I would change the safe margin, but depends on what you think regarding it most likely breaking in Bullet. TBH I would just not care about Bullet at this point.

[pouleyKetchoupp]

@reduz I've just pushed two changes based on your feedback and our discussion on rocketchat:

• Safe margin cleanup

Safe margin property on CharacterBody instead of PhysicsBody, used as argument in move_and_collide. It can be still useful to keep it as a property as it's used in move_and_slide and CharacterBody is a specialized node.
Removed kinematic_safe_margin in 3D physics server, not really useful and now harmonized with 2D.

• Linear velocity cleanup

CharacterBody has a linear_velocity property to replace the argument in move_and_slide. So now move_and_slide uses this property and modifies it when collisions occur.

StaticBody handles reporting linear/angular velocity correctly when kinematic motion is used (in 3D, used in vehicle and navigation). This is an issue I've just spotted, when I've moved kinematic motion from KinematicBody to StaticBody I overlooked this case.

[fire]

Supersedes #43073?

[pouleyKetchoupp]

Supersedes #43073?

Yeah, #43073 is based on an older proposal that was superseded.

[akien-mga]

That's a great step in the right direction, let's see how the user feedback is and iterate on it for 4.0.

[akien-mga]

Thanks!

[BastiaanOlij]

Late to the party but only just found out about the linear_velocity property. I am not a fan..... Little more a fan :P