Physics: Add additional information to RigidBody's body_entered signal

[Redesigner]

The body_entered signal in RigidBody3D (and similarly for RigidBody2D) currently only reports the Node of the other colliding body when a contact is created. As far as I know, there really isn't any obstacle to reporting extra information such as the position or normal of the collision. The RID of the body collided with is also present in the method that emits the signal, and it is very difficult to get this information otherwise.
I feel that this information would be really useful for something like generating collision particle effects.

[SirLich]

Absolutely. I was going to open my own proposal, but I will piggy back on yours.

The issue with properly detecting physics collisions is multi-faceted. I will try to break down my own struggles with the topic.

SKIP TO THE PROPOSAL

My Use Case

My use-case is a 'pong' style game, with a moving ball, and a moving platform. I would like to use the physics engine to detect collisions+normal between the ball and the platform, but otherwise control the ball and paddle with my own logic.

Attempt 1: Area2D + Area2D

I knew that I wanted full control over the physics simulation, so I chose to use two Area2D nodes. Issue: It's impossible to get the normal of the collision from on_area_entered.

Attempt 2: AnimatableBody2D + CharacterBody2D

My next attempt was moving the ball using move_and_collide, while moving the platform using global position. The ball detected collisions, and applied the appropriate physical response. Issue: move_and_collide only gives a KinematicCollision2D when the BALL is moving, not when the platform moves into the ball.

Attempt 3: AnimatableBody2D + RigidBody2D

My next attempt was using a RigidBody2D ball, and _integrate_forces, paired with functions such as get_contact_collider_object and get_contact_local_normal. This didn't work very well, but I admit I may have done something incorrectly.

I also tried using _on_body_entered, as discovered, it doesn't have the requisite information (normal information, in my case).

Attempt 4: CharacterBody2D + CharacterBody2D

I think the next thing I will try is using x2 CharacterBody2D, and moving both of them with move_and_collide. The platform can communicate collision information to the ball, and the ball can continue handling movement. I haven't tried this yet, but I imagine it might work.

Attempt 5: Area2D + Area2D

My next set of tests were using two Area2D nodes, and then calling collide_and_get_contacts from _on_area_shape_entered. This worked OK, but there was an annoying issue where the _on_area_shape_entered would be called, but the resulting call to collide_and_get_contacts would return no collisions. This allowed me to phase-shift through the platform.

I also tried calling collide_and_get_contacts from inside of physics_process, but the collisions would sometimes be reported before the ball hit the platform.

Then, I tried using get_overlapping_areas (to validate a collision had occurred), paired with collide_and_get_contacts, but this just added a very unresponsive feeling: The ball wouldn't phase-shift through the paddle, but it would get some % in before triggering.

Suggested Improvements

1: More info in Callbacks

Add additional information to body_entered , and if possible area_entered. I would highly suggest packaging it into a data type like KinematicCollision2D, or even better, using KinematicCollision2D itself!

2: Make callbacks more accessible

The next suggestion is to move these collision callbacks out of RigidBod2D, and into the base-classes. So that means either PhysicsBody2D or CollisionObject2D. Related properties such as contact_moniter would also need to be migrated.

[Redesigner]

It looks like I've made a mistake: the signal body_shape_entered() provides most of the functionality that I'd want. The only other issue here is whether or not the signal should provide the normal and position.

Currently it works like this (from my own GDExtension code):
PhysicsDirectBodyState3D *state = PhysicsServer3D::get_singleton()->body_get_direct_state(get_rid());
Vector3 global_position = state->get_contact_collider_position(contact_idx);
Vector3 normal = state->get_contact_local_normal(contact_idx);

[SirLich]

Ok so it's a situation where the information is there, but it needs to be data-mined from the PhysicsServer. I will try re-doing my experiments using two Area2D nodes, and this callback based approach.

[SirLich]

I wonder if areas have state, like 'PhysicsDirectBodyState2D'? If not, I think that at least one of the two interacting physics objects needs to be a body.

[SirLich]

Another workaround:

Unfortunately there is no way to get the collision data from an Area2d, but there is a semi-working workaround. If you have a KinematicBody2D node with the layers all disabled, you can position it at the same position as your Area2d and then use move_and_collide with the test move argument on. This will return collision data that should, if I recall correctly, give a decently accurate idea of the collision position and normal for the Area2d.