So say you want to simulate several objects in two dimensions, just bouncing around in a finite space. Using AABB and sweep tests, it shouldn't be that complicated to calculate single collisions between objects. But if you want to have an object bounce off another surface in the same frame (one collision), how do you account for any additional collisions after that first one? This might not make much sense, so I put a little graphic together to explain what I mean.

Collision representation

So say all this is happening in one frame cycle. The gray box moves up and bounces off the wall on the top; that's easy enough. That orange box is the problem, though. How do I calculate that collision as well (where the two translucent boxes are)? OR, if the frame rate is high enough, does it even matter? Thanks!

  • 1
    \$\begingroup\$ No time to write a full answer, but this might help or at least contain useful reference literature: Cohen, Lin, Manocha, Ponamgi "Interactive and Exact Collision Detection for MultiBody Environments" (1994) \$\endgroup\$ Aug 22, 2012 at 13:46
  • \$\begingroup\$ Is this an actual problem you are experiencing? \$\endgroup\$ Aug 22, 2012 at 16:53
  • \$\begingroup\$ @MartinSojka - Thanks! Just took a quick breeze through that, it looks cool. I'll give it a more in-depth read when I get the chance. \$\endgroup\$ Aug 22, 2012 at 17:49
  • \$\begingroup\$ @NoobsArePeople2 - Not a problem at the moment, but more of a concern. I'm slowly clunking along on some collision handling code and it struck me as something worth investigating before I put everything together. \$\endgroup\$ Aug 22, 2012 at 17:49
  • 1
    \$\begingroup\$ @ChrisLangford In that case, I wouldn't rule this out as a problem that potentially might occur at some point. That said I wouldn't worry about it too much, instead focus on getting your system up and running. Then test and test and test to see a) if you can make this happen and b) if it does happen is the situation within the bounds of your application (i.e., under enough strain most (all?) systems will buckle and break but that point might not matter for your purposes). \$\endgroup\$ Aug 22, 2012 at 18:42

2 Answers 2


It's quite a special case you are describing :) Most physics engines would probably not handle it exactly but would do something that's "good enough". If you really want something like this then you might want to look into Continous Collision Detection (CCD). I think Box2D can handle this for some objects by declaring them as "bullet" for example so you could check out the source for that. You might also want to look into speculative contacts which I think is described in a good way at Jitter physics.

If your requirements are not extreme or your timestep small then a simpler solution might be acceptable. One way to handle it is by running several iterations of the collision handling and recalculating closing velocities for the involved bodies (collision island) after each handled collision. This would, however, not actually detect new collisions like you describe but I don't think it will be necessary for most cases.


As a potential solution, you could break down your updates and frames so that you update multiple times per render frame. This comes with a change where you have to account for the number of times you are updating because if you simply update 10 times more at the same speed your game just moves 10x faster with 10x less frames.

Once you have that accounted for, you will find that if you are updating 10 times per frame, the first collision will occur perhaps on update 4, handle for it by adjusting your velocity, etc. and then maybe on update 7 the final collision occurs and you can handle it accordingly and use the proper velocity, etc. for the last 3 updates.

Obviously this is going to add some processing time to your game so make sure you are only updating what is necessary for your situation. You can in fact, take this one step further and separate things out even more. You could draw every X updates, handle input every Y updates, update physics every Z udpates, etc. Also, make sure that the number of times you update makes sense for how your game works. If you don't have to update 10 times a frame because not that much happens within a single frame, then lower the number of updates.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .