Ball Bouncing Ball

Understanding the Bouncing Ball: Physics, Animation, and Code

The bouncing ball is one of the most basic exercises in animation, physics simulation, and game development. It looks simple on paper, but getting it to feel right requires dealing with gravity, energy loss, and timing. I've worked on this exact problem across several projects—2D platformers, UI animations, and rigid body simulations—and the core issues are always the same. Here is how it actually works. At the most basic level, a bouncing ball has three properties: position, velocity, and acceleration. Gravity provides constant downward acceleration. When the ball hits a surface, its velocity reverses direction and loses a portion of its energy. That portion is called the coefficient of restitution, usually between 0 and 1. A ball with a restitution of 0.7 keeps 70% of its speed on each bounce. A ball with 0.1 barely rebounds and looks like a dead weight. The formula for position updates each frame is straightforward:

velocity += gravity * deltaTime position += velocity * deltaTime

When the ball reaches the ground, you flip the velocity and multiply it by the restitution value. That's it for the bare minimum.

Implementation of Ball Bouncing Ball in Code

I'll show a JavaScript example since it runs directly in the browser with no setup. You can drop this into any canvas or DOM-based project. Start with a canvas element and a small update loop:

const canvas = document.getElementById('canvas'); const ctx = canvas.getContext('2d'); let ball = { x: 200, y: 50, radius: 20, vy: 0, gravity: 0.5, restitution: 0.7 }; const groundY = canvas.height - ball.radius; Then the frame loop:

function update() { ball.vy += ball.gravity; ball.y += ball.vy; if (ball.y >= groundY) { ball.y = groundY; ball.vy *= -ball.restitution; } requestAnimationFrame(update); } That loop runs until the ball stops moving, which in pure math never happens because floating point values get tiny but never hit exactly zero. In practice, you add a threshold:

if (Math.abs(ball.vy) < 0.1 && ball.y >= groundY - 1) { ball.vy = 0; ball.y = groundY; } Without that check, the ball will micro-bounce forever at sub-pixel heights and look broken.

I ran into a specific problem on a project where I needed a ball to bounce inside a container with angled walls. The standard ground-only check didn't work. The workaround was calculating the collision normal for each wall segment using vector dot products and reflecting the velocity vector across that normal instead of just flipping the Y component. It took about twenty minutes to implement correctly and saved me from rewriting the entire physics system later. Here's how the reflection works:

function reflect(velocity, normal) { const dot = velocity.x * normal.x + velocity.y * normal.y; return { x: velocity.x - 2 * dot * normal.x, y: velocity.y - 2 * dot * normal.y }; } Apply this whenever the ball collides with any surface that isn't perfectly horizontal. The normal vector for a flat ground pointing upward is simply {x: 0, y: -1}. For a slanted wall, you calculate it from the wall's angle using Math.sin and Math.cos.

Common Pitfalls and What Beginners Miss

The biggest mistake people make is treating the bounce as an instantaneous event. It isn't. Even in simple 2D, the ball compresses slightly on impact, then expands. In animation, this is handled with squash and stretch. In physics engines, it's handled by continuous collision detection, which most hobbyist implementations skip. The result is tunneling: the ball moves so fast between frames that it passes through the ground entirely and never triggers a bounce. To prevent this, you either reduce the timestep or add a sweep test that checks the entire path the ball travels during one frame. Another thing people don't expect is that restitution alone doesn't control how high a ball bounces in a visually pleasing way. A high restitution makes the ball bounce high but also creates a lot of small bounces that look jittery. The trick is combining restitution with air resistance. Adding a simple drag factor like multiplying velocity by 0.99 every frame smooths out those micro-bounces and gives the ball a more natural settling behavior.

I had a case where a bouncing ball animation looked fine at 60fps but completely broke at 30fps. The issue was that the gravity value was hardcoded per frame instead of scaled to the actual frame duration. The fix was multiplying gravity and velocity changes by deltaTime calculated from the actual frame time. Once that was in place, the animation ran identically across refresh rates.

Using Existing Libraries

If you're building something more complex than a single bouncing ball, writing your own physics is usually a waste of time. Libraries like Matter.js or Box2D handle collisions, restitution, friction, and angular momentum out of the box. Matter.js is free, runs in the browser, and has a gentle learning curve. Box2D is more powerful but has a steeper entry point and requires more setup. The tradeoff with libraries is that they add overhead and sometimes behave differently than your custom implementation. A full physics engine will also simulate rotation, which a simple demo might not need. For a bouncing ball animation in a presentation or a lightweight game, the custom approach is faster and gives you more direct control. For anything involving multiple objects colliding, the library route saves hours.

Animation Techniques for Realistic Bouncing

In traditional animation, a bouncing ball is the first exercise because it teaches timing, spacing, and anticipation. The ball should squash on impact and stretch during the fall and rise phases. The squash is a brief frame or two where the ball compresses vertically and expands horizontally. The stretch elongates the ball in the direction of movement. Between bounces, the spacing gets tighter near the peak and wider near the ground, reflecting gravity's constant acceleration. Many beginners make the ball too round at the top of its arc. It should actually look slightly compressed there because gravity is slowing it down. The stretch only happens during the fastest parts of the movement—the fall and the initial rebound. Getting this spacing right matters more than any formula when the goal is visual appeal rather than physical accuracy.

If you're building this for a game or an interactive project, the pure physics approach is usually sufficient. If you're animating for video or a cinematic sequence, keyframing the squash and stretch manually or using a dedicated animation tool gives you far more control than a physics simulation will.

Practical Tips for Your Own Ball Bouncing Ball Project

Start with a single axis. Get the vertical bounce working correctly before adding horizontal movement or rotation. Horizontal movement introduces friction, which complicates the restitution calculation and can make the ball roll instead of bounce if not handled properly. A rolling ball uses a different model entirely and requires angular velocity and rotational inertia. Use a fixed timestep for your physics if possible. Variable timesteps cause inconsistent behavior across machines with different refresh rates. The standard approach is to separate the rendering loop from the physics loop, running physics at a fixed interval and interpolating the visual position between steps. This is how engines like Unity and Godot handle it by default. Rolling your own fixed timestep is not hard and prevents a class of bugs that are very difficult to track down later.

For a quick working example you can run today, the custom JavaScript approach above is all you need. Save it as an HTML file, open it in a browser, and adjust the gravity, restitution, and initial velocity values until the bounce feels right for your use case. Typical values for a rubber ball are gravity around 0.3 to 0.8 and restitution around 0.6 to 0.85. A steel ball bearing would have higher restitution and less air drag. A wet sponge would have restitution near zero and barely bounce at all. The bouncing ball is deceptively simple. The basic version takes about fifteen minutes to code. The version that handles angled surfaces, varying frame rates, and realistic visual behavior takes considerably longer. Knowing where to draw the line between a quick demo and a full implementation is the actual skill here.