RaycastHit Point Always returns Vector3.zero

While testing my game, I came across this severe bug where the Vector3 of hit.point (the point where the RaycastHit data hit) always returned (0, 0, 0). This happened regardless of what was hitting it, or where it actually hit. For example, when I cast a BoxcastAll between two points to determine the intersections of a road, it will correctly identify the colliders that hit, but will not correctly identify the point where it hit.

Even when the collider does indeed detect a collision that has occurred, it still returns a position that is inaccurate. (Spline0 is the collider of the road that has been intersected).

This is not a huge issue when just intersecting 1 point linearly, but it does mess with the game’s ability to intersect diagonal or multiple roads.

Diagonal Collisions


Notice how the position of the actual intersections have shifted from where it was originally intended. This is because the code uses the hit point to determine the point in which both the splines meet.

Multiple Collisions

Sometimes it works perfectly as intended because the RaycastHits were hit in the same order as the direction between the starting point and the end point.

Other times it will join and split incorrectly because the hit points need to be in order from p1 to p2 so that the splines can be split in the intersections neatly.


(Still returns (0, 0, 0) on every collision regardless of whether it collided or where it collided!)

I originally encountered this bug on Unity-2022-2.17f1, so I decided to update to
Unity-2022-3-LTS.22f1 (an LTS version!) to see whether this issue was resolved in an update. Although it fixed some of my collider issues, the bug in which all RaycastHit hit points return (0, 0, 0) has not been resolved.

Here is the code that I use to determine collisions for reference. I will send the entire project if requested

for (int i = 1; i < pointsRef.Count; i++) //for each point on the road
    Vector3 p1 = pointsRef[i - 1]; Vector3 p2 = pointsRef[i]; //the starting point and the ending point of the section, as seen in the diagrams.
    RaycastHit[] hits = Physics.BoxCastAll((p1 + p2) / 2 + Vector3.up, new Vector3(width, 0.1f, Vector3.Distance(p1, p2) / 2), Vector3.down, Quaternion.Euler(0, Vector3.SignedAngle(p2 - p1, Vector3.forward, Vector3.down), 0), 2, LayerMask.GetMask("Selector"));
    foreach (RaycastHit hit in hits)
        if (hit.collider != road.collider)
            Debug.Log($"{hit.collider}, {hit.point}");
            //the sorting determines the position in the road where the points are, which is crucial for even intersections
            hitList.Sort((a, b) =>
                Vector3 testPoint; Vector3 compPoint; float tThis; float tComp;
                m_SplineSampler.SampleSplinePoint(spline, a.point, (int)(spline.GetLength() * 2), out testPoint, out tThis);
                m_SplineSampler.SampleSplinePoint(spline, b.point, (int)(spline.GetLength() * 2), out compPoint, out tComp);
                if (tThis < tComp)
                    return -1;
                    return 0;

You have read the documentation, right?

Notes: For colliders that overlap the box at the start of the sweep, RaycastHit.normal is set opposite to the direction of the sweep, RaycastHit.distance is set to zero, and the zero vector gets returned in RaycastHit.point. You might want to check whether this is the case in your particular query and perform additional queries to refine the result.

You don’t really seem to actually doing a proper sweep in a particular direction as your “box” is way too large and does already overlap all your colliders at the start. So the physics system does not really have any reference from which “side” it would hit the colliders. You also always cast the sweep downwards and the “length” or your case is always just 2 units. This makes no sense. Your box should be way smaller, the sweep should start at one of your points and the direction should go from one point to the other. The orientation only defines how the box is rotated while it’s casted in worldspace. You essentially tried to use it like an overlap check but somehow expect to get hit information.

I am asking because it did work earlier, and I actually did attempt to program it so that the box would be a few cm higher than the actual colliders so it would not overlap with the colliders that are being targeted.

I increased the distance of the box from the ground and it seems to be well now. The reason I am doing such things in the first place is because I wanted to get the point of the collision, which Overlapping doesn’t seem to be able to do. I wonder, if you can help me, if you can suggest a cleaner way of doing so.