ShapeCast3D detects colliders behind it

[Sheepy3]

Tested versions

• Reproducible in 4.2.2 Stable, 4.1.4 Stable, 4.0.0 Stable, 4.3 Beta 2.

System information

Godot v4.2.2.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3090 (NVIDIA; 31.0.15.3623) - AMD Ryzen 9 5900X 12-Core Processor (24 Threads)

Issue description

I have a sweeping shapecast3D attached to an "agent node". this shapecast3D is intended to detect collisions within the shapecast3D. However, the shapecast3D is detecting objects directly behind it.

https://github.com/godotengine/godot/assets/109123711/baa3f0a4-9566-46b6-914a-a12854e629c2

Steps to reproduce

1) open the project 2) run the main scene 3) observe shapecast3D collision behavior

Minimal reproduction project (MRP)

shapecastminimalrepro.zip

[kleonc]

I don't think that's a bug, the casted BoxShape has size.x = 100 and the box is centered, hence from the starting position it reaches -50 <= x <= 50. The "agent behind" is roughly 2.69722 units away on x, hence it collides with the casted box. Setting size.x = 5.3 (less than 2 * 2.69722) for the casted BoxShape makes it no longer collide, as expected.

What might be confusing is how the debug collision is drawn:

[Calinou]

What might be confusing is how the debug collision is drawn:

Is there a way we could improve ShapeCast3D debug drawing to be less confusing?

[Sheepy3]

Is there a way we could improve ShapeCast3D debug drawing to be less confusing?

from my understanding, it seems like the debug drawing doesn't actually represent the true shape of the shapecast3D? I would presume the debug collision would be drawn in a manner which shows what region is being checked for collisions, no?

and the box is centered

if the box is centered, i suppose the confusion lies in how changing the target position no longer displays the box as centered.

if the intended result of changing the target position is for the shapecast's area to be translated accordingly, then the issue is as I described. If the intended result is not for the area to be translated, then the issue lies in how the debug drawing is rendered. or the secret third option where im an idiot who is very confused

[Sheepy3]

heres a video comparing the agent's shapecast with the default target position and with a changed target position (ive also attached this project specifically if thats helpful at all)

https://github.com/godotengine/godot/assets/109123711/48121bd2-87a0-4983-b342-7e78974fea83

shapecastminimalrepro_2.zip

[kleonc]

from my understanding, it seems like the debug drawing doesn't actually represent the true shape of the shapecast3D? I would presume the debug collision would be drawn in a manner which shows what region is being checked for collisions, no?

It only draws the shape once at the "safe fraction" away towards the target_position, and a line from the ShapeCast3D to its target_position. https://github.com/godotengine/godot/blob/6a13fdcae3662975c101213d47a1eb3a7db63cb3/scene/3d/physics/shape_cast_3d.cpp#L498-L515

---

Actually there is a potential bug, as both ShapeCast3D.get_closest_collision_safe_fraction and ShapeCast3D.get_closest_collision_unsafe_fraction return 1.0 when the ShapeCast3D collides right from its starting position. And as mentioned above the safe fraction determines where the debug shape ends up being drawn:

https://github.com/godotengine/godot/blob/6a13fdcae3662975c101213d47a1eb3a7db63cb3/scene/3d/physics/shape_cast_3d.cpp#L505

Issue in action (when it collides from the start then the debug shape is drawn at the target_position, far behind the initial collision):

Shouldn't these return 0.0 in such case? :thinking: I mean there's no "safe" movement as we start colliding but returning 0.0 indicating we can't move at all makes more sense to me than returning 1.0 indicating that we can move to ShapeCast3D.target_position without any collisions.

To inspect: https://github.com/godotengine/godot/blob/6a13fdcae3662975c101213d47a1eb3a7db63cb3/servers/physics_3d/godot_space_3d.cpp#L273-L274