Projectile motion as simulation

A projectile is a compact example of the programming-first method. The launch speed, angle, and gravity are inputs. Time is the independent variable. Position is the observable output.

Think like a programmer

Keep the trajectory function pure and let Three.js draw only its returned points. That separation means the same model can be unit-tested without a browser or graphics card.

Model checklist

Inputs: Launch speed in metres per second, launch angle in degrees, gravity in metres per second squared, and elapsed time in seconds.
State: The chosen launch parameters; position is derived rather than stored.
Rule: Resolve the initial velocity into horizontal and vertical components, then apply constant acceleration vertically.
Output: Horizontal and vertical position, trajectory, and landing time.
Check: At t = 0, both position components are zero; at landing, vertical position returns to zero.

\[x(t)=v_0\\cos(\\theta)t, \\qquad y(t)=v_0\\sin(\\theta)t-\\frac{1}{2}gt^2\]

The simulation below draws values from that model. Three.js handles only the view; the position function lives separately, so it can be tested without a browser or graphics card.

Loading the interactive visual. The lesson text and model remain available while it starts.

What this model leaves out

It assumes a flat ground plane, constant gravitational acceleration, and no air resistance. Those simplifications make the update rule readable. They are not properties of every real projectile, so do not use this output to predict a golf shot in wind.

const y = launchSpeed * Math.sin(angle) * time - 0.5 * gravity * time ** 2;

An immediate check is that the projectile begins at the origin: positionAt(0) should return { x: 0, y: 0 }. The next lesson can replace this closed-form calculation with a step-by-step numerical integrator and compare its error.

Try this experiment

Prediction: At a fixed launch speed and gravity, a launch angle near 45 degrees produces the greatest horizontal range in this ideal flat-ground model.

Set the speed to 24 m/s. Predict whether 30 degrees or 45 degrees lands farther away, then use the landing time and path to check. Explain which omitted real effect could change that conclusion.

Where this model breaks

Air resistance, wind, spin, changing gravity, uneven ground, and launch height make real trajectories differ. The 45-degree range rule also depends on the same launch and landing height.

Summary

Projectile motion is one two-dimensional state calculation: horizontal motion is constant velocity, vertical motion is constant acceleration. Test the start and landing conditions before trusting the rendered arc.

Glossary

Projectile: an object moving mainly under gravity after launch.
Component: one coordinate-direction part of a vector.
Analytic solution: a direct formula for a result rather than a sequence of numerical steps.

Self-check

Which input changes the vertical acceleration in this model?
What should the position be at t = 0?
Why is the rendered arc not itself a test?

Sources

OpenStax, University Physics Volume 1, projectile motion.

Model contract

Treat the lesson as a small function before treating it as a fact to memorize. Give every value a unit, keep only the state needed for the next step, and make the output easy to inspect.

\[\text{observable output} = f(\text{inputs},\,\text{state})\]

Inputs: Quantities you set or measure, with units and useful bounds.
State: Values the program must retain to reproduce the next result.
Rule: The relationship or update that turns inputs and state into a result.
Check: A known limit, unit check, invariant, or measured result that can expose a bad model.

Implement the idea as a model

For Projectile Motion as Simulation, write down the quantities you can control, the values your program must retain, and the result a reader could inspect. In Motion in 2D and 3D, the useful program is not the drawing: it is the smallest explicit model that makes a prediction you can test.

Guided experiment

Prediction: changing one declared input while holding the others fixed should change only the outputs that the model connects to that input. Choose one input, predict the direction of change, then check a limiting case such as zero, a symmetric arrangement, or a familiar low-speed or small-change approximation.

Where this model breaks

This lesson is a teaching model, not a complete simulator. Before using it outside the stated question, check which interactions, scales, uncertainties, boundary conditions, and measurement limits it leaves out.

Summary

Treat Projectile Motion as Simulation as a contract: named inputs and units enter a rule, the rule produces an observable result, and a known limit or invariant checks whether the implementation deserves trust.

Glossary

Input: a measured value or chosen parameter supplied to a model.
State: the smallest set of values needed to continue or reproduce a model.
Validation: comparing an output with a known result, limit, invariant, or measurement.

Self-check

Which values are inputs, and which values must remain state?
What observable result would tell you the model is behaving as expected?
Which assumption would you test first before applying the model to a real system?

Model review: turn Projectile Motion as Simulation into a test

Turn launch speed and angle into a visible path with a pure physics model and a Three.js renderer.

Name the inputs and units that the motion in 2d and 3d model needs.
Separate the state you must keep from values you can calculate when needed.
Write one rule that maps the current state and inputs to an observable result.
Choose a limiting case, unit check, invariant, or known result before trusting an output.
State one assumption you would change before using this simplified model for a real decision.

Share to: