9
\$\begingroup\$

I've implemented simple 3D game physics engine. I already have decent collision detection in place, now I'm trying to figure out the collision response part. I'm using impulse based method to calculate the post-collision velocities. This works pretty well, however, it does not completely prevent the bodies to keep interpenetrating. So I have additional piece of code to resolve the penetration. Currently, I just move the bodies along the contact normal by half the penetration depth - first body in the direction of the contact normal, second body in the opposite direction.

This is ok most of the time, but there are some undesirable effects. For example, imagine a narrow corridor and an object moving through it. If the object hits one of the walls of the corridor, the penetration resolution moves it into the opposite wall, then in the next frame back into the first wall and so on. The effect is the object is kind of vibrating really fast between the walls which is not pretty.

So my question is whether there is a better way to resolve the penetration? Perhaps not move the bodies, just somehow adjust their velocities (in addition to the impulse computation) so they stop moving toward each other and the penetration resolves itself in the next couple of frames. I'm just guessing here. Any ideas?

Improve this question
\$\endgroup\$

2 Answers 2

Reset to default
3
\$\begingroup\$

When you detect a collision, determine at what time / point the bodies first started colliding, and treat the collision at this point. You may still have a slight penetration to resolve at this point, but it will be much smaller and [typically] won't yield the oscillation issues you're having.

Lets say that you have 100ms simulation steps and that in some frame, you have two balls that collide half way (50ms) into the frame. First, you'll detect that they collided at any point in the frame (which I trust you're already doing effectively). They you'll determine at what point during the frame they collided. Now handle the collision, including the first 50ms of the frame in which they didn't collide. You'll now have the balls' new velocities, and you can also take steps now to ensure that they aren't penetrating (these should be very small since it "just happened.") Finally, you'll simulate the next 50s of the frame. Note that during this period, there may very well be another collision with one or both of these balls.

Improve this answer
\$\endgroup\$
4
  • 1
    \$\begingroup\$ So you are basically suggesting to implement continuous collision detection and then handle the penetrations still left the same way I already do, since they will likely be very small. This could work I suppose. Now I only have to figure out how to make my collision detection continuous :) \$\endgroup\$
    – adam
    Jan 12, 2012 at 21:43
  • \$\begingroup\$ Not sure what you mean by continuous. Strictly speaking, there is nothing continuous in physics simulation, as everything is always broken down in to some size discrete steps. Taking smaller steps, which is essentially what I suggest, will yield much smaller (and easier to correct) errors. Another way to think about this is that there is a direct relationship between step size and errors (such as penetration). So when you detect such an error, break up into smaller steps until the error is trivially fixable. \$\endgroup\$
    – notlesh
    Jan 12, 2012 at 22:10
  • \$\begingroup\$ Continuous collision detection means that instead of checking intersection between two static objects (a 3d problem), you check contact of two moving objects (basically, a 4d problem). Usually it's enough to consider only constant velocities, because you can approximate the trajectories with piecewise linear curves. The advantage is that the penetration distance will always be zero (or close to, due to float rounding errors). I though you were talking about this, but maybe I misinterpreted your answer? \$\endgroup\$
    – adam
    Jan 16, 2012 at 12:00
  • \$\begingroup\$ @adam Yes, that's what I'm talking about. \$\endgroup\$
    – notlesh
    Jan 16, 2012 at 17:47
2
\$\begingroup\$

Check out this article -- which has been posted here many times before, just search through the collision-detection tagged Q&As -- it shows you how to do the "continuous" collision resolution that stephelton was talking about:

http://www.gamasutra.com/view/feature/3383/simple_intersection_tests_for_games.php?page=3

Basically, you solve some basic kinematics equations for the exact timepoint when your two bounding boxes began to intersect. You resolve your collisions at that exact moment, and then proceed with the remaining time in your frame. You might have to re-simulate what happens after the moment of collision, since the velocities/accelerations of your objects will have changed. But there is your starting point, anyway... cheers!

Improve this answer
\$\endgroup\$
1
  • \$\begingroup\$ Thanks, checked the article. Thing is I'm using different representation of my objects. I'm using convex polyhedra and testing the collision using separating axis theorem. This can be extended to handle bodies moving with constant linear velocities (which I know how to do), but no idea how to handle also angular velocities. But I'll ask separate question if I decide to go this way. \$\endgroup\$
    – adam
    Jan 16, 2012 at 12:04

You must log in to answer this question.

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