{"id":2131,"date":"2025-10-02T07:00:02","date_gmt":"2025-10-02T12:00:02","guid":{"rendered":"https:\/\/wollen.org\/blog\/?p=2131"},"modified":"2026-02-01T11:48:38","modified_gmt":"2026-02-01T17:48:38","slug":"elliptical-bank-shots","status":"publish","type":"post","link":"https:\/\/wollen.org\/blog\/2025\/10\/elliptical-bank-shots\/","title":{"rendered":"Elliptical bank shots"},"content":{"rendered":"

I think everyone knows what an ellipse is. It’s an elongated, squished circle that looks kind of like an egg. In mathematical terms it’s considered a conic section<\/a>. That means you can slice through a cone and trace an ellipse, like the image below.<\/p>\n

\"\"<\/a>
The four conic section types. Image credit: Wikipedia.<\/figcaption><\/figure>\n

Before getting into ellipses I want to touch on their conic section cousin: the parabola. Parabolas have similar properties and a familiar real-world application.<\/p>\n

These big satellite dishes (picture below) were common in the 1980s. They got smaller as technology improved and, in the 90s, shrank to the 2-foot DirecTV-style dishes we still see today.<\/p>\n

Technically they are 3-dimensional paraboloids<\/em> but the same principles apply. Parallel rays are deflected toward a single point, called the focus<\/em>. Satellite dish manufacturers mount a feedhorn<\/em> at this point. It collects the amplified signal, filters it, and converts it into an electrical signal. A wire carries that signal to your living room where a satellite receiver decodes it and draws a picture on your TV. Simple!<\/p>\n

\"\"<\/a><\/p>\n

Notice how all the photons\u2014the little bits of light that carry the signal\u2014hit the focus at the same time. No matter where they strike the parabola, they travel the same distance. A dish collects a signal out of the air like a bowl collects rainwater. Parabolic microphones operate using the same principle.<\/p>\n

\n

1. The ellipse.<\/h4>\n

That’s great but we’re here to talk about ellipses.<\/p>\n

It turns out that ellipses behave in a similar way. Rather than one focus they have two, and any particle fired from a focus will deflect off the inner wall and hit the other focus. It’s called the reflective property<\/em> of ellipses. Check out the diagram below to see what I mean.<\/p>\n

No matter what direction a particle is fired, it always ends up hitting the other focus. It’s a bank shot that goes in every time. You can imagine the orange tangent line sliding around the perimeter of the ellipse. At every position the two \u03b8 angles will be the same.<\/p>\n

\"\"<\/a><\/p>\n

And that behavior is what we’ll demonstrate in this post. We’ll fire several particles and animate them to prove that they all impact the focus.<\/p>\n

At this point there is a fork in the road. We already know what a particle’s behavior will be after it strikes the ellipse wall: it will change direction and travel toward the focus. So we could simply dictate this behavior and program every particle to move in the direction we know it’s supposed to go. But it will be a lot more interesting to model the deflection pictured above, i.e. calculate the tangent and reflect the particle over the normal line and let it go wherever it wants to go, thus proving the reflective property is real. I think it’s more fun to define basic rules of motion and see how the system behaves.<\/p>\n

It will also require more code, but that’s okay. We’ll step through a main loop to generate each frame of the animation. Particles will be instantiated from a Particle<\/code> class. This object-oriented approach will make it more difficult to talk through the code. But, as usual, you can find the complete script at the bottom of this post.<\/p>\n

\n

2. The code.<\/h4>\n

The formula for an ellipse centered at the origin looks like this:<\/p>\n

\"\"<\/a><\/p>\n

Where A<\/strong> defines the ellipse’s width along the x-axis and B<\/strong> along the y-axis.<\/p>\n

Because we’ll refer to it many times later, let’s create an Ellipse<\/code> class. It’s not a continuous function\u2014there are two y-values for every value of x\u2014so we need some logic to distinguish between “upper” and “lower.” The distance C<\/strong> from the center (0, 0) to the two foci is defined by C\u00b2 = A\u00b2 - B\u00b2<\/code>.<\/p>\n

class Ellipse:\r\n    def __init__(self, a, b):\r\n        self.A = a\r\n        self.B = b\r\n        self.x = arange(-self.A, self.A + 0.0001, 0.0001)\r\n        self.y_lower, self.y_upper = self.get_y_values()\r\n        self.focus_x_left, self.focus_x_right = self.get_focus_values()\r\n        self.focus_y_left, self.focus_y_right = 0, 0\r\n\r\n    def get_y_values(self):\r\n        y_lower = -self.B * sqrt(1 - self.x**2 \/ self.A**2)\r\n        y_upper = self.B * sqrt(1 - self.x**2 \/ self.A**2)\r\n        return y_lower, y_upper\r\n\r\n    def get_focus_values(self):\r\n        focus_x_left = -sqrt(self.A**2 - self.B**2)\r\n        focus_x_right = sqrt(self.A**2 - self.B**2)\r\n        return focus_x_left, focus_x_right\r\n\r\n\r\nellipse = Ellipse(a=5, b=3)<\/pre>\n
To model a particle’s motion we need to know its direction (slope) and speed. speed<\/code> will be the distance a particle travels during each frame of the animation.<\/p>\n
We’re going to fire several particles in different directions. Let’s package them into a list so we can easily iterate over them. For now the list will only contain one particle, but more will be appended later. This approach will allow us to fire particles one after another, rather than all at once.<\/p>\n
class Particle:\r\n    def __init__(self, initial_slope, speed):\r\n        self.x = ellipse.focus_x_left\r\n        self.y = ellipse.focus_y_left\r\n        self.movement_history = []\r\n        self.slope = initial_slope\r\n        self.collision_point = self.get_collision_point()\r\n        self.speed = speed\r\n        self.speed_x, self.speed_y = self.get_speed_components()\r\n        self.phase = 1\r\n    \r\n    [...]\r\n\r\nparticle = Particle(initial_slope=-10, speed=0.1)\r\n\r\nparticle_list = [particle]\r\n\r\n<\/pre>\n
Inside the __init__<\/code> you’ll notice a couple other methods.<\/p>\n
get_collision_point<\/code> checks where exactly the particle will collide with the ellipse wall. Calculating this value during initialization makes it much easier to do collision detection. We only have to check the particle’s distance from that exact point. When the distance is near zero, a collision has happened.<\/p>\n
To solve for this point we have to set the particle’s position equation equal to the ellipse equation and find what values of x and y satisfy the expression. This requires an obnoxious quadratic solution. I happily outsourced the work to Wolfram Alpha<\/a>.<\/p>\n
\"\"<\/a><\/p>\n
\"\"<\/a><\/p>\n
Then we plug the x value back into the y=mx+b<\/code> particle equation to solve for y. Technically this expression should include a \u00b1 symbol. But if we agree to only fire particles to the right, we can ignore it. I think that’s a fair compromise.<\/p>\n
class Particle:\r\n\r\n    [...]\r\n\r\n    def get_collision_point(self):\r\n        y_intercept = self.y - self.slope * self.x\r\n        x_val = (sqrt(ellipse.A**4 * ellipse.B**2 * self.slope**2 + ellipse.A**2 * ellipse.B**4 - ellipse.A**2 * ellipse.B**2 * y_intercept**2) - ellipse.A**2 * y_intercept * self.slope) \/ (ellipse.A**2 * self.slope**2 + ellipse.B**2)\r\n        y_val = self.slope * x_val + y_intercept\r\n        return (x_val, y_val)\r\n\r\n    [...]<\/pre>\n
The __init__<\/code> also references get_speed_components<\/code>. This method returns x- and y-components of the speed vector. They tell us exactly how the particle will move during each frame.<\/p>\n
class Particle:\r\n\r\n    [...]\r\n\r\n    def get_speed_components(self):\r\n        angle = atan2(self.collision_point[1] - self.y, self.collision_point[0] - self.x)\r\n        speed_x = self.speed * cos(angle)\r\n        speed_y = self.speed * sin(angle)\r\n        return speed_x, speed_y\r\n\r\n    [...]<\/pre>\n
Particle<\/code> objects have a movement_history<\/code> attribute which keeps track of all their past locations. We’ll use it to draw a tail on each particle\u2014sort of like the old NHL glow puck<\/a> but hopefully less hated by viewers.<\/p>\n
The phase<\/code> attribute will assist in collision detection.<\/p>\n