Basic Collision Concepts like Impulse

In real life, when two objects collide they exert forces on one another, not velocity changes. (I am deliberately avoiding some low level details of how the forces are generated, to keep this email shorter.)

Once collision response forces have developed, they continue for a short period of time, the collision response time. They are not, in reality, instantaneous. The collision response forces cause the object to accelerate (in such a direction that avoids the geometries interpenetrating and satisfying the relevant conservation laws), and it is this acceleration that results in a change of velocity.

In simulating physics, some techniques (such as the penalty method technique) do generate forces during collision...directly simulating the real world (er...approximately). But, it can be a challenge to do this type of simulation in a way that is numerically stable.

Other physics simulation techniques use the idea of "impulse momentum" response, which is the thing you typically see in undergraduate or high school physics textbooks...the two billard balls colliding and having an instantaneous change of velocity without directly modeling the response forces. This technique takes the idea that the collision does occur instantaneously...just an approximation. The guts of the technique integrate the collision response force over time, and this time-integrated force is the "impulse." The formulas seen in introductory physics textbooks solve for the velocity change directly, and so you don't necessarily even see a full description of impulse....it appears that it is velocity that the objects exchange, when in fact even this approach has its basis in a force applied over time with acceleration causing the velocity change.

As for the collision normal, the approach you describe is sort of correct. Remember, in true collision response, the objects exert a force on each other (same force, opposite direction on each object). The force causes acceleration that pushes them away from each other. The impulse-momentum approach simply computes a new velocity with instantaneous acceleration. So, if you do things this way, you do not explicitly move the objects apart. You just let the physics system use the new velocity so that the naturally move apart over time. There can be numerical stability problems with this approach, depending on the duration of the time step and in the case of multiple simultaneous collisions. And, so people have developed new stabilizing approaches that do explicitly project the objects apart at the time of collision. There is a lot of discussion of this type of idea here, and over at the forums for the Bullet physics library:

Bullet Continuous Collision Detection and Physics Library

I hope this helps. Or at least helps you to ask an evolved set of new questions!

[Edited by - grhodes_at_work on July 1, 2007 4:03:12 PM]

Thank you Graham for a superbly detailed reply. To be frank there has only been so much of it I could realistically absorb given the level of detail you went into.

I understood that one of the methods you describe does indeed appear to wait for an applied force/acceleration to change. The book I'm reading Game Physics Engine Development by Ian Millington deals with things differently. I popped home to my flat today after posting my initial reply and did yet more reading and discovered that Ian does indeed use a complete departure from the complex interactions you describe to model the physics in the engine.

He describes the application of forces in non-contact situations as obeying the normal laws of motion whilst using 'impulse' during collisions to alter velocities only. He makes a clear distinction between the two. IIRC he uses a nice system based on the inverse of the objects mass to determine the rate at which they seperate.

It's beginning to come together but I find this hard going and if you don't mind Graham I shall print this topic off and have a really good dig into your reply as at present I have had time only to skim it.

I am aiming at an MMOG so my physics engine does obviously not want to be too complex because even though the client side will be performing its own physics calculations obviously there will have to be a solid reference on the server which 'corrects' the clients every so often. Basically this means that (although they won't have to be rendered) all physics calculations for all client objects will have to be instantaneously computed on the server as a hard reference which clients obtain updates from depending on their connection speed.

I'm not looking forward (well actually I am) to learning about parallel networks and the knowledge needed to do this.

Hence I apologise in advance if I seem to eager to simplify things but I'm sure you can see why that is my aim :o)

Thanks again Graham I'll shall post again when I've had chance to really get to grips with your comments. This looks like a great forum.

*Edit* I have now read your reply thoroughly Graham thank you. It is going in my reference folder as it's the best explanation of events I've had yet.

[Edited by - adder_noir on July 1, 2007 4:45:19 PM]

Chris,

Glad I could help. That reply was quickly written, and I even just now tweaked it (mostly to try to avoid nit picking by other experts here!).

I would like to give myself a plug...I wrote the real-time game physics chapter in the book "Introduction to Game Development" published by Charles River Media (edited by Steve Rabin). Its a quite long chapter, which I wrote for a true newbie physics audience (but fast learners). It does dig into the theoretical details of the impulse momentum approach, how it differs from the real world, and the pros and cons of using something like this vs. an alternate approach for collision response. I don't know Ian's book----I think its the only game physics book I don't have a copy of, and there may be duplication. His may be better. But I'm proud of my work, and enjoy teaching, and so perhaps if you happen to go to a large bookstore you can browse it to see if you like it!

Warm Regards,

I found it easily on Amazon. I'm living on benefit at the moment, but as soon as I have some cash I think I will do thee the honour of purchasing that said book, and of course shall read that chapter :o)

I've found it very helpful to seperate forces which act over the entire time step and the relatively "instantaneous" forces which act during collisions-- basically directly changing objects' velocities.

This is an excellent resource. It should bring you up to speed with the theory without going into implementation details that necessarily should come after.

Thanks for the headsup mate I've been working through Chris Hecker's articles for a while now.

I never really considered looking at it that way, by seperating the forces out in such a fashion. I wonder how this would be implemented in code though.

Surely at the end of each time frame where the forces occur one must simply sum the forces acting on the object to produce the acceleration required. I wonder how this approach avoids interpenetration of fast moving objects? I would have thought at some point an instantaneous velocity change must occur, although I suspect this would be hard to model accurately and make it look right. Plus how does one combine instantaneous velocity changes with frame duration acting forces?

I know all the things I'm asking are catered for, but I wonder could someone explain how? :o)

Interpenetration isn't usually avoided completely. That is quite difficult and computationally expensive to do. Though some of the techniques correct for it pretty well, there are usually going to be cases where you can spot interpenetration.

There's been some interesting work in the past couple of years (I think) at UNC-Chapel Hill and probably other places that adds localized surface deformation, using a deformation texture, around points of collision. The idea here is to better mimic the real world, where objects do in fact deform when the collide. (It is this deformation that generates the internally stresses that cause the object to rebound its shape and push back on the other object....the forces that cause separation.) The deformation texture technique works pretty well when collision proxy interpenetration is minimal:

Dynamic Deformation Textures

Watch the video...

(Er, there are other techniques, of course, such as simple spring/mass models, that also can model this sort of deformation.)

I'd also recommend Erin Catto's Box2D testbed as a good place to experiment with various collision response techniques.

Game Physics

(See link to Box2D at the top. I'd go to the downloads page and grab the GDC2007 version...)

Cheers again Graham that's great thanks.

If you're using impulses I'd suggest using a Box2D-type approach or Jan Bender's method (http://www.impulse-based.de/) rather than the method given in Millington's book.

That book was quite disappointing, as there was much better info freely available online (Catto and Bender) which present much more robust, general impulse-based methods -- and (more importantly) explain the theory behind them!

Thank you Raigan, I've just given the book quite an average review on Amazon as I'm now 170 pages in and he has completely stopped explaining what he's doing. It's beginning to read more like a diary now than a textbook.

Real, real shame as it started out quite well but it has now gone right down in it's suitability for the non-elite.

Thanks for those references, it appears I will have alot of need for them. Any chance of a link to some of Catto's stuff I can't find it on google (maybe I'm using wrong keywords?).

Thanks again :o)

I should have mentioned, the GamePhysics, page Graham linked to above is Erin Catto's: www.gphysics.com

It took me several weeks to really understand Box2D, I had to crack open the linear algebra text and relearn matrix math. His presentations+source are the best introduction to impulse-based methods I've found, but definitely check out Bender's method too -- it's better for joints.

Thanks Raigan, that's a big help [smile]