Anyways, I have created a program that sort of mocks the physics when dealing with balls. Each ball is a game object (my own class) and they all are the same size and texture.

The way I handle collisions between them (after detecting a collision with a simple BoundingSphere) is that I will simply swap the two object's velocity with each other. The velocity is a Vector3 describing the x,y velocities. (z is always 0).

 This seems to work fine when there are only a few objects. But when I have multiple objects collide at the same time, I run into the problem where the objects severely overlap each other and become almost bound together. They seem to form bigger objects made up of multiple balls in a blob-shape fashion.

One-possible solution I thought of is to manually position the balls apart from each other if they overlap too much. But this would probably cause problems if there are like 5 balls colliding at the same time.

I am just wondering if anyone has any experience or input on this.

Thanks.

My advice is maybe to ignore collisions between two balls if they have already collided in the last few frames, or stop checking collisions between two balls until they are not inside each other anymore

how I coded my physics engine was to add velocity to a ball in the opposite direction of the ball it just collided with (or the average of multiple balls).

Kmullins:

One-possible solution I thought of is to manually position the balls apart from each other if they overlap too much. But this would probably cause problems if there are like 5 balls colliding at the same time.

It depends on how realistic (in terms of response direction) you want your collisions to appear. If some level realism is needed, you must separate anyways to determine a 'contactPointToballCenter' vector to determine resolution velocity vectors. Usually this separation takes care of binding issues as you were thinking. I made a billiards game and resolved the binding issues by separating the balls. Rarely in billiards do you have 5 balls colliding all at once though. My sepatation scheme works well even in the break where all balls are positioned close together. I can only get binding to occur when I set the velocity magnitude unrealisticly high(for pool) and the resolution vector is approx 180 deg.

 I am a little confused about the "'contactPointToballCenter" that Steve mentioned. Would this just describe the distance from the center of the ball to the point of contact with the colliding object? Also, I've never taken any physics classes but could you point me in the right direction on the term "Resolution Velocity" you mentioned? I tried to find information online about it but I am more confused about the subject. Thanks Steve.

Kmullins:

I am a little confused about the "'contactPointToballCenter" that Steve mentioned....  Also, I've never taken any physics classes but could you point me in the right direction on the term "Resolution Velocity" you mentioned?

contactPointToBallCenter was a descriptive name that represents a vector between the spot on the ball that first contacts an object to the ball's center of mass. Usually it is called the "collision Normal" or "contact Normal". It is used to help determine the "rebound" or "deflection" direction that the ball will travel after collision. That direction is what I referred to as resolution Velocity (as in "collision resolution"). The velocity vector the ball takes after the collision.

Here's why finding the collision normal is important. If a ball is rolling towards a wall but at an angle (not perp, not parallel), there is a component of it's velocity that is parallel to the wall and a component of its velocity that is perpendicular to the wall. These two components add up to make up the ball's velocity vector. After collision, only the component that is perpendicular to the wall is reversed. The component that runs parallel remains as it was. If the wall happened to run along the x axis (and your working a 2d game) then the after collision velocity is (x,-y) where (x,y) was the velocity before the collision. So when the wall runs along x, or y axis, it is relatively easy to resolve the new velocity. But when the wall runs along at an arbitrary angle, you must use a coordinate framework that relates the velocity components not to x & y but to that of parallel & perpendicular so that after collision you can reverse the perpendicular component. The "collision normal" or "contactPointToballCenter"  is part of that perpendicular component. Now, unlike a wall, when two balls collide, they do not reverse their perpendicular components but they trade perpendicular components with each other(assuming equal mass). Both of their parallel components remain just as before the collision. When this trade occurs, it looks just like two pool balls hitting each other would.

Here is a link to a site that gives a basic overview

here is code I use to separate the balls at collision for secondary collisions only. For a primary collisions (cue ball to target ball) I back the cue ball up along its velocity vector just far enough to where they touch. In pool, luckily, the target ball is always stationary for a primary collision.