In the Anatomy of Bounce Juggling, we discussed four different bounce juggling techniques, namely, Hyperforce, Force, Lift and Hyperlift. From Figure 1 (reproduced from the above blog), which assumes default Juggling Lab (JL) simulator settings (see Table 2), we can see that for a given flight time, it is possible for multiple solutions to exist in terms of the technique used for that bounce throw. Conversely, it could also be impossible to use a particular bounce technique to achieve a particular flight time.

In this blog, we delve deeper into how JL navigates this maze of choices and constraints, and what it does when the user inputs are such that a solution satisfying all the input parameters is impossible. We will restrict ourselves to single bounce throws and not consider multiple bounces here. Further, we will mostly use the 3B pattern as an example, though the results should apply in general to other single bounce patterns as well.

Juggling Lab Notation and Defaults

JL uses “B” as a modifier after the siteswap number to indicate a bounce throw. Additional modifiers specify the bounce technique to be used as summarized in Table 1.

Modifier after siteswap number	Juggling Lab Interpretation
B, BL	Lift Bounce
BF	Force Bounce
BHL	Hyperlift Bounce
BHF	Hyperforce Bounce
BBB… n times	n bounces between throw and catch

Some of the other parameters that are important for a bounce juggling simulation are listed in Table 2.

Parameter	Our notation	Default value in Juggling Lab
Hand height from which ball is thrown	HT	100cm above ground
Hand height at which ball is caught	HC	100cm above ground
[Acceleration due to] gravity	g	980cm/s2
Bounce Fraction	r	0.9
Beats per second	bps	Determined based on the Pattern input
Dwell beats		1.3 beats

The parameter “Bounce Fraction” may need some explanation. Suppose a ball is dropped (released with zero vertical speed) from a height H above the ground. Let us further suppose that after bouncing on the ground, the ball achieves a maximum height h before starting to fall towards the ground again. Then the Bounce Fraction r = h/H¹. In the real world we will always have r < 1.

Figure 2 shows the JL results for the 3-ball bounce cascade with the Pattern input set to 3B, 3BF, 3BHL, 3BHF and 3BBF. In the pattern 3BBF, the two B’s indicate two bounces between throw and catch and the F indicates the Force bounce technique. Other than the Pattern input, all other JL settings were left as default to generate these animations².

All the simulation outputs are as per the user input. Compare the throw rate (number of throws per second, another name for bps) of the single bounce patterns carefully. One should be able to make out that the bps is the highest for the Hyperforce pattern and the lowest for the Hyperlift pattern.

Modifying the Default Values

The JL pattern entry panel provides options for modifying each of the default values listed in Table 2. Details can be found in the Juggling Lab documentation, but we briefly summarize them below.

Hand Heights

The hand heights can be modified by setting the Hand movement field to “custom” and then entering the user defined values for the hand positions at the time of each throw and catch. The default value of 0cm for the z-coordinate of the hand position for both throwing and catching corresponds to a height of 100cm from the ground. If a value a is given for the z-coordinate, then the hands will be (100 + a) cm above the ground where a could be positive or negative. It is possible to specify a different hand height for the throw than that for the catch.

Gravity and Bounce Fraction

These parameters can be modified by using the Manual settings field of the pattern entry panel using semicolon separated key value pairs. For example, to simulate the gravity effects on the Moon where g is about 1/6 of its value on Earth, and simultaneously use r = 0.5, we can write gravity = 163.3; bouncefrac = 0.5 in the Manual settings field. It is also possible to use the Manual settings field to enter the hand positions instead of using the Hand movement field.

We said earlier that in the real world, r < 1. But what fun would a simulator be if all it could do was simulate the real world? JL allows one to enter values r ≥ 1 AND also set negative values of g! But we will stick to real world scenarios in this blog.

Beats per second and Dwell beats

JL internally determines the throw rate or bps to be used based on the input pattern if no bps has been explicitly specified by the user. For the purposes of this discussion, it suffices to know that the default bps it uses for a 3-ball cascade is 2.9 and for a 5-ball cascade is 4.1. The siteswap number, flight time, dwell time are all related to each other and bps helps us express these quantities in seconds instead of in beats.

Siteswap number = flight time in beats + dwell time in beats

Time in seconds for 1 beat = 1/bps

The user has the liberty to explicitly specify the bps and the Dwell beats in JL. Along with the Pattern input which provides the siteswap number for each throw, this information is sufficient to determine the flight time for each throw. For the purposes of this blog, we will always use the default Dwell beats setting of 1.3 beats.

Making Sense of Bounce Solutions

Let us now study some examples to understand how JL solves the bounce juggling problem under various conditions. Note that if H_C ≤ rH_T, a ball dropped with zero vertical speed will still be able to bounce back up to or above the catching hand height. But for H_C > rH_T, the juggler must throw the ball with some minimum vertical speed for it to bounce back up to the catching hand height. We therefore, choose to categorize our examples based on this relation between the throwing and catching hand heights.

Case 1: Default Settings (H_C > rH_T, Default bps)

We have already seen in Figure 2, that JL is able to output an animation for 3BL , 3BF, 3BHL and 3BHF patterns without the user providing any of the other parameters, including the bps. Why does the JL animation show a different bps for each of these patterns?

For a 3-ball cascade, with Dwell beats = 1.3 beats, the Flight time in beats = Siteswap number – Dwell beats = 3 – 1.3 = 1.7 beats. As mentioned above, for a 3-ball cascade JL defaults to bps = 2.9. So 1.7 beats of flight time translates to a duration of 1.7/2.9 = 0.586 seconds. From Figure 3 (which is an annotated reproduction of Figure 1), we can see that only the Hyperforce solution is possible with this flight time. We need more flight time for any of the other three techniques to be possible. This is precisely what JL does: it determines that the default bps won’t work for the 3BL, 3BF and 3BHL cases and finds a bps, or equivalently, a flight time, at which these patterns becomes possible.

Figure 3 shows the flight times determined by JL in each of the single bounce cases of Figure 2. This correlates well with Figure 2 where we see that the bps (which is inversely proportional to the flight times) for the patterns in descending order is 3BHF > 3BF > 3BL > 3BHL.

The Second Lift Solution

A closer look at Figure 3 reveals that at the flight time determined for the 3BL pattern, two solutions exist for the vertical throw speed the juggler can use. Figure 4 shows a zoomed in view of this region of the graph. As has been noted in the Anatomy of Bounce Juggling, this situation arises because the Lift bounce curve with the default settings is non-monotonic.

In such situations, JL usually seems to show the solution with the higher vertical throw in the animation. In Figure 5, we show this solution on the left (same as the 3BL animation in Figure 2 above) and the solution with the lower vertical throw speed on the right³.

Try and observe the same coloured ball in the two patterns of Figure 5. We should be able to make out that in the pattern on the left, the ball rises higher and hits the ground later than the same coloured ball on the right. But in both cases, the balls are caught and thrown at the same time, i.e., the flight time and dwell time (and therefore, the bps) is identical, keeping the two patterns always in sync.

The Second (and Third!) Force Solution

Interestingly, when H_C is only “very slightly” greater than rH_T, the Force bounce solution curve also acquires a non-monotonic character. We illustrate this in Figure 6 with the choice H_C = 100cm, H_T = 124.99cm and r = 0.8 such that rH_T = 99.992cm, only slightly less than H_C.

This case is even more interesting because the Force solution curve starts off with a positive slope (flight time increasing with the vertical throw speed), then has a negative slope for a while (flight time reduces with increasing vertical throw speed) and then finally goes back to having a positive slope. This behaviour of the curve creates a situation where the same Force bounce pattern with the same flight time can be achieved using three different vertical throw speeds. Figure 7 shows an even further zoomed in section of the force bounce curve of Figure 6 to illustrate this point.

The throw speeds, though different, are very small in each of the three cases to cause any noticeable difference in the animations, so we have not presented the corresponding animations here. We will later consider another case showing the same flight time with two different vertical throw speeds for Force bounce where the difference is more obvious. For the record, JL seems to prefer the solution with the highest throw speed in this case as well.

Case 2: H_C = rH_T, Default bps

In Figure 8, we set H_T = 100cm, H_C = 90cm and r = 0.9 so that if the ball is dropped with zero vertical speed from a height H_T = 100cm, it will exactly return to the catching hand at a height H_C = 90cm and with zero vertical speed. Thus, both the throw and the catch can be interpreted as either lift or force. Hence, all four juggling techniques converge to the same flight time number for zero vertical throw speed.

In the blow up on the right of Figure 8, we note that the Lift bounce curve has now become monotonic, but the curve for the Force solution continues to be non-monotonic for this case also. However, the nature of its non-monotonicity has changed to be like that of the Lift solution in Case 1: we can get two, but not three, Force solutions for the same flight time (within a certain range of flight times). Again, JL seems to consistently pick the higher vertical throw speed solution in such situations.

Case 3: H_C < rH_T, Default bps

We illustrate this situation in Figure 9 for which we have chosen H_T = 122cm, H_C = 100cm and r = 0.9. As in Case 2, each of the four bounce techniques is still possible with zero vertical throw speed. However, the flight times for all four techniques are not equal at zero vertical throw speed. Also unlike in Case 1, we now have the Hyperforce and Lift curves having a common solution at one point and similarly, the Force and Hyperlift curves having a common solution at one point.

The curve for the Force solution continues to be non-monotonic for Case 3 as well and JL continues to show the solution with the higher vertical throw speed for situations where two Force solutions are possible.

Case 4: User Specified bps

So far we have considered scenarios where the user did not specify a bps. JL was then free to modify it as per the requirements of the input pattern. But what if the user specifies a bps which results in a flight time at which it is impossible to juggle the input pattern?

For example, let us consider what happens if the user explicitly enters bps = 2.9, retaining the default Dwell beats (= 1.3) and hand heights settings and gives the input pattern as 3BL? As already seen, these settings lead to a flight time of 0.586s for which only a Hyperforce solution is possible. As shown in Figure 10, in such situations JL respects the bps input and outputs the 3BHF pattern even though the user had asked for the 3BL pattern.

Two Force Bounce Solutions

Let us now create a situation where two force bounce solutions are possible with the same flight time for the 3BF pattern. First, in Figure 11, we zoom in to the force bounce curve of Figure 9 and identify a suitable flight time which will need a significant difference in the two possible vertical throw speeds.

We find that if we can set a flight time of about 1.09s then there will be two solutions which will require vertical throw speeds of ~0.27m/s and ~2.07m/s. For a 3-ball cascade pattern with 1.3 beats of dwell time, this means that 3 – 1.3 = 1.7 beats of flight time should be equivalent to 1.09s. So the bps = 1.7/1.09 = 1.56. Also, we set the hand positions compatible with Figure 9, i.e., H_T = 122cm and the H_C = 100cm. Figure 12 shows the two possible solutions in this case. On the left is JL’s intrinsic solution and on the right is the other solution that we forced JL to show by hacking a local copy of its code.

One can see that on the panels on the left and right, the same coloured ball is caught and thrown almost simultaneously. However, in the panel on the left, the ball reaches the ground much earlier and bounces up much higher than in the panel on the right. This is as expected because the vertical throw speed imparted to the ball in the left panel is higher.

A Bug?

During the course of writing this blog, we discovered a potential bug in the JL code. As has been mentioned above, when no bps is specified, JL figures out a suitable bps for the bounce technique requested by the user and shows the pattern accordingly. However, when we entered Hyperforce patterns for 5 balls and more (e.g., 5BHF, 6BHF, 7BHF, etc.) in JL, without specifying a throw rate, it ended up juggling the corresponding Force patterns instead of the Hyperforce patterns. Why did it do that?

In the flight time vs. vertical throw speed curves for all the cases we have studied here, we see that for the Lift, Hyperlift and Force techniques, the flight time, eventually if not always, increases with the vertical throw speed. But there is a certain minimum flight time below which these patterns cannot be juggled. So if the given input conditions are such that the L, F or HL techniques cannot be juggled, JL iteratively keeps increasing the flight time till it reaches a point where a solution becomes possible. In contrast, for the Hyperforce technique, there is a limit on the maximum flight time possible. So if the given input conditions are such that the HF technique cannot be juggled, it means that the flight time is too high and needs to be reduced. For example, for a 5-ball cascade, with 1.3 beats of dwell time, the flight time is 5 – 1.3 = 3.7 beats. As mentioned earlier, JL uses a default bps = 4.1 for a 5-ball cascade. So the 3.7 beats of flight time translates to 3.7/4.1 = 0.9 seconds. As we can see from Figure 1 or Figure 3, this flight time is suited for a Force solution but is too high for a Hyperforce solution and needs to be reduced. The problem in the present JL code is that there is no intrinsic mechanism to reduce the flight time in such cases. Hence, it does the next best thing, which is to juggle a Force pattern instead. Interested readers can keep track of this issue on the Juggling Lab Github page.

Footnotes

1. This is related to a quantity called the restitution coefficient (e) by the equation r = e². ↩︎
2. We did set “colors = mixed” in the Manual settings field so that the balls each have different colours, making it easier to track the flight of every individual ball. ↩︎
3. JL does finds both the lift solutions, but animates only one of them. A local copy of the JL code (v1.6.5 in Java) was hacked to force it to animate the other lift solution which is shown in Figure 5. As of this writing, JL v1.6.7 in Kotlin has been released, but the JL behaviour in this context remains the same. ↩︎