"Point inside Object" condition does not behave correctly when used in combination with Raycasting

[Silver-Streak]

Describe the bug

The "Point inside object" condition does not seem to behave as expected when used with Raycasting. While trying to assist me with some other raycasting issues (another bug report to come later), Entropy on the discord showed that using these conditions in combination seems to only count the upper left corner of the object.

To Reproduce

Steps to reproduce the behavior:

1. Create an event to Raycast from one point to an object.
2. Create a subevent to test if the raycast destination is inside the object.
3. It will only evaluate true if it is cast to the upper left corner.

Entropy provided a video showing how this behaves:

https://user-images.githubusercontent.com/24237149/149642253-92b5bf0e-2402-4014-b43c-481c0c50ed66.mp4

He developed a workaround to use object selection and a few other items instead (also shown in the above video)

Other details

• I believe Entropy is running Win10 64bit, but will update this if I confirm otherwise.
• GD5 5.0.125

[Bouh]

I made it reproducible in this project:

You can drag and drop the pea and point the cube on all faces, and indeed right and bottom face doesn't work. And the test of the point flicker when the cube is in rotation, maybe because the point is not tested inside during one frame but just at the surface. Might be a second issue though.

debug-6541.zip

[4ian]

It's hard to tell if it's an issue or not, it could be related to approximations in floating point precision. The raycast will give you a point that is exactly at the border of the object, but it's not guaranteed indeed that this will be a point considered "inside the object". To be sure, the best way would be to "move a bit the point along the ray", by something like half a pixel, so that you're sure it's inside.

The upper left corner might be just a "lucky point" because the raycasting result and the top left corner are exactly at the same position?

[Silver-Streak]

Hmmm. How would you think we should account for/workaround the issue?

In the example project that Entropy provided, I could totally see the need for this type of behavior, especially in games that deal with stealth and/or vision/audio cones/etc.

If the thought is that raycasting is stopping before it is "inside" the object, is that an issue that "point is inside an object" doesn't count the vertices of the object? or is it an issue that raycasting stops directly before touching the vertices?

[Entr0py404]

the reason I thought this would works is because of what was in basic-ai-with-pathfinding example, some workarounds with object selection and picking do not work in a extension