Astrodynamics

Below is the actual map component, identical to the one on the home page. Every formula in the following sections is what positions these bodies. Use the Time control to change the simulation rate, Stack to reveal project moons, Refs to toggle the JPL layer, and drag / scroll to move the camera.

Interactive orbit map. Distance and speed encode project complexity; body size encodes project volume. Reference planets (Refs) and close-approach pings ride the same simulated clock.

Each project carries three 1–5 complexity ratings. A weighted average becomes the project's score, and the score maps to the semi-major axis a — the orbit's size — so larger / more complex projects sit farther from the star.

score = volume × 0.35 + architecture × 0.45 + polish × 0.2
a (semi-major) = map(score, 1..5 → 128..286 px)
radius         = map(volume, 1..5 → 9..25 px)

Architecture is weighted highest (0.45) because system design is the strongest signal of engineering depth. Body size tracks volume alone, so a project can read as physically large from surface area even when its score is moderate.

The e column is derived, not hand-picked: eccentricity scales with the score (map(score, 1..5 → 0.1..0.28)) plus a small stable per-project jitter (±0.035), clamped to [0.08, 0.34]. The jitter is a fixed hash of the project slug, so the value never changes between builds; any project can still override it explicitly. So every number in this table is reproducible from the formulas above.

Kepler's first law: each body orbits on an ellipse with the star at one focus, not the center. From the semi-major axis a and eccentricity e the rest of the shape follows.

b  = a · √(1 − e²)          // semi-minor axis
cx = −a · e                 // ellipse centre, offset from the star at the origin
rx = a,  ry = b             // then rotate by the argument of periapsis ω

The hard part is where a body is at a given time. Time enters as the mean anomaly M (which advances uniformly), but position needs the eccentric anomaly E. They are related by Kepler's transcendental equation, solved each frame with a few Newton iterations — the same procedure JPL documents for approximate planetary positions.

M = E − e · sin E                              // Kepler's equation (no closed form)
E ← E − (E − e·sin E − M) / (1 − e·cos E)      // Newton step, iterated ~7×
x = a · (cos E − e)                            // position in the orbital plane
y = b · sin E
(x, y) → rotate by ω (argument of periapsis)

Solver details: the iteration starts from E₀ = M (or π for the near-parabolic case e ≥ 0.8) and runs a fixed 7 Newton steps with no early-out — Newton converges quadratically and the eccentricities here (e ≤ 0.34 for projects, ≲ 0.21 for the planets) settle in 2–3 steps, so 7 is comfortably safe. This is a deliberately bounded solver for low eccentricity, not a robust all-eccentricity implementation.

Project bodies and real JPL planets obey one law. The same screen-distance → AU mapping that places the reference planets is inverted for project bodies, then Kepler's third law (period² ∝ semi-major³) sets each period. A project sitting on a given visual ring therefore orbits at the same rate as a planet on that ring.

au         = ((a − 70) / 101)²        // inverse of the JPL display mapping
periodDays = 365.25 · au^1.5            // Kepler's third law, year-normalised
meanMotion = 360 / periodDays              // degrees per simulated day

Because the mapping round-trips, feeding the real planets' on-screen radii back through this law reproduces their true periods (~88, ~366, ~687, ~4332 days — see the reference table below). To be precise about what is "physics": a project's orbit size (a) is an authored design glyph — it comes from the complexity score, not from any mass or distance. What is genuinely Keplerian is the phase law that follows: once a is fixed, the period, mean motion, and per-frame position are real two-body motion sharing one rule with the JPL planets, not an arbitrary constant.

All motion is driven by one simulated-day clock. The Time control sets how many simulated days pass per real second; the same value scales every body, so relative speeds stay correct at any setting. The clock accumulates deltas rather than elapsed × speed, so changing speed never teleports a body, and pausing is simply "stop accumulating".

simDays += (deltaMs / 1000) · daysPerSecond

The selection persists in localStorage. Under prefers-reduced-motion the map starts at Static; moving the slider is treated as explicit consent and the ecosystem animates from then on.

Four real planets are animated from osculating orbital elements captured from NASA/JPL Horizons at build time (epoch 2026-06-15). The browser makes no API calls — the snapshot is static data. Each planet rides the same simulated clock, so its visible period scales with the speed setting while preserving true relative motion (Mercury still laps Earth).

M = M₀(epoch) + simDays · meanMotion        // advance from the snapshot mean anomaly
E = solveKepler(M, e)                       // same Newton solver as project bodies
(x, y) = ( rx·(cos E − e), ry·sin E )
       → rotate by ϖ = Ω + ω                // ecliptic longitude of perihelion; inclination flattened

Frame

J2000 ecliptic, projected top-down to 2D — inclination I is flattened away (max ~7°, Mercury).

Orientation

Each orbit is rotated by the longitude of perihelion ϖ = Ω + ω (ascending node + argument of perihelion), so the four orbits are correctly oriented relative to a common reference direction — not by ω alone.

Angles

Mean motion is shown in degrees/day for readability; every angle is converted to radians before the trig solver. M, E internal math is radian.

Epoch & source

Frozen osculating elements at the snapshot epoch (2026-06-15), Sun-centred (Horizons 500@10). Two-body propagation of frozen elements drifts from a full Horizons ephemeris away from the epoch — there is no perturbation model. Accurate near the epoch; schematic over long spans.

Each project planet carries moons — one per core stack component. A moon runs the same two-body Kepler solve as a planet, but about its planet instead of the star; the planet's heliocentric motion then carries the whole moon system along (a vector sum each frame).

a_moon      = semiMajorRadii · planet.radius      // distance authored in planet radii
periodDays  = 12 · semiMajorRadii^1.5            // same Kepler shape, per planet
moonPos     = planetPos + moonLocal               // planet-centred vector sum

Distances are in planet radii so moons scale with their planet. The 12-day base is a schematic constant: every moon obeys one period-at-unit-radius law regardless of its planet, i.e. constant-density-style scaling — not a per-planet μ-parameterised satellite model. Moons are hidden at system scale and reveal when the parent is selected, when camera zoom ≥ 1.3, or when the Stack layer is forced on. Moon masses and mutual perturbation are out of scope — deliberately schematic.

A few effects are presentation, not simulation:

• Trails — 9 sampled positions across the last 7.5% of each body's period along its real orbit curve (not particles).
• Camera — UI easing toward a target transform (current += (target − current) · 0.14), not a physical body.
• Signal sweep — a rotating radial line and expanding ring; both stop under reduced motion.

• No N-body gravity, perturbations, masses, velocities, accelerations, or state-vector propagation.
• No explicit gravitational constant μ in the browser math — but the period law T = 365.25·a^1.5 is Kepler's third law Sun-normalised, so it implicitly fixes the solar gravity scale in AU/year units. "No μ" means no μ-based state-vector propagation, not no gravity.
• No real astronomical scale — complexity is mapped into orbit size.
• Reference bodies animate from a frozen osculating-element snapshot, not a live or perturbed ephemeris; two-body propagation of those elements drifts from full Horizons away from the epoch.
• Runtime math is intentionally duplicated from the build-time model so the browser script stays self-contained.

The intended compromise: realistic behaviour with schematic visuals.

External sources that informed the formulas and terminology (verified official NASA/JPL pages):

• Orbits and Kepler's Laws NASA Science Conceptual basis: elliptical orbits, the primary at one focus, non-uniform speed, and longer periods farther out.
• Approximate Positions of the Planets JPL Solar System Dynamics Keplerian elements and the exact Kepler-equation Newton solve (M = E − e·sin E; x' = a(cos E − e), y' = a√(1−e²)·sin E) the map reuses.
• Horizons API documentation JPL Solar System Dynamics Osculating orbital-element vocabulary (EC, W, MA, A, N) for the reference-body snapshot fetched at build time.
• Horizons system JPL Solar System Dynamics The ephemeris system the reference-body elements are sourced from.
• CAD (Close-Approach Data) API JPL Solar System Dynamics Source of the ambient close-approach source markers (pings) on the map.
• CSPICE conics_c NASA/JPL NAIF Conic-element → state vocabulary (periapse argument, mean anomaly at epoch, μ) the schematic model deliberately simplifies.