[Jolt Physics / GodotPhysics] RayCast3D returns different collision normals when hitting a CollisionShape on the edge

[Grandro]

Tested versions

• 4.4.1 stable

System information

Windows 11

Issue description

When a RayCast3D hits a CollisionShape on the edge there is different behavior between Jolt Physics and Godot Physics:
Jolt Physics:

Ray shoots along the Z-Axis. Reported collision normal is (-1, 0, 0)

Godot Physics:

Ray shoots along the Z-Axis. Reported collision normal is (0, 0, 1)

Jolt Physics behavior has a negative impact because if you put two CollisionShapes next to each other that leave no space inbetween, the reported normal suggest that the ray passed through the CollisionShape:

Ray shoots along the Z-Axis. Reported collision normal is (-1, 0, 0)

Steps to reproduce

1. Create a new project
2. Create a RayCast3D
3. Create a StaticBody3D and a CollisionShape3D with shape BoxShape3D
4. Position the nodes so that the RayCast3D collides with the StaticBody3D on the edge of its shape.
5. Print the collision shape normal

Minimal reproduction project (MRP)

Jolt_Collision_Normal.zip

[CreatedBySeb]

There are known differences between Godot Physics and Jolt Physics see this page in the docs. One entry that seems potentially relevant in this case (though I'm not an expert in either physics engine by any means) is Collision margins. Does tweaking the setting mentioned in the documentation affect whether the issue occurs? If it does then this may be a known and documented difference/limitation rather than a bug.

[Grandro]

@CreatedBySeb I tried some different combinations of collision margins and the Collision Margin Fraction project setting for Jolt and it didn't seem to have an impact. I also tried to adjust some other project settings with the same result.

[mihe]

One entry that seems potentially relevant in this case (though I'm not an expert in either physics engine by any means) is Collision margins.

Ray-casts in Jolt are not affected by collision margins, as I understand it, meaning they behave as if there is no rounding of the edges. We should probably add that note to that documentation.

Jolt Physics behavior has a negative impact because if you put two CollisionShapes next to each other that leave no space inbetween, the reported normal suggest that the ray passed through the CollisionShape

The outcome of this setup seems to depend on the order you place the shapes, where I get (1, 0, 0) if I have the left-hand collision shape as the last child of Static, but (-1, 0, 0) if it's the first, which I guess makes sense.

---

@jrouwe Without actually stepping through the Jolt internals, I'm assuming this has to do with the fact that we're forced to rely on JPH::Body::GetWorldSpaceSurfaceNormal to get the surface normal for ray-casts, the result of which is presumably somewhat undefined in a literal corner case like this?

[jrouwe]

Yes, the only information that is provided to JPH::Body::GetWorldSpaceSurfaceNormal is the contact point (there is no sub shape ID for a box). It will pick the surface of the box that is closest to the contact point, which on the edge of the box is not defined so both normals are possible as return value.

[mihe]

I take it there's not much that can be done to change this then? Do we just document this as a gotcha and leave it at that?

[Grandro]

I want to elaborate why this behavior is problematic for me. Maybe you can give me an alternative approach.
I have a room with a projector in the center. This projector shoots a ray using a RayCast3D to where it faces. I do this to find out where the projector projects its image to:

Now I want a character to move to the position the projector projects to but ~1 meter away from it. So I get the collision point from the RayCast3D and the collision normal and say that the position the character should move to is final = collision_point + collision_normal:

Now as soon as I hit the edge of a CollisionShape this approach fails because I cannot reliably tell what the normal will be.
Imagine this to be the gate the ray shoots at in the two pictures above:

I can understand that it is not clear what normal should be reported for the edge of a CollisionShape, but I think it would be better to return the normal that points the most back to the ray (or whatever GodotPhysics does).

Workaround:
I'm not sure if there is a real workaround. I could manually "merge" CollisionShapes so that I get less edges. But as soon as I have an edge that can be hit by the ray I can only hope that it won't be hit.

[mihe]

or whatever GodotPhysics does

Godot Physics optionally returns the surface normal as part of its line segment intersection test (seen here for box shapes), which seems to take the line direction into account, whereas with Jolt you query for the normal after the ray-casting is performed, using only the hit point as the input.

From what I've gathered this separation is for performance reasons, but @jrouwe is better suited to answer that.

Perhaps it's as "simple" as adding an optional direction parameter to JPH::Shape::GetSurfaceNormal and JPH::Body::GetWorldSpaceSurfaceNormal, but seeing as how those methods don't inherently have anything to do with ray-casting it would admittedly look a bit strange.

Another workaround in your case could be to replace the RayCast3D with a ShapeCast3D instead, using whatever shape that makes the most sense, and ideally with its max_results set to 1. You will then however get "rounded" normals around edges/corners instead, since ShapeCast3D.get_collision_normal gives you the collision normal and not the surface normal.

[jrouwe]

From what I've gathered this separation is for performance reasons, but @jrouwe is better suited to answer that.

This is indeed for performance reasons as often you find many hits before you find the closest hit. Calculating the normals for all hits would be a waste of time in that case and also makes it harder to SIMD-ify the ray cast.

Perhaps it's as "simple" as adding an optional direction parameter to JPH::Shape::GetSurfaceNormal and JPH::Body::GetWorldSpaceSurfaceNormal

I had the same thought. It would be possible, but I also find it a strange API. An alternative would be to encode the face that is hit in the SubShapeID but that also adds a lot of overhead to the system (maybe even more than just calculating and returning the normal).

As an alternate to doing a ShapeCast3D, I would suggest doing multiple ray casts, e.g. in a x pattern and using the returned points to calculate a plane. Ray casts are infinitely thin, so it's very easy for rays to pass through cracks (e.g. due to float precision errors) and cause odd results. Assuming that the normal at 1 point is representative for the entire wall is dangerous.