Jump to content

How to determine which side collision occurred for AABB


Chimera
 Share

Recommended Posts

This is a bit of a simple question I feel, but I have been struggling to get it right for a while. 

I am using super simpler AABB collision in my rect based game. I have a bouncing rect which behaves funny when it collides with the player, who is also a rect. The ball 'sticks' and bounces a bit inside the player before bouncing away. I don't have gravity at the moment, or any advanced collision logic. All I am doing is inverting the x or y vectors based on whether the bouncing ball hits the top or sides of another rect. 

I feel like to resolve this issue I should get the displacement value from the overlapping rects and then 'push' the overlapping rect (the ball in this case) away from the second rectangle by using the displacement value as a positive offset. To do this I feel like it would be cleaner to separate the collisions to different sides, or corners? 

Does anyone have any experience in implementing a slightly more advanced version of AABB?

Link to comment
Share on other sites

You just need the size of the intersection to be able to 'push' one object away from the other, but, you may have a bigger problem.

Normally you'd have some variant of this sequence of events:

* Decide where to move next

* Check that location is available

* Perform the move

So, in your issue (as you've described it) you have all the action occurring over two ticks, or, two iterations through the above sequence. Given that you're inverting the velocity of one of the objects, you should only collide once, i.e. if a x movement of 10 brings the ball inside the player (collision) then a movement of -10 in the next tick will move it out again (no collision). This isn't what you're describing though. It's almost like you're checking collisions more frequently than updating movement, which you should avoid (rendering less frequently is fine, but the simulation needs to perform all steps, usually in a set order).

However, there is an additional case here, where both entities are moving, which I suspect might be your issue. A 'push' to resolve overlaps sounds reasonable and I'm pretty sure that is exactly what many physics libraries do. Obviously the less overlaps you create the better, it also makes your bounce code more complex as you'd need to work out the resultant velocities of the 2 (or more) entities for each collision, simply inverting an axis or two won't help.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...