"vf = vi + at", and delta_x = v_inital * time + 0.5at^2
Dr. Dave and Bob Jewett have written accessible articles on the physics of billiards. They also post on AzB regularly and are walking, talking warehouses of useful information about the game. (As always, big thanks go out to both of them.) Dr. Dave has posted a list of useful resources about the physics of billiards:
http://billiards.colostate.edu/physics/index.html
There are several textbooks that examine the physics of billiards in detail. I have Wayland Marlow's The Physics of Pocket Billiards from 1994, which is one of the books listed on Dr. Dave's page.
In addition to the basic physics, Marlow covers collisions, table tilt, squirt, jump shots, masse, and other topics. He even has a chapter on Optimum Break Cue Weight. (I haven't checked his break cue weight calculations against the tests Bob Jewett and others conducted in the 90's and reported in Billiards Digest.) Marlow's work isn't purely theoretical; the book also includes empirical data.
If you don't already have an undergraduate degree in physics or mathematics (or at least engineering) then the math could prove daunting. No single equation in the book is hard to read, but understanding the real world meaning of each equation requires effort. Looking at the math is one thing; checking the math and reproducing it from memory is another. (If you buy the book, don't lose the Errata sheet!)
And how many other math books would give credit to "Ears" Yingling?
For a code reference, take a look at the open source project FooBillard by Florian Berger. The software demonstrates collisions, ray tracing, and rudimentary controls. That's a good start.
http://en.wikipedia.org/wiki/FooBillard
You would need to be proficient in OpenGL and C to modify the code. If you look at "ball.c", you'll notice that there are very few comments in the code, and that's unfortunate. With a good debugger, the OpenGL SuperBible (or equivalent), and a lot of patience you might still have fun with the code.
http://sourceforge.net/projects/foobillard/
Good luck.
I was disappointed when I programmed the one dimensional motion. I used the simple physics model to see how quickly the python compiler can recursively calculate and update the screen. I varied my fixed time interval from 1, 0.1, 0.01 anything smaller and the computational work exhausted the processor, I assumed acceleration was -2 and positions were based on pixels. The simulation part looked good. I will give it another shot. I slacked off a bit because of poor project planning, there are many technical issues to solve, the order to solve them challenges me. The problem in my code was the screen flickering, developing efficient code is challenging, but I will redesign it again.
Elastic collisions are easy to program. Inelastic collisions will require me to calculate the KE before impact, I still have to come up with a way to decide how much energy is transferred. [edit] The only forces involved will be the cue contact with cue ball, the position of the cue contact maps to the amount of kinetic energy transferred, stop shots are elastic, draw and follow are inelastic, based on initial position of cue striking line I can set up a ratio to determine the transfer amount.
The programming part isn't so bad. Designing the efficient code is challenging and a one man team doesn't have many opportunities for discussion on trying things differently. First I will program the type of motion that would occur in a vacuum then I will add the delicacies of gravity and friction. The great thing about programming is object oriented solutions is if you can solve the problem for two objects the solution is the same for 100001, but that's when the efficiency of the code matters.
Last edited: