Collision point checker

[AdeptusForge]

Gives the scripting API access to 'contains_point' logic for Shape2D's and Collision Shape2D's

• Bugsquad edit, closes: Checking if Points are within a given CollisionShape godot-proposals#9636

[AThousandShips]

And you need to run clang-format to make sure your code follows the style guide

Also the cases that just are placeholders now should be fixed, this shouldn't be merged in a half finished state IMO

[RedMser]

Doing something similar for Shape3D would be very appreciated as well! Most of the primitives would likely be trivial as well.

[kleonc]

• You need to generate the docs (and fill them).
• Since this PR seems to be WIP I suggest converting it into a draft (until it's ready for review).
• CollisionShape2D::contains_point needs to be clearer about whether it takes local/global point in relation to the CollisionShape2D (maybe it's fine as is and just documenting would be enough).
• Should Shape2D::contains_point be exposed as well? 🤔 Since it's added anyway...

[AdeptusForge]

• You need to generate the docs (and fill them).
• Since this PR seems to be WIP I suggest converting it into a draft (until it's ready for review).
• CollisionShape2D::contains_point needs to be clearer about whether it takes local/global point in relation to the CollisionShape2D (maybe it's fine as is and just documenting would be enough).
• Should Shape2D::contains_point be exposed as well? 🤔 Since it's added anyway...

Docs Generated and filled, contains_point now works globally, and shape2d's don't have their 'contains_point' functions exposed because they only work locally.

Only thing(s) left I reckon is to pass the workflow approval and to perhaps expand it outward to the Shape3D's too.

[kleonc]

I don't see a reason for such check, there's no need for a CollisionShape2D to be a child of a CollisionObject2D to be able to check whether the given point is within its shape. 🤔

What needs to be checked however is whether there's a valid shape assigned in the first place.

Suggested change

	if (!collision_object || !Object::cast_to<Node2D>(collision_object->shape_owner_get_owner(owner_id))) {
	return false;
	}
	return shape->contains_point(to_local(p_point));
	return shape.is_valid() && shape->contains_point(to_local(p_point));

---

Unless we want this method to be working in the "physics world", according to the physics server. In such case checking for collision object existence etc. makes sense. But then we wouldn't want to use to_local etc. because it's using node-cached global transform, which means there could be potential discrepancy between its state and what's the current state within the physics server (depending on when you'd call this method).
So I'd say if it's supposed to be working directly with the data as per physics server then the transforms would also need to be fetched from it.

I don't know if one approach is preferred over the other. Not sure what makes more sense API-wise etc. I think before accepting/merging either of the approaches this would need some input from the @godotengine/physics team.

[AdeptusForge]

The math I was doing prior to using to_local would work, given its not node-cached. The validation was originally there for that math.

Personally speaking, running point-checking off the current physics state makes more sense given what it would be used for during runtime, and is more imminently useful. Seems overall better for the end-user.