Kepler Orbits

[thombruce]

Planets should orbit their parent stars.

We want to do this "on rails" so that the position can be recalculated for any given time value (it's also just faster to do and much less prone to error).

I suppose each planet might have an Orbit component with:

• Semi-major axis (the "longest radius" of an ellipse - for a circle this is just the radius)
• Eccentricity (the "shape" of the orbit - circle eccentricity is 0, ellipse is between 0 and 1, parabola is 1)
• Inclination (tilt of the orbit)
• Longitude of ascending node
• Argument of periapsis

Using these and Time, we should be able to get the True Anomaly (position) of an orbiting body.

It's unclear to me what the difference between True Anomaly, Mean Anomaly and Eccentric Anomaly is at this point.

I'm also trying to figure out the relevance of longitude of ascending node and argument of periapsis for 2D. I think longitude of ascending node is useful, as it describes the direction of the eccentricity... essentially (which direction from the center is the long side pointing).

You might think inclination has no relevance in 2D either. For planets around stars, I think not - we don't want planets to orbit over the top of stars. But for the ship in orbit around a planet or a star, I would like for it to be able to pass over/under the celestial body rather than crash into it... This is gonna be a bit janky (I'm imagining we'll need to force a minimum radius to prevent orbiting within the body itself) but... should work, right?

For the planet-star relationship, I think we just need...

• Semi-major axis
• Eccentricity
• Argument of periapsis??

And an initial anomaly value from which time results in the new anomaly... which might just be Mean Anomaly rather than True Anomaly? Complicated. Found this Bevy module that does it seemingly for 2D: https://github.com/atbentley/bevy_mod_orbits/blob/main/src/orbit.rs

For 3D and the faux-3D I have in mind for the ship's position... you do need inclination and the longitude of the ascending node as well. Might be more janky than I was thinking actually, but we'll experiment.

[thombruce]

Is that what makes the most sense? An Orbit component with orbital values that is controlled by an orbital positioning system?

Seems right to me.

In later stages of development, these values will be generated for some number of planets, probably from a seed... and we'll need to make sure they don't conflict. But that can be worried about later. How we set this up now shouldn't interfere too much with that process.

[thombruce]

We have orbit in the current PR (#27) but it's just looping the planet around the star in a circle at a constant rate.

For a reasonable understanding of how to implement Kepler orbits, this seems like a good resource: https://www.youtube.com/watch?v=UXD97l7ZT0w&t=1319s

[thombruce]

Justification for adding the v0.1.0 milestone:

Presently, planets at greater distances from their parent body are moving faster than planets closer to it (see also #48). This is incorrect and is a problem that becomes worse as we increase scale (I'm currently planning to work on a solar system scale).

Kepler orbits fix this problem, as well as setting us up to do more advanced orbital scenarios in the future, like elliptical orbits.