While developing libraries there are many ideas that dawn on me that are normally accompanied by the phrase “How hard could it be to….”. This is the result of one of those thoughts.
While developing ground contact models for our VeSyMA – Motorsports, 1D and 2D tests were created as both “sanity checks” and isolated theory tests. In most cases this normally results in checking variables on graphs, but in this case it made more sense to look at visualisations of the components to sanity check them. You can see if something is wrong pretty quickly if you visualise it; it may highlight a variable you may not otherwise have looked at that’s doing something unexpected.
During this development I considered how difficult it would be to create a game of pool/snooker with this; I mean, how hard could it be?…….
The theory of the contact models were lifted from the Motorsports library; the cloth friction models were modified models taken from the Claytex Library.
After a little time developing and adapting the contact models, which didn’t go to the length of incorporating vertical freedom or spin, I then developed a model instance representing and containing the physics of each ball. Each model knew where the other balls and cushions were and the contact stiffness with each of them. All the ball models were exactly the same and had the correct weight and size of regulation balls. The only difference was the colour and that there was a short pulse point force applied to the cue ball in along an axis at the start of the simulation.
After a little more time taken making it look vaguely like a pool table I had a basic 2D implementation of a pool table, with cushions, a full rack of pool balls and pockets.
While this was a good place to start, having a single shot pool table is a little limited. To play a proper game of pool the balls needed to remain where they were ready for the next shot. If we assume that we are taking each shot as a separate simulation then for each simulation we would need to know the position of the balls at the end of the previous shot.
I created an interactive function where you define the experiment containing the table and balls and their initial positions. You then give the impact axis and impact force and shot number. This then simulates the next shot and then outputs a new version of the pool table with the final resting places of the balls for the next shot. Below is the function interface:
This allows a continuous game to be played. I am not a good player myself on a real table but after a while I was able to at least pot a ball after a couple of tries (with no cheating, I promise….). Below is a cut together video of the first 3 shots. The pool cue doesn’t come into contact with any of the balls but only serves as a visualisation of the hit axis.
More often than not these sorts of developments/investigations have brought me either a new way of thinking or a more robust/efficient way of creating model and this time was no different; I found that I needed to re-consider the use of events in simulations. They can be beneficial and if incorporated into simulations and taken advantage of then they can speed up your simulations and improve robustness. So rather than always avoid them for simulation efficiency, it can be more efficient to use them in choice locations and sparingly to create accurate and robust simulations.
Going forward this type of testing also lends some structure to the VeSyMA library in developing durability studies. While the durability of a pool ball is not an area crying out for investigation, vehicle durability is. This methodology is directly transferable, taking the final position/wear level/temperature of components and then transfer them to the next test automatically.
With a little preparation, vehicle testing (pool table and balls) can be done fluidly and at the end of a full durability study (round of pool) the quality of the components can be determined with no time lost in transferring initial conditions.
So who wants a game?
Written by: David Briant – Project Engineer