ShapeCast3D moves when Visible Collision Shapes are enabled

[tbhel]

Tested versions

Reproducable in 4.3dev6 and 4.2.1.stable

System information

Godot v4.2.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - integrated Intel(R) UHD Graphics 620 (Intel Corporation; 31.0.101.2111) - Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (8 Threads)

Issue description

I have added a ShapeCast3D as a child to a CharacterBody3D. When the CharacterBody3D moves, the ShapeCast3D moves with it.

With Visible Collision Shapes enabled, when the ShapeCast3D hits a StaticBody3D the ShapeCast3D does not keep to its original position in relation to its parent, the CharacterBody3D. It seems to get stuck on the StaticBody3D as if it were colliding.

Other CharacterBody3Ds moving into the ShapeCast3D can also move it.

I am not 100% certain but I believe this only affects the Visible Collision Shapes, not the actual ShapeCast3D itself. But it makes debugging hard.

This is a clip showing the issue.
The moving square is a CharacterBody3D, the static square is a StaticBody3D. The rectangle is the ShapeCast3D.

Steps to reproduce

Make a scene with the following structure:

• Node3D
  • Camera3D
  • CharacterBody3D
    • CollisionShape3D
    • ShapeCast3D
  • StaticBody3D
    • CollisionShape3D

Move the ShapeCast3D position so that it is in front of the CharacterBody3D.

Attach a script to the CharacterBody3D that takes user input to move it around.

Enable Visible Collision Shapes and run the scene. Move the CharacterBody3D so the the ShapeCast3D would collide with the StaticBody3D.

Minimal reproduction project (MRP)

test.zip

[AThousandShips]

This looks by design IMO, it shows how far the shape can move before it hits, which is part of how the ShapeCast3D node is designed, I don't think this is a bug but a feature, you can see the code making this happen here:

godot/scene/3d/physics/shape_cast_3d.cpp

Lines 498 to 515 in daa81bb

	void ShapeCast3D::_update_debug_shape_vertices() {
	debug_shape_vertices.clear();
	debug_line_vertices.clear();
	if (!shape.is_null()) {
	debug_shape_vertices.append_array(shape->get_debug_mesh_lines());
	for (int i = 0; i < debug_shape_vertices.size(); i++) {
	debug_shape_vertices.set(i, debug_shape_vertices[i] + Vector3(target_position * get_closest_collision_safe_fraction()));
	}
	}
	if (target_position == Vector3()) {
	return;
	}
	debug_line_vertices.push_back(Vector3());
	debug_line_vertices.push_back(target_position);
	}

[tbhel]

It's certainly possible that this is by design, but to me it seems very unintuitive and somewhat buggy for several reasons.

• I was under the impression that ShapeCast3D would behave similarly to Area3D, meaning it will only report on what it overlaps with, not actually collide and move.
• This makes ShapeCast3D behave differently from RayCast3D, meaning RayCasts aren't moved when detecting a collision.
• The position / global_position value of the ShapeCast3D does not change, only the visual representation of it. That makes zero sense to me.
• As you can see in the clip above, when the CharacterBody3D moves all the way forward to the StaticBody3D, the ShapeCast3D actually moves to the back side of the StaticBody3D. So it does not actually show "how far the shape can move before it hits".

[AThousandShips]

It doesn't collide and move, it doesn't actually move, the debug is just a debug representation, don't take the visualization to be the real behavior

The shape visualizes the closest safe fraction, which is a common use of ShapeCast3D, see here for details on what that means

This is 100% by design, this code didn't happen by accident because it doesn't represent some simulation, it's just a visualization.

In the final case where it moves beyond that's due to it not being able to work at the root position, which is possibly a bug in how ShapeCast3D works fundamentally, but not in the visualization

So while that specific behavior part might be a bug, the fact that it visualizes this way is not an oversight but by design, and displays how the node works and the features of it, you can read the documentation for more details if you have questions on how it works

[tbhel]

I see, thanks. I think I understand now that this is how ShapeCast3D works, and is working as intended. (Possibly except for the case where it moves beyond the StaticBody3D)

However, for debugging purposes, would it not make more sense to keep the visual representation of the ShapeCast3D in its root position? If not, would it be possible to show both root position and closest safe fraction, or maybe make it an option to choose from root position or closest safe fraction?

[AThousandShips]

However, for debugging purposes, would it not make more sense to keep the visual representation of the ShapeCast3D in its root position?

I don't think that makes sense, it doesn't serve any purpose like that IMO, the way it currently works it shows:

• If it is colliding
• Where it collides

Which IMO is exactly the information you want to visualize

If not, would it be possible to show both root position and closest safe fraction

This would be cluttered

or maybe make it an option to choose from root position or closest safe fraction?

That could be an idea, but that would have to be handled in a proposal instead

So I'd suggest opening a proposal for that part, and the incorrect check at the root position is already tracked in:

• ShapeCast3D & SpringArm(3D) return incorrect collision length when shape intersects at the origin (GodotPhysics) #72995

So closing this, but thank you for your report and conversation! If you're interested in changing the behavior of this please open a proposal to discuss this