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.
Hey cool project! I built a solar system visualizer some years ago but just using JPL's ephemerides, no physics. This is ambitious. Noting your age I would say, invest the time to study numeric methods starting from basics - Euler, Improved Euler, finite differences, explicit vs implicit, multi-step methods and adaptive.
Eg I see you've got an adaptive Runge-Kutta method implemented in integrator.js. While that will do really well the purpose of this project is to learn - maybe you could make the solver implementation swappable, to experiment with and gain understanding of the different techniques. Some are very slow. Some maybe unstable and blow up the solar system. Why? Numeric methods are not one size fits all - see what the different tradeoffs are and how they respond to fiddling parameters.
When I'm starting from mostly ignorance, being an apprentice is better than trying , making little progress, and giving up. The problem will be if we never transition from being an apprentice, to independence.
Well it seems to be hug-of-death'd - how are you loading 41k points of data?
Hi HN!
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.
GitHub: https://github.com/azpeeen/NEO-Radar
Hey cool project! I built a solar system visualizer some years ago but just using JPL's ephemerides, no physics. This is ambitious. Noting your age I would say, invest the time to study numeric methods starting from basics - Euler, Improved Euler, finite differences, explicit vs implicit, multi-step methods and adaptive.
Eg I see you've got an adaptive Runge-Kutta method implemented in integrator.js. While that will do really well the purpose of this project is to learn - maybe you could make the solver implementation swappable, to experiment with and gain understanding of the different techniques. Some are very slow. Some maybe unstable and blow up the solar system. Why? Numeric methods are not one size fits all - see what the different tradeoffs are and how they respond to fiddling parameters.
Why did you choose to have something else write the project if your goal was to learn as much as you can from first principles yourself?
When I'm starting from mostly ignorance, being an apprentice is better than trying , making little progress, and giving up. The problem will be if we never transition from being an apprentice, to independence.