Multiple collisions within a single frame cycle?

Question

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.

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!

Answer 1

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.

Answer 2

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.