Well it seems to be hug-of-death'd - how are you loading 41k points of data?
you piqued my curiosity so I submitted it for indexing on deep wiki (https://deepwiki.com/azpeeen/NEO-Radar) ... surprised to see it was 1.5gb on disk... 700mb on disk of texture images and doesn't look like they've been quantized / compressed so there's some low hanging fruit there.
I know folks on here have a love / hate relationship but I think this would benefit from moving to cloudflare's stack. Current server is completely dead (has a Hostinger IP so they probably took it down from the traffic spike)
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.
Hey cool project! I built a solar system visualizer some years ago but just using the ephemerides data, no physics. This is ambitious. Noting your age I would say, invest some time in the basics - Euler, Improved Euler, finite differences, explicit vs implicit, multi-step methods etc.
Eg I see you've got a powerful adaptive Runge-Kutta method implemented in integrator.js. While that will do really well, for the sake of study you might make the solver implementation swappable and experiment with basic 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. Understand the fundamentals.
[flagged]
If anyone is wondering or it's not clear, AI was used. (There's some discussion in a sibling comment).
yep
Very cool I'm going to share with our NEKAAL group at Farpoint Observatory.
[dead]
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?
[flagged]
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.
Were people not able to accomplish that transition in the times before AI existed?
And that's a fine start, but my question was not why they avoided inventing everything from scratch themselves. Apprenticing to see how it can be done is only half the journey to understanding things from first principles, trying to then do it yourself is the other half. Usually you learn more in the second half than the first, you just need the first to make the second feasible.
Not that there is anything wrong with just wanting to make another visualizer and learn some things along the way, it's just a hollow way to try to learn first principles.
This is the answer. Sometimes you don't even know the word to use to find information.
This stage is called ‘keyword foraging’