How can I convert Physics2D.Raycast to Physics2D.BoxCast to yield the same results?

Question

This question has been updated to better reflect my current issue, and some of the progress made while solving it.

I've been working on a 2D character controller that uses raycasting to detect collisions with objects. Since Physics2D.Raycast and Physics2D.BoxCast both return a RaycastHit2D object, I was hoping to convert my raycast detection to boxcast detection, but I've been having trouble understanding how to do it. Unity's scripting API is a little vague on how BoxCast actually works; specifically, I don't understand the difference in use between the size and distance parameters.

My current method works like this:

• I get the bounds of my box collider, and fire a raycast with an origin point.y of skinWidth inside the collider (this ensures that collisions can still be detected when the character is flat on the ground). skinWidth is a very small number (like .015f) used to achieve this result.
• If I'm moving down, the raycast is fired from the bottom center (center.x, min.y) of my collider, otherwise it's fired from the top center.
• The length of the raycast this frame is determined by deltaMovement.y + skinWidth, which is a reference to my character's velocity, but represents the change in movement this frame; this is also a small number. skinWidth is added back to this value to compensate for the ray beginning inside the box.
• If the raycast hits the ground, deltaMovement is updated to be equal to the (hit.distance - skinWidth) * velocityDir. This means our character will move another hit.distance - skinWidth more before colliding with an object. skinWidth is subtracted because I added it to the ray's length, and I multiply by velocityDir to maintain my direction because hit.distance is always a positive value, even when moving down.

Here's what this looks like in code (this works exactly as I'd like):

private void CollideVertically(ref Vector2 deltaMovement)
{
    float velocityDir = Mathf.Sign(deltaMovement.y);
    float raycastLength = Mathf.Abs(deltaMovement.y) + skinWidth;
    Vector2 origin = (velocityDir == -1) ? bottomCenter : topCenter;

    //this makes the raycast move with the character on the x axis
    origin.x += deltaMovement.x 

    RaycastHit2D hit = Physics2D.Raycast(origin, Vector2.up * velocityDir, raycastLength, verticalCollisionMask);

    if (hit)
    {
        deltaMovement.y = (hit.distance - skinWidth) * velocityDir;
        State.IsCollidingAbove = velocityDir == 1;
        State.IsCollidingBelow = velocityDir == -1;
    }
}

I thought adapting this to work with boxcasts would be easy; after all, Physics2D.BoxCast has many of the same parameters. I ran into some issues, though, but here's my code:

private void CollideVertically(ref Vector2 deltaMovement)
{
    float velocityDir = Mathf.Sign(deltaMovement.y);
    float raycastLength = Mathf.Abs(deltaMovement.y) + skinWidth;
    Vector2 origin = (velocityDir == -1) ? bottomCenter : topCenter;
    origin.x += deltaMovement.x;
    Vector2 size = new Vector2(boxCollider.size.x, .02f);

    RaycastHit2D hit = Physics2D.BoxCast(origin, size, 0, Vector2.up * directionY, raycastLength, verticalCollisionMask);

    if (hit)
    {
        deltaMovement.y = hit.distance * velocityDir;
        State.IsCollidingBelow = velocityDir == -1;
        State.IsCollidingAbove = velocityDir == 1;
    }
}

One of the issues with this is simply how my character "feels" when using this method vs my raycast method. The movement doesn't feel quite as tight. Similarly, I have to use the arbitrary value of .02f as the box's size.y in order to make my character be flat on the ground. I've tried other values like skinWidth, or something like .03f, but these put my collider slightly in the ground or above it. I had initially used raycastLength as both the box's size.y and the distance parameter of the boxcast method, but this was inconsistent, and I think it produced "too much" of a box when casting (I was frequently colliding when my character was still airborne).

I also don't understand why I don't have to take away skinWidth in the line deltaMovement.y = hit.distance * velocityDir. I had been subtracting it, but this was producing a lot of bouncing; the movement wasn't right at all.

Ultimately, this related question helps explain why I want to use boxcasting. Instead of using many rays, each of which has a gap between it and the next ray, I'd like to use a boxcast to simulate a solid "sheet" of rays that can determine my collisions. Imagine a scenario in which the character is on the peak of a mountain; raycasts (with the aforementioned gaps) might miss this sharp point, but a boxcast will hit it, and that hit point will determine the character's movement.

Here's a little visualization I made about the two approaches: https://i.sstatic.net/GYZS3.jpg Am I thinking about this correctly? Should I be using Physics2D.OverlapBox instead?

Answer 1

I would very highly recommend that you visualise (using Debug.Draw... methods) your collision hit points/contacts and normals to better understand what's going on - actually, I'd say output all the info that RaycastHit2D gives you after a BoxCast2D. The main catch with BoxCast2D is that the hit point won't necessarily be "on the edge" of your collider (as it's the case with Raycast2D) - it can very likely be inside of your collider. Here's an image of how your BoxCast2D might behave:

If what you're trying to achieve is a precise "push out of collision" behaviour, you'll need to use BoxCast2D in tandem with Physics2D.Distance.

1) You BoxCast2D in the direction of movement.

2) Move your BoxCollider2D to the position where BoxCast2D collision happened (hit.centroid is where the box of a BoxCast2D was positioned when the hit happened).

3) Use Physics2D.Distance to find out how much you should push out your BoxCollider2D out of collision.

Answer 2

I think it's useful to visualize the physics 'Cast' operations as an object being thrown in a straight line and stopping when it hits another object (collider).

Size is the size of the box being "thrown".

Distance is how long that box is "thrown" in said direction.

---

When dealing with game physics an approach generally taken is to update positions, then calculate collisions and correct overlaps. This is done because it's very robust and easy. Trying to prevent overlaps before they happen (which it seems like you are trying to) is much harder and more prone to errors.

Translating that to your example that would mean:

1. Add user input to velocity

2. Add gravity to velocity

3. Move by velocity*Time.deltaTime (velocity is movement divided by time, so by multiplying with time you get movement)

4. Detect collisions and fix overlap

Your code would be the part slotted into nr 4 in that list.

Here's what I'd suggest:

2 & 3.

//in Update/FixedUpdate in controller script (use fixedDeltaTime if in FixedUpdate)
velocity += gravity*Time.deltaTime; //Gravity is an acceleration
transform.Translate(velocity*Time.deltaTime);

4.

void CollideVertically(){
    float velocityDir = Mathf.Sign(velocity.y);
    Vector2 size = new Vector2(boxCollider.size.x, boxCollider.size.y*0.1f);
    float rayLength = boxCollider.size.y/2 - boxCollider.size.y*0.1f/2; //Subtract how much the box being cast overshoots length
    RaycastHit2D hit = Physics2D.BoxCast(transform.position, size, 0, Vector2.up*velocityDir, rayLength);
    if (hit){
        velocity.y = 0;
        var overlap = transform.position.y + boxCollider.size.y/2 * velocityDir - hit.point.y;
        transform.Translate(new Vector3(0, -overlap, 0));
    }
}

You'll need a CollideHorizontally as well, which needs to execute before the vertical one to ensure that you can't climb up walls. But that should be identical to the vertical one, only with reversed X and Y.

As for the input movement (step 1), that will vary wildly from game to game, so that's entirely up to you.

Hope that helps :)

Answer 3

Unity has collision detection and collison resolution built in. If you want to know what collider your character is standing on, use OnCollisionEnter. No need to reinvent the wheel using raycasts.

If you want to know about colliders nearby, i.e. colliders a fixed distance away from your character but not yet touching it, use a trigger volume and OnTriggerEnter.

However, if for some reason you really need to know about colliders a dynamic distance away from your character, e.g. for predicting future collisions, a box cast comes in handy. Note the difference between Physics.BoxCast and Physics.OverlapBox though, a box cast moves the box along a line.

The reason why your code is not working is because you need to offset the origin of the cast by the half-extents of the box so that the entire box starts within your character bounds. If you start the cast near the bottom of your character bounds then half of the box already overlaps with the outside world.

Answer 4

So after trying some more things today, I've got this working about as well as I think I can. Here's the boxcast method:

private void CollideVertically(ref Vector2 deltaMovement)
{
    float velocityDir = Mathf.Sign(deltaMovement.y);
    float raycastLength = Mathf.Abs(deltaMovement.y);
    Vector2 origin = (velocityDir == -1) ? bottomCenter : topCenter;
    origin.x += deltaMovement.x;
    Vector2 size = new Vector2(boxCollider.size.x - skinWidth * 2, 2 * skinWidth);

    RaycastHit2D hit = Physics2D.BoxCast(origin, size, 0, Vector2.up * directionY, raycastLength, verticalCollisionMask);

    if (hit)
    {
        deltaMovement.y = hit.distance * velocityDir;
        State.IsCollidingBelow = velocityDir == -1;
        State.IsCollidingAbove = velocityDir == 1;
    }
}

The relatively simple changes that I made were to:

1. Remove the addition of skinWidth to raycastLength
2. Make the size.y of the boxcast 2 * skinWidth
3. Remove the subtraction of skinWidth from deltaMovement.y
4. Subtract 2 * skinWidth from the boxcast's size.x (not important for the issues in this question, but prevents clipping on walls/corners)

The reason points 1 and 2 are important is because the size.y of the boxcast makes up for the skinWidth needed in the raycast method. In the raycast method I was adding skinWidth to raycastLength so that the length would always reach outside of my collider (remember that the rays start from inside the collider). By removing this in the boxcast method, and making the boxcast have a size.y of skinWidth * 2, the bottom half of the boxcast acts as the "made up" length that I was using in the raycast method. In addition, since I'm no longer adding it to raycastLength, skinWidth does not need to be removed from deltaMovement.y = hit.distance * velocityDir.

With that being said, this method still doesn't produce a completely accurate collision when compared to the raycast method. For example, my position is still off by .005f using a boxcast, and my character is still ever so slightly landing off the floor (you have to zoom is quite far in the scene view to see this, but there is no visible gap using raycasts). While this is still very accurate, I'm wondering if this discrepancy would cause collision issues once more (complex) functionality is added to the controller.

@Karl Ramstedt presented an alternative in which collisions are resolved after moving the character, and this might be a better/more reliable approach. I would still appreciate some feedback if anybody has anything else to contribute.