Search Unity

BoxCastAll always gives zero vector for "point"

Discussion in 'Physics' started by Runetass, Feb 9, 2016.

  1. Runetass

    Runetass

    Joined:
    Jun 4, 2013
    Posts:
    16
    Problem: Checking for rayhit.point always gives (0,0,0). Consistent between several tests. Doesn't start in any collider. Shape, size has no effect. How do you get the actual collision point from this? It really makes sense to use the boxcast since it can be oriented and (I think) called at the time of my own choosing, as opposed to OnCollision(...).

    Ultimate goal: Check for collision points between colliders multiple times per frame (so in a while loop).

    Code (CSharp):
    1. RaycastHit[] hits = Physics.BoxCastAll(transform.position, Vector3.one, Vector3.one, transform.rotation, 0f, allowedCollisions);
    2.  
    3.         foreach (RaycastHit rayhit in hits)
    4.         {
    5.             //Ignore any self collision
    6.             if (rayhit.transform.root.GetInstanceID() == transform.root.GetInstanceID())
    7.             {
    8.                 continue;
    9.             }
    10.  
    11.             print("Collided with " + rayhit.transform.name);
    12.             print("Point: " + rayhit.point);
    13.         }
    Documentation: Notes: For colliders that overlap the box at the start of the sweep, the output direction is set opposite to the direction of the sweep, distance is set to zero as well as zero vector gets returned in the position field of the RaycastHit structure. You might want to check whether this is the case in your particular query and perform additional queries to refine the result.

    I have included a unitypackage to illustrate the issue as simply as possible.
     

    Attached Files:

  2. Hyblademin

    Hyblademin

    Joined:
    Oct 14, 2013
    Posts:
    725
    What exactly do you mean by "doesn't start in any collider"?

    Since you're using a maxDistance of 0, it seems it would need to overlap a collider at the first iteration of the cast, otherwise there will be no detection.

    Given that, I'd offer this theory: for area and volume casts, as opposed to plain raycasts, the point property does not return the actual intersection point with a collider, but rather the center point of the area/volume when it intersects. Since your "cast" is essentially a single-iteration of a box overlap check at one position, you will always get the zero vector in point if there is an intersection.

    I can't test this myself at the moment, and I haven't ever tried returning the point on a volume cast, so I don't know if this is true.
     
  3. Runetass

    Runetass

    Joined:
    Jun 4, 2013
    Posts:
    16
    What you said about maxDistance makes sense, yeah. That's probably what it means, overlapping at the first iteration, so I misunderstood that part. Tried it out, and getting some point data indeed.

    It doesn't return the center point exactly. I can't make anything consistent out of what it gets, you can see what happened, here:



    Comparing with other volume collisions like the Collision of OnCollisionEnter, they are different. They have potentially many collisions (stored in an array), and they seem to use the edge of the collider somehow, so also not very pinpoint.

    Is there any alternative to BoxCasting? It seems unideal, since I basically have the shape I want to use (not shown in the test video), and projecting it in a set direction breaks the ways I intended to use it (basically just as a collision box that I can check multiple times per frame). It's still possible I could use the rigidbody's velocity to get an accurate 'direction', but if there are alternatives, I'd like to try them before settling with some kind of projection based thing that seems irrelevant in my case.