2D Physics Engine Philosophy

I am well into developing my own 2D physics engine, but I have run into a stumbling block in terms of design philosophy. I have collision detection down, that's no problem, but I have no means by which to interpret and act on this situation:

I need to determing what forces are applied on two objects when they collide (i.e. overlap eachother). I have the overlapping area in terms of a polygon, but I am at a loss as to what equations should be applied to this scenario. I have the forces generated by the surfaces of the objects at each point of contact, but how do I apply forces from the area inside the objects such that the "collision" overlap will not be seen?

Let me give an example: If a character is walking on the ground, I am currently able to balance forces between the ground and the character, such that the character recieves a resultant upwards force and moment ("torque", for you non-engineers out there ) that perfectly balances the effects of gravity on the character. Therefore, he is happily standing on the ground, and not falling to an endless doom.

However, if suddenly the character's sprite changes to a different image, one of its feet may now move from resting ontop of the ground, to being inside the ground, which we obviously don't want to have. How do I manage forces in such a way that, with this new image, the character's foot (and therefore, entire body) moves upward and appears to be resting on the surface again? (ie he is now balancing on one leg)

I may be looking at this scenario entirely wrong, so please let me know if there is a better alternative!

With respect to the scenario you described you are looking at it all wrong. Whatever value you use to describe the vertical position of the sprite(not the y axis value but the value which denotes how high in the air it is) should not be allowed to go below 0(or whatever value corresponds to the ground surface).

Quote:With respect to the scenario you described you are looking at it all wrong. Whatever value you use to describe the vertical position of the sprite(not the y axis value but the value which denotes how high in the air it is) should not be allowed to go below 0(or whatever value corresponds to the ground surface).

This is exacly my predicament. I have to handle my objects by their middle when drawing, and thus the lowest point of the image is, as far as the physics engine is concerned, unknown. Thus the only way that I know if some points are "inside" the ground... is if the points are inside the ground, and it's too late to go back.

What I believe you are saying is that the engine should be checking if the lowest point is "inside" the other object, and if it is, move it upwards to compensate. This cannot be applied in my engine, due to the fact that ground itself is a (theoretically), movable object, and this process can be applied to any two collisions. If two random objects collide (say, two equivalent balls), how is one to tell which one of them should be moved to recompensate?

Normally, the lowermost value would not be "below" the ground, but again, because of sudden changes to the sprite images, all of a sudden, it might be. This is my question: once it's there, how do I fix it?

Got collision detection down, just struggling with the collision response eh? Heh, it seems that you've found the hard part that takes 90% of the effort in a physics engine.

Chipmunk fixes overlaps by pushing the objects apart by a fraction of the minimum separation distance along the collision normal each step. That way after a few frames, the objects' overlap will be reduced to a very small amount. To be more specific, along with the usual impulse applied to fix the collision, it also calculates a psuedo-velocity that is reset every frame. The psuedo-velocities basically use the same collision formulas, but salt the normal impulse to make the objects want to move apart the correct amount within the next frame. Using the same basic collision response equation means that it handles interactions between objects of differing mass nicely even when they are stacked up. This is solved as part of the normal solver loop.

It doesn't seem to apply to your case, regardless what I usually did was subdivide time to isolate the instant of collision.. so that there is infintesimal/negligible overlap and apply the reaction force at that instant.

unknown Wrote:It doesn't seem to apply to your case, regardless what I usually did was subdivide time to isolate the instant of collision.. so that there is infintesimal/negligible overlap and apply the reaction force at that instant.

That is indeed what I am doing with normal collisions, but as I mentioned above, that doesn't apply to sudden changes in the shape of an object.

Quote:The psuedo-velocities basically use the same collision formulas, but salt the normal impulse to make the objects want to move apart the correct amount within the next frame

This is what I was getting at, I just need to know how these velocity/force values are derived. What I would like even better, is something that can be deduced from phyisical laws, rather than giving some arbitrary amount. Does such a thing exist? (Bonus points if you say yes )

Quote:Honestly it would really help if you could post an image so I could see exactly how your engine looks and works.

Shunter Wrote:This is what I was getting at, I just need to know how these velocity/force values are derived. What I would like even better, is something that can be deduced from phyisical laws, rather than giving some arbitrary amount. Does such a thing exist? (Bonus points if you say yes )

Nope sorry. No such thing in real life. When is the last time you saw an object suddenly change shape so that it intersects the ground and have the ground push it out of itself? The "correct" thing to do is prevent the overlap from happening in the first place. This is pretty hard to do, so the next best thing is to make something simple that looks plausible. As far as knowing how they are derived, did you look at the link I posted?

As Skorche says, objects don't suddenly change shape in real life. To deal with it in a real-life manner you would have to subdivide your frame, interpolate the shape change and use the edges or vertices to calculate collisions. You could then work out appropriate force for the the two bodies to apply to each other based on velocity and mass.
In the example you gave of a person's foot suddenly intersecting the ground, this is exactly what would have actually happened. I'd imagine Skorche's approach is far more practical however.

clamp means to keep a value within a certain range by picking the closest value in the range. To clamp a value to be positive MAX(0, value), to clamp it to the range [0, 1] MIN(MAX(0, value), 1), etc.

There isn't really much "C" to read through in that example. It's calculating the impulse to apply to each collision point. cpv*() functions are my vector functions, and cpf*() are the float functions. cpvadd(v1, v2) adds two vectors, cpvperp(v) gets a perpendicular vector, etc. You can find them in the cpVect.h header file in the same directory.