next »

[TakeV]

Right now, I am working on a game for the 360/PC, using the XNA framework. It is a 2 dimensional cave-shooter type thing, with newtonian physics. However, I've run into a bit of a snag, in that I'm not sure how to handle collisions, so that a force is applied to both objects correctly.

At the moment, every physics object has the following important information for the physics:
Mass,
InverseMass (Makes calculations simpler),
Position,
Velocity.

Anyone have an idea, or a guide on how to resolve a collision, so that the proper amount of force is applied to both physics objects?

Please note that I've already got collision detection already, thank you.

Thank you,
~TakeV

[zacaj]

I think youd want to be keeping track of acceleration/force too, if youre doing normal rigid body physics.  Basically, you want to move both objects apart just so theyre not colliding.  Each object would have a force applied to it, using F=ma. Object 1 would have object 2's mass*acceleration applied to is as a force, and vice versa.  If your objects are solid, in order not to go through each other, each applies a force equal to the force of the object hitting it to it aswell.  At least thats how it works in the real world, you might have to change it a bit because of limited precision.  Just off the top of my head though.

[TakeV]

Hmm, that would work. What do I get the acceleration from, though?

[Dacke]

Please don't make your own physics engine. You'll make the angels cry. Try to look around for existing solutions.

[Montoli]

The long answer is, if you're wanting the physics to be interesting, and your shapes are anything other than trivial convex solids (circles, for example) then you're going to need to do some maths on them.  A lot of things start mattering, such as the shape of the object, where the collision occurred on each shape, compared to its center of mass, how much energy was lost due to elasticity, etc.  How you represent these depends a lot on what sort of shapes you want to be able to support.  Circles are fairly straightforward.  Concave arbitrary polygons?  Less so.

This is, while not impossible, still a fairly substantial amount of work.  Chris Hecker has some nice tutorials up on the interwebs that might be of use to you.


The short answer is, you might want to consider looking into the Box2d library, which is a fairly robust, open source library used by a lot of people for their physics needs, because physics programming is a significant undertaking.


So yeah.  If you want to go through it yourself (because the math IS kind of cool) then Hecker's webpages are very useful.  If you're just looking to have something working though, seriously look into Box2d.  (It is the reason you've seen so many physics games lately, from Red Star Drop, to Crayon Physics, etc.)

[zacaj]

Chipmunk physics is also good, and very fast.
To get acceleration, just solve F=ma for a.
a=F/m
or
a=f*inversemass

[TakeV]

The long answer is, if you're wanting the physics to be interesting, and your shapes are anything other than trivial convex solids (circles, for example) then you're going to need to do some maths on them.  A lot of things start mattering, such as the shape of the object, where the collision occurred on each shape, compared to its center of mass, how much energy was lost due to elasticity, etc.  How you represent these depends a lot on what sort of shapes you want to be able to support.  Circles are fairly straightforward.  Concave arbitrary polygons?  Less so.

This is, while not impossible, still a fairly substantial amount of work.  Chris Hecker has some nice tutorials up on the interwebs that might be of use to you.

Thank you for your answer, that helps a lot actually. (Though the link is broken, I found it here.)

As for using another physics engine to handle it, thank you, but no thank you. I have a few good reasons for creating my own:

1) I am both a starting computer science major and a physics major, and I wish to do this to get a better grasp on the things I learn.
2) "Don't reinvent the wheel, unless you wish to learn more about wheels"

And a few other reasons that aren't as notable, yet still important.

Regardless, that link seems to have a lot of information to put to use, thank you.

To get acceleration, just solve F=ma for a.
a=F/m
or
a=f*inversemass

The problem with that is, how do you get F? To solve for F, you need a. A bit of a circular problem there.

[Dacke]

Building your own wheel (at least once) is a great idea. But if you are planning to make your own physics engine, you need to start from scratch and structure it properly. You can't have it as a part of your game project to begin with, or you will end up with one big mess.

In high school, me and five other people made a 2D physics engine as school-project (we chose the project on our own and didn't get any assistance, just a grade). We were young and inexperienced and only one of us knew what he was doing. But even so, I'm fairly sure the project felt huge because.. well.. it was huge. After almost year (not full time, mind you, but still) we had a proper physics simulation for rigid convex bodies with the ability to bolt them down (including spinning). But it couldn't handle more than one collision per frame or it'd bug out. We didn't even approach handling resting objects (so we couldn't add gravity). The bugs we had in the final product were so complex, we had no idea how to work them out. I just want to make sure that if you make the commitment to make this, don't expect to have a game running on it any time soon.

Anyway, I looked at our old report. The math we used for the physics we got from www.myphysicslab.com/collision.html
The site still looks pretty good for purposes of learning physics-programming.

Good luck!

[TakeV]

Ah, perhaps I may have miscommunicated the exact nature of what I am doing. I have not set out to create a full physics engine. Angular momentum and other such things will not quite be a factor. All cases will be similar to circle shapes, so there will only be translational movement.

Sorry if I gave another impression.

[Zaphos]

The simplest thing is to just project the circles out of the geometry they're colliding with, and then adjust the velocity so the component-in-the-direction-of-the-projection-vector (ie towards the geometry you collided with) is zero (or, to bounce, is the opposite of what it was ...).  If you have multiple moving objects to handle, you can do this iteratively and just hope it converges to something reasonable.

The n+ tutorials on collision detection and response cover this approach, and are generally nice: http://www.metanetsoftware.com/technique/tutorialA.html

[zacaj]

Usually, youd keep track of force separately, and apply forces to it(like gravity).  But if youre really just looking for collision detection, Zaphos' idea will work well

[Zaphos]

Application of forces like gravity is kind of unrelated to collision response; you can certainly apply a gravity force and still use the projection method to handle collisions.

If you want to use forces explicitly to resolve collisions, you'll probably end up with something like the penalty force method.  Penalty forces are similar to the projection method but instead of 'teleporting' your object along the projection direction to a valid location, you apply a force in that direction, with strength proportional to how much it's penetrated the object.  The goal here is to more-gradually resolve the collision, which can be important for maintaining stability in (for example) a spring mass system, where teleportation might suddenly introduce huge spring forces.  The obvious downside of this is of course that penalties are not instantly resolved.  Another issue is that it does not tend to 'settle' to a resting state very nicely; things tend to jitter back and forth in unsettling ways.  In general it leads to collisions which are more 'squishy,' which doesn't match our concept of a rigid body very well.

Changing the velocity instantaneously is actually nicely formalized as an 'impulse'.  This is actually sort of a physically justified way of handling things, for rigid bodies -- I like the explanation in the rigid body course notes here: http://www.pixar.com/companyinfo/research/pbm2001/

How do we compute the change in velocity?  Any force we might imagine acting at p, no matter
 how strong, would require at least a small amount of time to completely halt the relative motion between the bodies. (No matter how strong your car brakes are, you still need to apply them before you hit the brick wall. If you wait until you’ve contacted the wall, it’s too late...) Since we want bodies to change their velocity instantly though, we postulate a new quantity J called an impulse. An impulse is a vector quantity, just like a force, but it has the units of momentum. Applying an impulse produces an instantaneous change in the velocity of a body. To determine the effects of a given impulse J, we imagine a large force F that acts for a small time interval delta_t. If we let F go to infinity and delta_t go to zero in such a way that F*delta_t = J then we can derive the effect of J on a body’s velocity by considering how the velocity would change if we let the force F act on it for delta_t time.
For example, if we apply an impulse J to a rigid body with mass M, then the change in linear velocity delta_v is simply J / M.

Don't let the formalism scare you -- ultimately this really just boils down to 'correct the velocity at the time of impact to resolve the collision' -- but it's sometimes nice to know that some formal way of thinking about it exists.

Note that changing the position instantly, via projection, is not so justifiable -- to be completely accurate we should solve for the time of collision and apply the impulse *then*, however, doing so would be relatively expensive and raises some tricky problems of its own, like handling resting contact.  At least for a first attempt, I'd recommend sticking to the projection method.

[raigan]

Note that changing the position instantly, via projection, is not so justifiable -- to be completely accurate we should solve for the time of collision and apply the impulse *then*

Isn't projection analogous to impulses? To correct position error, you could apply an impulse and then integrate forward in time to find the new position. Or, you could let the impulse go to infinity and the timestep go to 0, and just find the new position directly.

This is a separate issue from correcting penetration vs trying to find TOI though, the former can use either impulses or projections, while the latter only makes sense for impulses (since at TOI there isn't any position error).

[Zaphos]

I guess you could say it's analogous but it seems much less justifiable, since the instant velocity correction does correspond to our notion of how rigid bodies should behave, but teleportation does not.

[raigan]

Projection out of collision isn't necessarily teleportation, because those object positions don't properly exist -- they're simply guesses/extrapolations. Only at the end of a single prediction-correction cycle can you really consider them actual positions. This is similar to the sweep/prediction tests in used in "Nonconvex Rigid Bodies with Stacking": the overlapping positions are only temporary, used to calculate constraint forces.

I suppose this is all subject to interpretation though

[Zaphos]

Hmm, I think if you try to say something about applying an infinite impulse over zero time, then you really are talking about teleportation?  I do like the prediction-correction interpretation better, though

[TakeV]

Oh wow, a lot of responses now, thank you all.

I eventually went with an impulse system, as you described. It's working for the most part right now, just a few bugs and tweaks to fix. Nothing like seeing a ball fly away off the map at absurdly high speeds from a tap.

Now just need to fix the world collision detection and handling, which is turning into the more troublesome of the two collision types.

Thank you again.