Hello devforum. I want to figure out how one would determine if a part is blocked from reaching another part. The only solution I’ve found was using Roblox’s built-in pathfinding, however ComputeAsync is very, very slow when you account for the fact I need to use this a lot. Raycasting, to my knowledge, also doesn’t work, the reason why is in this diagram:
As you can see, if you cast a direct ray to point b from point a, it will think that the path is blocked, however you can clearly tell that point b is reachable by simply going around the obstacle.
The best way you can use is raycasting, as i know there is no better way than a raycast from the part and check if it hit anything rather than the part you want.
But what if point b is FULLY blocked? the ray would think that it’s reachable, as the ray would only be looking for that specific part and nothing else.
Not really, you would check what did the ray hit, if a part with specific name, then its reachable, if no part was hit with this name, then it didnt hit the part we want and it is not reachable.
I explained this in the diagram, if the part is blocked from an angle, but reachable from other angles, the ray would have no idea and think the part is blocked.
You can use raycasts, first of all check magnitude, if it’s bigger then return nil, if it’s OK then create 6 rays and check how many of them hit, if most rays hit then return true
Grid-Based Pathfinding (A)*: If you want more control over the speed and accuracy of the pathfinding, you could implement a simplified A* pathfinding algorithm yourself. This would break down the area into a grid and check for reachable spaces without directly relying on ComputeAsync.
Breadth-First Search (BFS): This method could be used in combination with a grid-based approach to check if a point is reachable from another. It’s simpler than A* but might be useful if the environment doesn’t have complicated terrains.
Area of Influence (AOI) Mapping: Another option is to calculate “areas of influence” or “reachability zones” using bounding boxes or spheres around obstacles. By checking overlaps between these zones and the parts, you could simulate a “reachable” check without direct pathfinding calculations every time.
Pre-Processed Path Networks: If the layout doesn’t change often, consider creating a navigation mesh or pre-defined path network in advance. You can then quickly look up paths between two parts based on proximity and avoid the slow real-time pathfinding calculations.
Hybrid Raycasting: Another potential solution is to combine raycasting with iterative steps around the obstacle. For example, cast rays in small angles or directions around the obstacle when a direct path is blocked, simulating how a player or character would “look around” an obstacle to find a clear path.
