New RaycastParams parameter: IncludeInitialInstances

Feature Requests Engine Features
1

When using Spherecast, it’s currently impossible to detect a hit if the target is already inside the starting sphere.

This creates two major issues:

  • It makes it difficult to detect yourself (for debugging).

  • It introduces gameplay bugs, such as failing to register a nearby enemy who steps too close and ends up inside the starting sphere.

In the swing example below, I perform four spherecasts. None of them detect my own hitbox, because all start with me already inside their sphere:

image
image409×311 86 KB

A possible workaround would be to run an initial check at the starting position using GetPartsInPart, by placing a physical sphere there.
However, this approach is highly inefficient and undermines the entire purpose of using Spherecast in the first place.

That’s why I suggest adding a new property to RaycastParams that will detect parts already inside the initial sphere:

RaycastParams.IncludeInitialInstances : boolean
When enabled, detects BaseParts that initially intersect the shape.

Enabling this would detect hits even if they are inside the starting sphere/block/shape.

4 Likes
2

Is there a reason you’re not just using GetPartsInRadius? It solves the inefficiency with creating a physical sphere.

2 Likes
3

I also had this issue until I learned how Raycasts/Shapecasts are designed. The algorithm behind Raycasts and Shapecasts is to find the first collision along a path. Roblox docs also explain that ray and shape casts dont detect initial intersections:

image
image1389×370 39.6 KB

Use the bounding querying operations for initial intersections between shapes:
https://create.roblox.com/docs/reference/engine/classes/WorldRoot#GetPartsInPart

4

You could definitely run an additional GetPartsInPart check everytime you make a Spherecast, but it’s inefficient and messy.

Adding the functionality to the Spherecast would ease the coding experience for alot of devs, and roblox could probably make the algoritm faster than GetPartsInPart.

I do understand the logic that @Ezworkzz presents, and it makes sense for individual Rays.
But saying that I did not hit the part that’s 2 studs infront of me, just because the radius of my bullet is 3 studs, does not feel intuitive.

1 Like
5

yes!! this is a big pain point for me when making custom physics implementations and character controllers - spherecasting is hardly as useful as it should be because of this.

there is, however, some ambiguity as to what hit normal / contact point values this should return, however. for spheres specifically this is easy enough (it should logically always be the direction towards the sphere’s center and the closest point on the surrounding geometry) but for boxcasts and particularly mesh-casts this becomes more complicated.

but i think even a half implementation of this that works only for spherecasts is a better api than nothing!