[Bullet] Raycast results return wrong positions

[Flavelius]

Godot version

3.3.2.stable.mono.official

System information

Windows 10, GLES3

Issue description

CollideShape and IntersectRay of PhysicsDirectSpaceState return wrong values in editor in the attached trimmed down reproduction project.
In another more complete project they return correct values, even though the base setup is the same.
But there CollideShape and IntersectRay hit disabled CollisionShapes (bug) when used in the editor, at runtime they work correctly.
-When bullet is used as backend; with godot physics, disabled CollisionShapes are still hit (bug).
In the attached project though, using both backends wrong hit points are returned in editor (bug). At runtime using bullet the same wrong results are returned (bug), but with godot physics they are correct (not a bug?).
This feels super random that's why it's hard to explain or put into a single issue's description; i hope the attached project still provides some clarification.

Additionally, when convex collisionshapes are used on plane meshes (generated via toolmenu) physics queries only seem to hit one half of the shape in certain cases, which is likely another issue, but it became visible when debugging this one.

Other project with bullet backend in editor (floating arrows = disabled collisionshapes bug)

Reproduction project with godot physics/bullet in editor and at runtime

Reproduction project with godot physics at runtime

Steps to reproduce

Open the attached project, chose either godot physics or bullet as physics backend in the settings, click the 'Editor Do Refresh' checkbox to trigger a toolmode-invoke of the rescan method that scans the area and debug-draws the arrows with hit information (red arrows = final valid hits, blue arrows = normals (leftover from trimming down, same as red here), yellow spheres = temporary first pass hits, see code for more info).
Then compare the results with both backends at runtime.

Minimal reproduction project

BugProject.zip

[Calinou]

Given the issue title, can you reproduce this in earlier Godot versions like 3.2.3?

[Flavelius]

I just wanted to distinguish it from 4.0. But i tested it in 3.2.3 and the results are the same, yes.

[pouleyKetchoupp]

I can reproduce at least some of the issues mentioned so let me try and list all of them:

Bullet issues

1. Raycasts always return false when starting from inside the shape (identified issue but not fixed yet)
   That might be the difference between the MRP and your other project but I can't confirm.

Godot Physics issues

2. Raycasts can detect disabled shapes (I've just opened Fix and clean disabled shapes handling in godot physics servers #49844 and [3.x] Fix and clean disabled shapes handling in godot physics servers #49845 to fix this bug)

3. Raycasts don't always return true when starting inside the shape (identified but not fixed yet)
   It does for boxes, but results can be inconsistent with certain shapes, including convex polyhedron.

I don't see a difference with Godot Physics between editor and runtime though. Could you confirm that? Note that you need to restart your project for the change of physics backend to take effect within the editor.

Is there anything I've missed?

[Flavelius]

As for the second part, you're right, i didn't restart the editor inbetween changing the backend. Doing that makes the results more consistent. Godot physics (while the disabled ColShape bug still exists) now returns correct values both in editor and at runtime.

In both projects (source and MRP) the rays start at a defined location above the 'ground', so no intersections or origins inside CollisionShapes. The only case i can imagine could be that (because) the coordinate space in bullet is for some reason different even for the ray origins, (that) they may have ended up there, as atleast the results are nonsensical.
And with the knowledge that the editor has to be restarted for the change, i retested my original project and indeed the results seem to have been skewed by that, now they are incorrect too, it's as if everything is really performed in some other coordinate system:

So the bullet implementation seems to be at fault here.

Edit: and it's likely related to this issue: #45680

[akien-mga]

Edit: and it's likely related to this issue: #45680

This issue is now fixed in 3.5.

For the rest, I'm a bit confused by the fairly complex MRP and description so I'm not sure what should be interpreted as bugs or not. Could you check the current state in 3.5 RC 1 or later and update this issue accordingly?