Missing cushion collision

[LeXXik]

Under some conditions, e.g. in a billiards game, no pockets, when you hit a corner, the ball will go outside of table bounds.

Make a square table, place the ball somewhere at the diagonal and shoot at 45 degrees:

cue = pt.Cue(cue_ball_id="cue")
cue.set_state(2.0, 45, 0, 0, 0)

table_specs = pt.objects.BilliardTableSpecs(l=4.5, w=4.5)
table = pt.Table.from_table_specs(table_specs)

cue_ball = pt.Ball.create("cue", xy=(1, 1))
obj_ball = pt.Ball.create("obj", xy=(10.0, 10.0)) # have to create an object ball as it seems I can't have only a cue ball? :/

system = pt.System(table=table, balls=(cue_ball, obj_ball), cue=cue)

When it hits the corner, there will be 2 cushions at very close time delta to each other and only one cushion gets processed.

Also, probably related, if you place the cue ball right next to the cushion (table width/length minus ball radius) and shoot towards the cushion, the ball will also go outside of the table bounds.

[LeXXik]

In my engine (non python) I am also using the Leckie/Greenspan method for ball evolution. Had the same issue with the corner hit.

The issue was that after you evolve the ball, its position may penetrate the line by a fraction due to a floating point precision error. I solved it by using a de-penetrated ball position when we solve the boundary collision time, instead of using its raw position:

pooltool/pooltool/evolution/event_based/solve.py

Line 228 in d620448

cx, cy = rvw[0, 0], rvw[0, 1]

Not sure about the problem when you place the ball next to a cushion, as my engine doesn't have that issue. The event time should be very small in that case, so I would start from looking if that delta time passes a test for a valid event.

[ekiefl]

Hey @LeXXik thanks for this report. In pooltool there is a silly named routine called make_kiss, which moves the ball along the cushion normal to ensure a separation of R + a small epsilon. It

pooltool/pooltool/physics/resolve/ball_cushion/core.py

Lines 54 to 81 in d620448

	def make_kiss(self, ball: Ball, cushion: LinearCushionSegment) -> Ball:
	"""Translate the ball so it (almost) touches the linear cushion segment
	This makes a correction such that if the ball is not a distance R from the
	cushion, the ball is moved along the normal such that it is. To avoid downstream
	float precision round-off error, a small epsilon of additional distance
	(constants.EPS_SPACE) is put between them, ensuring the cushion and ball are
	separated post-resolution.
	"""
	normal = cushion.get_normal(ball.state.rvw)
	# orient the normal so it points away from playing surface
	normal = normal if np.dot(normal, ball.state.rvw[1]) > 0 else -normal
	# Calculate the point on cushion line where contact should be made, then set the
	# z-component to match the ball's height
	c = ptmath.point_on_line_closest_to_point(
	cushion.p1, cushion.p2, ball.state.rvw[0]
	)
	c[2] = ball.state.rvw[0, 2]
	# Move the ball to exactly meet the cushion
	correction = (
	ball.params.R - ptmath.norm3d(ball.state.rvw[0] - c) + const.EPS_SPACE
	)
	ball.state.rvw[0] -= correction * normal
	return ball

This

• moves along the cushion normal
• keeps the raw time

Taking your suggestion in mind, I think it would probably be better to

• move along the ball's trajectory
• potentially update the time

[LeXXik]

Ah, ok, sorry, I'm not very familiar with your API :) Glad you considered it, feel free to close.

[ekiefl]

I'll keep it open, because the issue is about a missing collision (I was able to replicate btw, thanks for the MRE).

I would appreciate any feedback you might have on my proposed solution, perhaps how it compares to your project?

[LeXXik]

Ah, ok. Right, so, I don't actually change the raw position of the ball. Only the values that go into quadratic equation. This way you can keep the time as is and the solution would be stable.

Also, not sure if I should create another issue, but I noticed you solve against all balls and line/circle cushions that are present on the table. You can actually improve it. If you use the ball velocity, you can know if you are moving away from the ball or line segment. Then you can skip it altogether. Doing a dot check for plus/minus sign is much cheaper, than a quartic/quadratic solve. This way you can filter half of the table objects out most of the time.

Edit:
About the case, where the ball is placed right at the cushion and misses the collision - not sure yet. I will take a look at my implementation and see if there is anything obvious I could spot.

[ekiefl]

I don't actually change the raw position of the ball. Only the values that go into quadratic equation

The quadratic you refer to is the ball's equation of motion (not the quadratic whose real positive root is the time until collision), right?

I really appreciate the time you've already spent, but could you please better define what "raw position" means versus what "goes into the quadratic"? Even more useful would be if you took some time to define your approach more algorithmically.

Also, not sure if I should create another issue, but I noticed you solve against all balls and line/circle cushions that are present on the table. You can actually improve it. If you use the ball velocity, you can know if you are moving away from the ball or line segment. Then you can skip it altogether. Doing a dot check for plus/minus sign is much cheaper, than a quartic/quadratic solve. This way you can filter half of the table objects out most of the time.

The reason is massé shots. Initial velocity is not an indication of trajectory shape. It's possible for the ball to reverse direction into a rail while maintaining a parabolic (sliding) trajectory throughout.

https://youtube.com/shorts/V5-77Gnl4x8?si=to5d3T9LSn6wzC_Q

That said, only the cue stick's influence on the ball can realistically impart the amount of spin required, so this dot product check can likely be applied to all balls except the cued ball.

Thanks for the idea! Let me know if you concur.

[LeXXik]

Sorry, I was not clear about it. There isn't really much to the algorithm here and it is similar to your kiss function. What I do is that here:

pooltool/pooltool/evolution/event_based/solve.py

Line 228 in d620448

cx, cy = rvw[0, 0], rvw[0, 1]

Instead of

cx, cy = rvw[0, 0], rvw[0, 1]

I do something like

cx, cy = depenetrate(rvw[0, 0], rvw[0, 1], cushion)

Where depenetrate function simply returns the same rvw[0], if the cushion is far, or an adjusted position (simply moved by epsilon along the cushion normal).

What does it mean in terms of simulation? Let's take an example with the corner ball. Say, the ideal position for the center of a ball to be (2.0, 2.0), where it is touching both cushions in the bottom right corner. We just now evolved the ball somewhere in the middle of the table and it transitioned from sliding to rolling state, moving towards the corner position. Remember, we are dealing with event based approach, which means only one thing can happen at any time and the earliest event takes precedence. So, we start off with solving time for all the cushions. We first solve, e.g. bottom cushion and find the time. Then we solve for the side cushion and find the time as well. One of them will be smaller by a fraction, let's say side cushion happened to be the first one. We discard the other event and evolve the ball by the time to hit the side cushion. After evolution the position may end up be at (2.0, 2.0000000002).

We start again, solving time for all the cushions. Since the ball collided with the side cushion, its velocity will be now pointing away from it, so no time (no collision) for the side one. We then solve for the bottom cushion. However, because we are starting from 2.0000000002, we are actually starting behind the cushion (outside play area), and moving away from it. As a result, no time for the bottom cushion, so no collision. To fix it, we use the depenetrated position and find that the next collision event will be after, I don't know, 5 nanoseconds. Note, we only use the adjusted position for solving for time, we don't actually change rvw[0].

The other balls would still use rvw[0] of the corner ball to solve their time for collision. Meaning, they will still see it at (2.0, 2.0000000002). Once the loop is over, we sort the events by time and find that the next event will be after 5 nanoseconds. We grab it, and discard all other events, no matter what the other balls thought about colliding with the corner ball. We then evolve all balls by 5 nanoseconds and update their positions, including the corner ball, and solve for collision time again. This time, though, the corner ball will be at the correct position (2.0, 2.0), as if 2.0000000002 position never happened.

This may happen with events that happen at "the same time", like hitting a corner, or hitting a ball and a cushion, or when balls are touching each other in the rack, etc. After the evolution, their position may be penetrating the obstacle.

The reason is massé shots. Initial velocity is not an indication of trajectory shape.

That should not be an issue. The filtering should apply for the cue ball as well. We only use the velocity to get the direction the ball is facing. All objects in front of it would be candidates for collision, all objects behind can be ignored. In your example, the cushion the cue ball hits on the side is still infront of it, so no skipping. We can do it, because no event can reverse the direction of the ball's motion within the event itself. No matter what spin is applied. For example, hitting a heavy draw shot with almost vertical cue stick, will send the ball forward towards the middle of the table, then it will turn back and return to you. This is still fine, becuase you do the filtering per each event. After striking the ball, it transitions to sliding state, moving away from you. We solve for collision time, and velocity direction will tell us that we are moving away from the cushion, so we can skip it. Then the ball changes the state from sliding to rolling, that is when it starts coming back to you. The velocity will change, though, now facing towards the cushion and the filtering will not skip it, so we can solve for the collision time.

[ekiefl]

Thanks for taking the time to explain. I now see your general approach, which occurs upstream of event detection in order to protect against object intersections. This is different from the make_kiss method which is applied after detection and prior to resolution. I'll definitely consider implementing this, or perhaps modifying make_kiss. Thanks to your explanation, I can see the failure mode for make_kiss, which currently translates the ball normal to the cushion. However, this displacement occurs perpendicularly to the second cushion's normal, so it remains intersected, and hence not detected.

---

That should not be an issue. The filtering should apply for the cue ball as well. We only use the velocity to get the direction the ball is facing. All objects in front of it would be candidates for collision, all objects behind can be ignored. In your example, the cushion the cue ball hits on the side is still infront of it, so no skipping. We can do it, because no event can reverse the direction of the ball's motion within the event itself. No matter what spin is applied. For example, hitting a heavy draw shot with almost vertical cue stick, will send the ball forward towards the middle of the table, then it will turn back and return to you. This is still fine, becuase you do the filtering per each event. After striking the ball, it transitions to sliding state, moving away from you. We solve for collision time, and velocity direction will tell us that we are moving away from the cushion, so we can skip it. Then the ball changes the state from sliding to rolling, that is when it starts coming back to you. The velocity will change, though, now facing towards the cushion and the filtering will not skip it, so we can solve for the collision time.

I've bolded what isn't true in general. Between these two cushion hits, the ball is only sliding.

(please ignore the fact that the 8-ball is technically contacted before the second cushion).

That's why I said:

It's possible for the ball to reverse direction into a rail while maintaining a parabolic (sliding) trajectory throughout.

That's also why this shortcut hasn't been implemented. However, to reiterate, I think it's suitable to implement for all non-cued balls.

[LeXXik]

Between these two cushion hits, the ball is only sliding.

Yes, I understand your meaning. Well, at least I think I understand. English is hard ;)

When I say reverse direction, I mean going in opposite direction from what we started with. You cannot do it within a single event. We use the velocity of the ball to find the front side of the ball. This gives us a line of demarcation that divides the world into 2 halves - the front and the back, which we then use to find whether the cushion/ball/pocket is in front of us or behind.

In your example, that short cushion is still going to be tested, because one of its points will be in front. In fact, pretty much everything will be used in your example, except one corner pocket (and its jaws, if you use those):

In order for us to skip that short rail, the demarcation line needs to be almost parallel to it. In order for it to be parallel, we have to hit the ball almost perpendicularly to it, and there is no way to get back to the cushion in that case just by sliding, without a roll or touching some ball/cushion first.

[ekiefl]

English is hard ;)

No worries.

When I say reverse direction, I mean going in opposite direction from what we started with. You cannot do it within a single event.

Reversal does not necessitate an event transition from sliding to rolling. Mathematically, the transition occurs when the relative velocity between ball and cloth, $\vec{u}(t)=0$. This condition is unrelated to when the point of reversal occurs. Equipped with this fact, it might be helpful for you to revisit your own example and to point out where you have assumed otherwise:

For example, hitting a heavy draw shot with almost vertical cue stick, will send the ball forward towards the middle of the table, then it will turn back and return to you. (...) After striking the ball, it transitions to sliding state, moving away from you. We solve for collision time, and velocity direction will tell us that we are moving away from the cushion, so we can skip it. Then the ball changes the state from sliding to rolling, that is when it starts coming back to you. The velocity will change, though, now facing towards the cushion and the filtering will not skip it, so we can solve for the collision time.

If we assume the ball transitions at the time of reversal, $t_{rev}$, as you seem to be suggesting, then we know that by definition $\vec{u}(t_{rev})=0$ (definition of sliding is $\vec{u} \neq 0$) and $\vec{v}(t_{rev})=0$ (the velocity must pass through zero in order to reverse). Since $\vec{v}(t_{rev})=0$, the only way to satisfy $\vec{u}(t_{rev})=0$, given its definition, is if the angular momentum is also 0: $\vec{\omega}(t_{rev})=0$. With no velocity or angular velocity, the ball has no motion, meaning that the only way for the ball to transition out of the sliding state at the apex is if it comes to a dead stop. This represents a special case: any less spin and no reversal occurs and any more spin and a reversal does occur. This proves that any backwards motion is due to the transition occurring after the reversal. The amount of time between reversal and transition will depend on the amount of spin, and with enough spin, the transition could occur after the ball contacts the cushion.

https://ekiefl.github.io/2020/04/24/pooltool-theory/#case-3-rolling
https://ekiefl.github.io/2020/04/24/pooltool-theory/#case-4-sliding

[LeXXik]

Thank you for the explanation! I will see if I need to revise my logic regarding the tests related to the cue ball. At least, the other balls should be fine, as you mentioned.

[LeXXik]

After looking at it in more detail, I agree with you. You are right, this can actually happen. I am an avid pool player in real life, and simply considered it as a no-way-possible-to-execute shot :) This lands straight into a trick-shot land. In a normal match, you'd rarely jack up a cue stick like that. You'd have more chances winning a match by a simpler safety shot. Still, from the math point of view, it holds and gamers do show stunts we rarely expect in real life. It was educational, thank you.

[LeXXik]

Curious if there is another way to check for cue ball potential on hitting the objects in the back. Like maybe cue elevation, or perhaps its spin to velocity rate...

Also, checked your Mathavan solver implementation, it looks like this work completed calculation is superfluous and can be removed?

pooltool/pooltool/physics/resolve/ball_cushion/mathavan_2010/model.py

Lines 428 to 438 in d620448

	# Calculate actual work done
	actual_work = calculate_work_done(refine_vy, cos_theta, refine_delta_p)
	refine_WzI += actual_work
	return (
	refine_vx,
	refine_vy,
	refine_omega_x,
	refine_omega_y,
	refine_omega_z,
	)