KinematicCollision much less accurate in GodotPhysics compared to Bullet

[deyn123456789]

Godot version

3.4.beta4

System information

Windows10

Issue description

Using KinematicCollision to get a Vector between the Player and the KinematicCollision.position seems to be much more accurate in Bullet compared to GodotPhysics.

Going straight left until colliding with a straight wall and using

if collision: print(collision.position.direction_to(self.global_transform.origin))

returns (0.987696, 0, 0.156385) in Bullet and (0.894458, 0, -0.447152) in GodotPhysics with default values.

You have to increase the Collision.SafeMargin to a very large number to get similar Results in GodotPhysics.

Steps to reproduce

Download the Project, go left until the wall is hit, switch between Bullet and GodotPhysics.

Minimal reproduction project

PhysicsTest.zip

[pouleyKetchoupp]

Confirmed in 3.3.3.stable as well.

[Calinou]

I can confirm this on 3.4.beta (17e61fa), 3.2.3 and 3.1.2. Is this related to #28032? A BoxShape is used for the static collider.

When using Bullet, note that the value will rapidly oscilliate when you keep moving left (in 3.1.2, 3.2.3 and 3.4 beta):

(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)
(0.987696, 0, 0.156385)
(0.987696, -0, 0.156387)

[pouleyKetchoupp]

Is this related to #28032? A BoxShape is used for the static collider.

Artifacts due to collision margin could explain the imprecision in Bullet (extra margin on the shape itself, different from the kinematic safe margin), but it shouldn't be the case with Godot Physics.

[Hiiamwilliam]

While I don't know anything about Godot internals, I think this may not be a bug about accuracy. From my (simple) understanding, trying to get the global position of a collision may not give correct results if you're trying to collide parallel shapes, or in other words, shapes that have more than one point of contact.
In the MRP, the height of the Capsule (which can be understood as a line) will collide with the wall. At the moment of collision, all points of the line will be colliding, so what is the collision position? It's not going to be a "precise" answer since all points are colliding. The result is probably the first good position the engine calculated.
I also think this may not be a bug because if you A) rotate the capsule so that the spherical part hits the wall first or B) check collision normal instead of position, the results of both engines will be the same, ignoring some differences on the fifth decimal house and the signal of zero.