Anyone who has ever flown through the air on two wheels can appreciate this: a rider staring at a jump and its gap, trying to picture the arc. How fast do I need to go? Will I clear it? Will the landing feel smooth or like a punch to the spine? The mental math is unreliable, the necessary intuition only gained with loads of experience, and the consequences of getting it wrong range from cuts and bruises to an ER visit and a stint on injured reserve.
We built the Jump Simulator to replace that guesswork with real physics. It's a free, browser-based tool that lets BMX, MTB, and MX riders design gap jumps, simulate trajectories, and see exactly where (and how hard!) they'll land before moving a single shovel of dirt.
The Problem with Gap Jump Design
Gap jumps are deceptively simple: a takeoff ramp, empty air, and a landing ramp. Three elements. But each one hides a web of variables. The takeoff angle determines how much speed converts to height versus distance. The lip height sets the launch point above the gap floor, and with the landing height establish if you're working with doubles, a step-up, or an often dreaded step-down. The gap distance is the void you need to clear. The landing angle and height offset determine whether your wheels kiss the slope gently or slam into flat ground.
Change any one variable and the entire trajectory shifts. A 5-degree steeper takeoff lip at the same speed can turn a clean landing into a 4-foot overshoot. A 2 mph drop in approach speed can leave you dangling over the gap's leading edge leading to a monster case.
Experienced riders develop intuition for this, but intuition fails at the margins, and the margins are exactly where crashes happen.
Projectile Motion, With Drag
At its core, the simulator solves a projectile motion problem, but not the textbook version. Once a rider leaves the lip, two forces act on them: gravity pulling them down, and air drag slowing them through the arc.
The launch velocities are straightforward:
vx = speed × cos(angle)
vy = speed × sin(angle)
Where gravity g = 9.81 m/s² and angle is the takeoff lip angle. In a vacuum, that's all you need, horizontal velocity stays constant, vertical velocity decays linearly. But at real-world speeds, air drag matters, especially for motorcycles carrying hundreds of pounds through the air at 40+ mph.
The drag force at any instant is:
F_drag = ½ × ρ × CdA × v²
Where ρ is air density (1.225 kg/m³), CdA is the rider+vehicle's drag area, and v is the current speed. The deceleration is F_drag / mass, applied opposite to the velocity vector. Math nerdery aside, a heavier vehicle feels less deceleration from the same drag force. Or to put it even clearer, a lighter-weight BMX setup loses speed faster than a motorcycle at the same velocity.
Because drag depends on velocity, which changes continuously, there's no clean closed-form solution. The simulator uses Euler numerical integration with a 0.0005-second timestep, updating position and velocity at each step. This produces a trajectory that's subtly different from a pure parabola, the arc is slightly asymmetric, with the descent steeper than the ascent. That's how real jumps work.
What all this stuff is working toward, and where the complexity lies, is detecting where on the landing ramp the rider actually touches down.
Landing Detection: Slope Geometry
The landing ramp isn't a point, it's a sloped surface with a defined start, angle, and length. The simulator steps through the trajectory in 0.001-second increments, checking at each step whether the rider's position has crossed below the landing ramp's surface.
The ramp surface is defined as a line from the gap's far edge, angled downward at the landing angle. At each timestep, the simulator compares the rider's y-position against the ramp's y-value at that x-position. When the rider crosses below the surface, we interpolate to find the precise landing point.
This discrete stepping approach is more robust than solving the intersection analytically, because it handles edge cases gracefully, riders that land past the ramp, riders that never reach it, and riders that graze the lip on the way down. Sadly the simulator doesn't account for deliberate stylish nose taps at the lip on landing, but that doesn't mean you shouldn't do them!
The Verdict System
So to rule a jump successful (safe!), landing on the ramp is necessary but not sufficient. A rider who lands on the ramp at a 45-degree descent angle when the ramp slopes at 25 degrees is going to be in for a rough time. The angle mismatch means the bike slams into the surface rather than matching it.
The simulator classifies every jump into one of five verdicts:
| Verdict | Condition |
|---|---|
| Clean | Lands on ramp, descent angle within 15° of ramp angle |
| Tight | Lands on ramp but very close to the start or end (ratio < 0.15 or > 0.85) |
| Hard Landing | Lands on ramp but descent angle mismatch exceeds 15° |
| Short | Lands before the ramp (didn't clear the gap) |
| Long | Lands past the ramp (overshot) |
The 15-degree tolerance is generous on purpose. Real-world suspension and body positioning absorb some mismatch. But beyond 15 degrees, even a skilled rider is going to feel it.
Impact G-Force
Beyond the verdict, the simulator estimates the G-force on landing. It calculates the component of the rider's velocity perpendicular to the landing ramp surface, the part that your body and suspension have to absorb, and converts it to a G-force estimate assuming a short deceleration window.
This number is especially useful when comparing vehicle types. A motorcycle landing at the same trajectory angle as a BMX hits the ramp with more perpendicular velocity because of its higher approach speed, even if the descent angle matches the ramp perfectly. A "Clean" verdict with 4G of impact is a very different experience on a 25 pound BMX bike than on a 200+ pound dirt bike.
Three Vehicles, Three Physics Profiles
BMX, MTB, and motorcycles ride fundamentally differently. A 20-inch BMX bike at 15 mph feels fast. A 27.5- or 29-inch mountain bike at 15 mph feels moderate. A 250cc dirt bike at 15 mph is barely rolling. The vehicles have different wheelbases, different masses, different drag profiles, and different speed envelopes.
The simulator ships with three presets:
| Parameter | BMX | MTB | Moto |
|---|---|---|---|
| Wheel diameter | 20" | 27.5" | 21" |
| Wheelbase | 37" | 41" | 58" |
| Mass (rider + vehicle) | 90 kg | 100 kg | 190 kg |
| Drag area (CdA) | 0.40 m² | 0.45 m² | 0.65 m² |
| Speed range | 5–25 mph | 8–30 mph | 15–55 mph |
| Gap range | 2–40 ft | 2–60 ft | 8–80 ft |
Unlike a simple projectile calculator, the presets do change the physics. Mass determines how much air drag decelerates the vehicle mid-flight, a 190 kg motorcycle shrugs off drag that would noticeably slow a 90 kg BMX setup. The drag area (CdA) captures the vehicle's frontal profile: a motorcycle with a seated rider presents a larger surface to the air than a tucked BMX rider. Together, mass and CdA produce meaningfully different trajectories at the same launch speed and angle.
"Dial It In": The Optimizer
The most useful feature isn't the physics or the visualization. It's a single button: Dial It In.
When a rider has set up their ramp geometry but can't find a speed that yields a clean landing, the optimizer searches the full speed range for the current sport preset, evaluating the physics at each 0.5 mph increment. It collects every speed that produces a "Clean" verdict, then picks the one closest to the rider's current speed setting.
If no speed in the range works, the ramp geometry is fundamentally incompatible, it goes further: adjusting the landing angle in 1-degree increments to find a viable configuration. The algorithm returns the smallest set of changes needed to make the jump work.
This is the feature that saves trips to the ER. A rider can set up their dream gap, hit Dial It In, and immediately know whether the jump is achievable and exactly what speed to target.
Rendering: Canvas 2D, Not WebGL
Anyone who ever played the old Stunt Cycle arcade game will appreciate this decision (yeah I'm aging myself, I know)...I deliberately chose Canvas 2D over Three.js or WebGL for this tool. The visualization is fundamentally two-dimensional, a side profile of the jump, and adding a third dimension would obscure the information riders actually need: trajectory shape, landing point, and angle matching.
The rendering system uses a dynamic coordinate transformation that maps real-world feet/meters to canvas pixels. The scene auto-scales to fit the jump geometry, keeping the takeoff lip as the origin point and expanding the viewport as the gap distance or peak height grows.
The Vehicle
Each vehicle is drawn procedurally. The bicycles get two wheels, a frame, handlebars, and a standing rider silhouette. The motorcycle gets thicker tires, a swing-arm, front fork, engine block, exhaust pipe, seat, fenders, and a seated rider with a helmet and visor, legs bent down to the pegs instead of standing on pedals. During flight, the vehicle rotates naturally using the actual descent angle at each point in the trajectory:
rotation = atan2(-vy, vx)
This produces the realistic nose-up-on-takeoff, level-at-peak, nose-down-into-landing motion that riders recognize from real footage.
Ghost Trails
Every time a rider changes a parameter, the previous trajectory is saved as a ghost trail, a semi-transparent dashed arc that lingers for 2 seconds before fading. Up to three trails are kept simultaneously.
Ghost trails are the key to iterative design. A rider can nudge the speed up by 1 mph and immediately see how the new arc compares to the old one. Without ghosts, each change exists in isolation. With them, the design process becomes visual diff.
The Animation State Machine
The simulator isn't just a static trajectory plotter, it animates the full jump sequence. The animation runs through four phases:
- Approach: The bike rolls up the kicker surface, following the curved ramp profile
- Flight: Projectile motion through the air, following the calculated trajectory
- Ride-off: On a clean landing, the bike eases down the landing ramp for 1 second
- Crash: On a miss, the bike freezes at the impact point with a red crash indicator
Each phase transitions to the next based on position triggers, not timers. The approach phase ends when the bike reaches the lip. The flight phase ends when landing detection fires. The ride-off or crash phase runs for a fixed duration, then the animation holds on the final frame.
Playback speed is adjustable from 0.25x to 2x, which is useful for studying the critical moment when the bike meets the landing ramp.
Kicker Geometry: The Radius Problem
The takeoff ramp isn't a straight slope, it's a curved surface defined by a radius. The kicker radius determines how gradually the rider transitions from horizontal to the lip angle. A tight radius (small value) creates an abrupt, poppy kicker. A large radius creates a smooth, flowing ramp that's easier to ride but requires more speed to clear a similar gap as its poppier cousin.
The simulator calculates the kicker radius automatically from the lip angle and lip height:
radius = height / (1 - cos(angle))
This is the same circular arc math used in skateboard ramp design, and it ensures the ramp profile matches real-world construction. The curve is rendered on the canvas as a series of line segments following the arc, giving riders an accurate picture of the ramp's shape and size.
What We Learned Building It
So all the tech implementation details aside, we learned a few things while building this tool:
Landing angle matters more than distance. The early prototype only checked whether the rider cleared the gap. Testers kept asking "why does this feel wrong?", the answer was always angle mismatch. Try jumping to flat in the real world and you'll feel this mismatch in your teeth! Adding the 15-degree tolerance check and the "Hard Landing" verdict transformed the tool from a distance calculator into an actual design tool.
Ghost trails were an afterthought that became essential. Ghost trails became a need because the canvas flickered between parameter changes and revealed a lack of visual continuity. Once created, riders started using them to compare trajectories, and now they're the primary way to iterate on jump designs.
The Dial It In optimizer needed to be conservative. Early versions would suggest radical changes, "increase speed by 12 mph and change the landing angle by 20 degrees." That's technically correct but useless. The final version minimizes the delta from the rider's current settings, making suggestions that feel like refinements rather than redesigns.
Try It
The Jump Simulator runs entirely in your browser. No account, no install, no tracking. Pick your vehicle, dial in your ramp geometry, and simulate before you build. Let us know if it helps you, and feel free to recommend improvements. Send it!
The Jump Simulator is a free experiment from Stalefish Labs.
Top comments (0)