30 karma · joined July 22, 2026
On the RK4 accuracy: it surprised me too, honestly. The 412 km RMS against JPL Horizons over 50 years came from combining adaptive timestep (the integrator tightens to ~0.001 days near perihelion) with the full N-body perturbation chain: Sun, Jupiter, Saturn, Uranus, Neptune. Most of the residual error is from ignoring relativistic corrections and non-gravitational forces, which I document as known limitations.
As for the naysayers: noted. Shipping is the answer.
My analogy: AI is like a calculator. In the hands of someone who doesn't understand math, it produces answers they can't verify. In the hands of someone learning, it lets you tackle problems that would otherwise take years to reach.
But the real answer is what I can demonstrate: I understand why Newton-Raphson converges for Kepler's equation, why RK4 needs 4 evaluations per step, why adaptive timestep matters near perihelion, and why N-body perturbations from Jupiter dominate over Saturn for most NEOs. I wrote the physics isolation boundary myself because I understood why it mattered.
Could I implement all of this from scratch without AI? Not yet. But I understand what's there and that's where I'm starting from, not ending.
I'm Davi, a 17-year-old developer from Brazil, and I've spent the last few months building NEO Radar, a browser-based orbital mechanics engine focused on Near-Earth Objects.
The goal wasn't to build another Solar System viewer, but to understand how orbital propagation actually works and implement as much of it as I could from first principles.
Some highlights:
• 41,812 real asteroids from the Minor Planet Center • JPL Horizons ephemerides • Newton-Raphson solver for Kepler's equation • Adaptive RK4 N-body integration • Monte Carlo uncertainty propagation • Real planetary perturbations • Interactive 2D heliocentric visualization
One architectural decision I'm particularly happy with is that the physics engine is completely isolated from rendering. The integrator has no DOM, Canvas or fetch dependencies—it simply outputs state vectors that the renderer consumes.
The repository also includes benchmarks, unit tests and documentation describing the numerical methods and the limitations of the model.
This project taught me far more about numerical methods and orbital mechanics than I expected when I started.
I'd really appreciate feedback, especially from anyone with experience in astrodynamics, numerical simulation or scientific visualization. I'm sure there are many things that can still be improved.