I’m trying to build my own 2D pathing code and an important component of that is finding obstacles in the way. As I was getting close to figuring it out I realized there was some inconsistencies with the RaycastHit2D returning colliders. So I made a demo. Here is the script attached to the “origin” object.
This script is attached to the green dot in the screenshots. There are no other scripts in play. The three boxes all completely identical and have colliders assigned to a “Box” layer as you can see in the setup screenshot.
The rest of the screenshots are different scenarios where the RaycastHit2D is returning or not returning a hit (see the ticked isHitting property flag in the screenshots).
isHitting is true: A hit is registered when there are no colliders between the points.
isHitting is true: Hit is registered when going through multiple colliders.
isHitting is false: This is the scenario where I first recognized the inconsistency.
isHitting is true: cast goes straight through collider, detects it.
I tried changing the raycast to a circle cast and got the same results. What is going on here? Is there something I’m doing wrong? Is there a better way to detect these colliders?
Is using the destination as the direction wrong? I thought the direction was the position the ray would point to and the distance would be the magnitude/length of the ray.
Edit:
I did the Debug.DrawRay() and it seems it points away from the destination. What should I be using as my direction vector then?
Essentially your thread titie is saying that a basic function used by hundreds of thousands of devs is fundamentally broken. When you think this, it’s best to really validate how you’re using it, carefully.
You’re best to first read the docs for Physics2D.Raycast. So “direction” is described as “A vector representing the direction of the ray”. A vector direction is not a position in space. A ray is not a line between two points. It’s a position, direction and distance.
If all else fails, look at the code-snippet. You’ll soon see it doesn’t expect two world positions.
What you want is a line-segment and that’s available with Physics2D.LineCast. That has startPoint and endPoint described as: “The start point of the line in world space” and “The end point of the line in world space” respectively. You then don’t need distance at all because it’s a well-defined line-segment i.e. two world positions.
I didn’t mean to offend with my title. When something works in some cases and doesn’t in others I consider it “buggy” so I tagged it as such. I figured it wasn’t working due to some ignorance on my part hence me saying “Is there something I’m doing wrong?”.
I did check the docs, I read that direction definition probably 30 times. There is no distinction made between a positional vector and a directional vector. Vector up until now, to me, has been synonymous with position. Thank you for clarifying.
I’m here to learn. You have helped me a lot in a few other posts so again I thank you for your patience and what you do for this community. The LineCast was exactly what I needed and now my navigation code works!
I didn’t take offence at all. It was a simply a suggestion on how to think about it. The title states that Unity is inconsistently returning results despite you asking if you’re doing something wrong. That can lead some devs down the wrong path. To be fair, most devs state Unity isn’t working no matter what the problem. I was only trying suggest considering your script must be wrong given the basic nature of the thing you’re calling.
Then you’re not very familiar with basic Vector operations and there’s nothing wrong with that at all but each individual call in Unity isn’t going to describe the difference between a position and a direction and Vector ops. If you search for “Vector direction” on Google then you’ll get a whole bunch of stuff to help! Vector2/Vector3 are just values. They can encode a position or a direction. Often in graphics, they encode RGB and other stuff. In Unity, if it’s a postiion in space, it’ll always be called a position or point. If it’s pointing in a direction then it’ll always be direction.