Ben Henry
CMPS161 - Winter '05
Prof. Pang

Final Project - 3D Pool Simulator (7-Ball Physics)

 

For my final project I decided to implement a 3-dimensional pool game. As a program modelling physically-based (physics-based) behavior, I felt that it was appropriate as a final project for this class. This models the motions and actions of billiard (pool) balls in a simulated, 3-D setting.

Unfortunately, at the time, I hadn't really fully considered the planning and work that would go into such a project. The physics seemed straightfoward when thinking about it, but when I got into it, I realized that it was a bit more complicated than I'd originally guessed. As a result, the actual "game" aspect of the project was not realized, but I did eventually get very realistic looking results regarding the behavior of the balls on the table.

 

Usage

- This program is very straightfoward and easy to use. All interactions are done between the mouse and keyboard (well, spacebar).

MOUSE INTERACTIONS:

Mouse Left while any mouse button pressed: Camera angle left

Mouse Right while any mouse button pressed: Camera angle right
Force Slider on gui determines amount of force upon strike

KEYBOARD INTERACTIONS:

Space Bar pressed: Takes shot any given force

 

 

The Physics Involved...

 

The physical calculations involved in this program were the most challenging part of the program. As an animator, one must always think in terms of frames. Before a new frame is drawn, new physical calculations must be performed. For a single-ball model this is very-easy to implement, but we must consider that we may have many balls (in pool, up to 16, but it should still work with more balls.

FORCES IN ACTION AS BALL ROLLS ALONG TABLE:

To begin, the ball is "struck" by the cue stick. The cue ball is imparted with force from the cue. The force, as mentioned above, is an arbitrary number determined by the user on the bottom slider.

As the ball rolls along the table surface, two forces are acting upon it, DAMPING and FRICTION. Damping slows the ball down at a linear rate compared to the balls velocity. Friction is a calculated function based on the normal vector of the table, in this case (0,1,0), and the balls velocity normal. Both of these forces act to slow the ball down.

 

FORCES IN ACTION WHEN THE BALL STRIKES ANOTHER OBJECT:

When a ball collides with or penetrates another object upon frame redraw, a "collision" occurs. When this happens, the program "backtracks" in order to find when the collision happens and "resolves" it. When considering systems using force, velocity, etc., we must remember Newtons 2nd law:

F = ma

Another physical property we must keep true while simulating is Conservation of Momentum:

InitialForce = FinalForce

InitialForce(ball1) + InitialForce(ball2) = FinalForce(ball1) + FinalForce(ball2)

This is most evident when we have a two-ball collision in which the object ball (ball2) is stationary (InitialForce(ball2) = 0). In this case, the force of the cue ball will be "shared" with the object ball and each will have a new force based on the angle of their collision with respect to each other.

When the ball hits a wall (bumper), an additional friction is applied, further slowing it down, this is also based on the vector normals of the ball and surface.

 

IMPLEMENTATION:

After struggling for days and days and endless hours, I finally got my implementation working decently. As mentioned above, the one-ball model is VERY simple to implement, but once we got more balls, handling collisions became expontentially more difficult. Thus I've implemented a variety of ways and means to deal with collisions. There are a variety of collision states, and if a collision occurs, it creates a Contact. After all of the Contacts have been recognized, they are resolved through vector analysis.

 

 

Final Words: I had much loftier goals for this assignment that did not get implemented. Originally I wanted to have a clever variation of an 8-Ball game in which you could apply lots of cool forces and play around with the table orientation, etc. I basically wanted the program to have many more features than it ended up with. About 95% of the endless, infinite number of hours I spent on this went into getting the physics right, so was unable to complete the rest.