Collision Detection

At this point you should be familiar with functions, animations, and if statements. This tutorial introduces collision detection, which allows you to determine when two shapes touch. If you can determine that two shapes touch, you can trigger some action- think of detecting when the user has moused over a button, or when a game character touches the floor or a badguy, or when your animation reaches a certain state.


This is a companion discussion topic for the original entry at https://happycoding.io/tutorials/processing/collision-detection

In your tutorial on collision detection where a moving rectangle collides with a stationary center rectangle it appears to fail if the moving rectangle is moving at 1 pixel speed in both the x and y and collides exactly on the corner of the center stationary rectangle. This because on the next frame the x and y individually fail. Can you confirm this and suggest a fix for this.

This was precisely what i was looking for but am not sure if i have got something wrong.

Many thanks in advance.

Greg

Hey Greg, in what way does it fail for you?

Here’s what I see:

cd

Is that different from what you’re seeing?

A bit further checking and the problem is irrespective of the x and y speeds as long as there is an x and y speed both moving towards the center rectangle. The bouncing rectangle must be touching the corner but not overlapping the center rectangle. In this scenario it fails to detect the collision.

However, this may not be too much of a problem as the collision detection does work on the next frame after the bouncing rectangle has moved on this frame. Not ideal but may be okay.

A possible solution might be to ensure, for example, if you are moving at say 1 pixel per frame change it to 1.01 pixels per frame. This will look like it is butting up to center rectangle but will infact be probably overlapping by some smalll fraction of a pixel internally but not visibly.

I think it might depend on how we define a collision. If the bouncing rectangle is touching the corner but not overlapping, is that really a collision? What if the bouncing rectangle stopped, or started going straight down or straight right instead of going diagonally?

I personally think that’s it’s correct that touching but not overlapping is not counted as collision.

In fact, I think you could ask a similar question about collision on an edge, not on a corner. If the bouncing rectangle is touching but not overlapping the center rectangle, that won’t be counted as a collision no matter if it’s in the corner or not.

If you’re worried that the bouncing rectangle might overlap with the center rectangle for a frame, you can try snapping it to an edge when a collision is detected.

Does that make sense, or are you worried about something else?

I dont think i explained myself very clearly so hopefully this will be clearer. Im more curious than anything else.

1 Like

Hi Kevin.

I must first apologise as it seems i may of been a little arrogant and a touch pushy. Sorry for that.

If i may explain my drawing above.

As you can see the 2 objects do not overlap and therefore do not collide. So when the 2 algorithms are run you would expect them to detect that i will collide if i continue to move and therefore reverse the bouncingrect x & y. It does not do this until the next frame after they have collided. Despite what i said your algorithms do not fail, it is simply a little oddity on this precise situation. You are absolutely correct when you say that a check for this can be done and the bouncingrect can be repositioned.

Thank you for a great and simple algorithm :+1:

1 Like

No worries, I didn’t take it that way.

But I totally get what you’re saying. This is interesting because I think there’s a difference in how we as humans think of collision, and what the code is telling the computer to do.

In our human brains, we know that the bouncing rectangle is moving towards the center rectangle, so we see the case you’re describing (where the rectangles are touching but not overlapping yet) as a collision. But I think that’s because our brains are pattern matching based on our expectations, which the computer isn’t smart enough to do.

To explain what I mean, imagine that we’re using this collision detection algorithm in a game where you control a car (with a rectangle bounding box) that’s driving around obstacles (also with rectangle bounding boxes). If somebody is really good at the game, they might be able to maneuver the car so it barely passes by an obstacle. Should this be a collision?

You might say that it depends on the direction of the car, but what if on the last frame I was moving to the upper right, but on the next frame I’m only going to be moving up?

Or think about it in reverse: what if this is for a game where I need to make sure one rectangle is touching another one, and I lose if they stop overlapping? Should the “touching but not quite overlapping” case count as overlapping?

Part of what makes this interesting to me is that there aren’t right or wrong answers to those questions. It depends on exactly what behavior you want!

Another way around this is to add a third if statement that checks what would happen if both x and y were updated. But whether you want that depends on your exact goal.

Hi everyone,
I am pleased to speak briefly in this beautiful forum after a long time !
I’m very interested in the subject of collisions (on another occasion I will send my own little algorithms).
My language is Italian, but I believe that in this case there is no difference with the English language: I would like to invite everyone to reflect on the difference between contact and collision.
I also ask myself: are the vertical sides of two different polygons having the same x (abscissa) intersected or overlapped (especially in the field of integers, like a “simple pixel area”)?
Bye and good reasoning to all ! :grinning: :wave:

1 Like

image 2
Hi Kevin, I found a typo here :point_up_2:

Thanks, fixed!