Missed collision detection during the simulation

[parazjx]

Thanks for all the great works! The project has been a great help in verifying my theories about playing pool on daily play.

But sometimes I found the ball went through with other ball in EightBall game when i put cue ball in 1/4 place and others in 3/4 place.

First change position In pooltool/layouts.py:

def _get_eight_ball_rack:
...
blueprint = ball_cluster_blueprint(
seed=BallPos([], (0.5, 0.75), solids),
...
cue = BallPos([], (0.5, 0.25), {"cue"})

Then with the test code follow:

shot = pt.System(
    cue=pt.Cue(cue_ball_id="cue"),
    table=(table := pt.Table.default()),
    balls=pt.get_rack(
        pt.GameType.EIGHTBALL, table
    ),
)
shot.strike(V0=3.262213, phi=81.83468, theta=0, a= 0, b=0)
pt.simulate(shot, inplace=True)   
pt.show(shot)

The magic number of V0 and phi are just copied when i shot by hand.
I am not sure which step caused the problem, wether the time calculation error when solving the equation or the omission when querying the transition event.

Thanks again for all great works!

[derek-mcblane]

@ekiefl, my understanding is that the balls are placed in the rack with some spacing and random positioning.

More as a note to myself: I'm curious exactly what would happen if the balls were placed touching. I suspect there might be an adjustment to the collision prediction that could fix issues arising in that case.

[binaryni]

I found that sometimes two balls were initialized with some tiny overlap. In this case, they can go through each other.

[ekiefl]

@binaryni, I just added tests to make sure this never happens (#203). In general, if you use get_rack, which the GUI uses by default, the balls should never initialize with any overlap. An exception to this, which was discovered in writing these tests, was the pink ball overlapping with the first red in snooker. I've since fixed that.

If balls do end up overlapping, which can occur due to missed collisions, then they go through each other. Still working on fixing missing collisions, but it's not due to initially overlapping balls...

[ekiefl]

Happy to report this should now be solved (#257)

Here is an 8-ball break with zero space between balls:

Priorly, this would have caused several intersections.

Note: micrometer-level intersection is still possible, but also extremely rare. We owe both the possibility and the rarity of intersection to the somewhat complicated behavior of the ball-ball make_kiss function, which runs after evolving balls to the time of collision and before the collision is resolved. However, in the case of such intersections the involved balls are guaranteed to undergo a ball-ball collision at a time t=0 later, which enforces distances between them.

Closing this for now, but please reopen if any problems persist.