This could be a really cool project. Best of luck.
A few questions:
What language, IDE, and OS are you using for development? What graphics package would be used for display?
Are you prototyping this as a desktop application initially?
If this would be a desktop application, would processing be targeted to the CPU(s), or also to the GPU(s)?
Would the server or client handle the processing? (If the server handles the processing, how many simultaneous users would it support?)
Would this be an open source project?
Is there a plan to model different rail geometries (e.g. flat-faced snooker rail) and different rail stiffnesses?
The pool shot simulator for a 2-d platform is a quick exercise in object oriented programming.
Out of curiosity, do you have any favorite design patterns (e.g. from the GoF book)? Do you see a good fit for particular patterns for this project?
Once you define the ball class and its methods, the whole runtime environment is finished, it is just discrete recursions of physics equations of two-dimensions.
Would you also model masse shots, half masse shots, and jumps? Or break shots in which the cue ball can fly off the table?
Of the different papers and books on the physics of billiards, is there one you've found particularly helpful?
What I am not promising is a grand program that looks real. I do not have plans for developing the graphics of the program, which I think will turn a lot of people off.
If you develop a fully functional simulator, then I could provide some guidance and/or code for the UI. My time is already stretched pretty thin, but I could probably help you find someone to develop the GUI and design the user interaction.
Do you have experience writing APIs for UI designers to use?
The development process requires parameterization of position, velocity and acceleration. The first two are textbook calculations. The last is not needed because as the ball rolls it is under constant decceleration. The velocity changes continuously this is a problem because the distance between intervals changes over each interval. The solution is a recursive loop. Think about creating a smooth display, best guess is use many small intervals.
I'd be particularly interested to see a drag-draw shot modeled properly. If a striped cue ball were used to demonstrate a drag-draw shot, then the motion of the stripe could make it more clear to the user how the cue ball starts with backspin, then slides, then takes on natural roll.
I'd also be curious to see bank shots modeled well. If I could take my copy of
Banking with the Beard (thanks, Freddy!) and reproduce many of the shots in a simulator--varying cue ball spin & speed for each shot--that would be cool.
Creating an efficient collision detection method, the distance between two balls during collision is exactly twice the radius, a loop checking distance between all objects seems costly. Maybe a motion and distance condition will enhance the efficiency.
Perhaps I'm misunderstanding something here.
Unless all balls are moving simultaneously, why would you check for collisions with all balls rather than just
1. the ball(s) in motion, and
2. the balls within one radius distance (+ a smidgen) of the projected path(s) of the ball(s) in motion?
For example, if the cue ball is shot from one corner pocket towards an object ball hanging in the opposite corner pocket, and if no balls are located in the ball-width path, then the other balls can be ignored for collision detection. Is that what you meant?
Of course, modeling all 15 balls in the rack for the break shot would be a different matter. Although I've yet to read Joe Tucker's
Racking Secrets (but hope to soon), I'd be pleased if the simulator could reproduce Joe's work. Of course, I'd still buy Joe's DVD.
Again, best of luck with the project. Sounds fun.
