[aw1621107]

> It's not like you need to update orbits nearly as often as part physics. The max time warp is 100000x, and at that speed if you updated orbits every 10 game seconds that would only be 400 calculations per tick, per craft. So without that simplification you might need a smaller cap on satellite swarms, or a max speed of 10000x, but time warp would still be well inside the realm of "possible".

KSP's most well-known n-body physics mod does precisely this. 1 integration step is performed every frame by default, but during warp an integration step is performed every 10 in-game seconds for vessels and every 35 minutes for bodies [0].

> You could probably get processor use really low by using an exact curve for the most influential object and a very slowly updated offset for other influences.

The Keplerian curve no longer applies once you introduce additional influences, though, so it doesn't really matter how (in)frequently updates are applied for those other influences.

The approximation wouldn't be very good farther away from a body as well, as the difference in effect between the "most influential" and less-influential bodies would be smaller.

[0]: https://github.com/mockingbirdnest/Principia/issues/2247#iss...

[Dylan16807]

> The Keplerian curve no longer applies once you introduce additional influences, though, so it doesn't really matter how (in)frequently updates are applied for those other influences.

It depends on how well you can simplify the math. I would imagine that instead of an n body calculation it's lot simpler to calculate the influence from one body plus one unchanging vector, but I've never tried it.

> The approximation wouldn't be very good farther away from a body as well, as the difference in effect between the "most influential" and less-influential bodies would be smaller.

Not a problem because if you're not close to anything then your orbit won't be chaotic.

[aw1621107]

> I would imagine that instead of an n body calculation it's lot simpler to calculate the influence from one body plus one unchanging vector, but I've never tried it.

I think what you describe could either be Euler's three-body problem (two fixed point masses and a particle) [0], or the restricted three-body problem (two point masses and a particle) in a rotating/pulsating reference frame. The former does have exact solutions, and I don't believe the latter does, though I'm admittedly not familiar with the literature. I'm also not sure how easy/hard it is to evaluate the exact solution, and how the difficulty compares to proper n-body integration.

That being said, I think using Euler's three-body problem would result in losing some potentially useful n-body effects. For example, centrifugal/centripetal forces would be missing compared to a restricted three-body problem in a rotating reference frame, so Lagrange points might not be present. There might be other effects I'm not aware of as well.

> Not a problem because if you're not close to anything then your orbit won't be chaotic.

I'm not sure I understand why being farther away from something would result in less chaotic trajectories? If anything, I'd expect more interesting orbits due to the lack of one dominating influence.

[0]: https://en.wikipedia.org/wiki/Euler%27s_three-body_problem

[Dylan16807]

> I think what you describe could either be Euler's three-body problem (two fixed point masses and a particle) [0], or the restricted three-body problem (two point masses and a particle) in a rotating/pulsating reference frame.

Even simpler, though, because only one of the masses needs to have a location. The other one is effectively at a fixed direction and distance, far enough away that you can ignore relative motion.

> I'm not sure I understand why being farther away from something would result in less chaotic trajectories? If anything, I'd expect more interesting orbits due to the lack of one dominating influence.

I'll rephrase. The gravitational vector on the craft won't be shifting very fast, so you can get away with a quite big timestep.

[aw1621107]

> Even simpler, though, because only one of the masses needs to have a location. The other one is effectively at a fixed direction and distance, far enough away that you can ignore relative motion.

This still sounds like precisely what I described. Euler's three-body problem is two fixed point masses, so there's no relative motion by construction, and the restricted three-body problem in a rotating/pulsating reference frame has mathematical transformations applied so the two bodies are "effectively fixed" relative to each other in that reference frame (while preserving effects due to rotations, such as centripetal/centrifugal forces).

The question in such a case becomes whether such a thing is substantially better than a regular n-body integrator. Euler's three-body problem may lose some useful n-body effects such as Lagrange points, which partially defeats the purpose of moving away from Keplerian orbits, and the restricted three-body problem arguably isn't simplified enough compared to full-blown n-body integration to be worth it.

> I'll rephrase. The gravitational vector on the craft won't be shifting very fast, so you can get away with a quite big timestep.

Ah, that makes more sense. IIRC Principia has an adaptive timestep, so it already does that, though that's with full n-body calculations. Swapping between the approximation and proper n-body depending on position relative to other bodies seems like a rather complex scheme, though, and I'm not sure whether that'd be the best approach.

[Dylan16807]

> This still sounds like precisely what I described. Euler's three-body problem is two fixed point masses, so there's no relative motion by construction, and the restricted three-body problem in a rotating/pulsating reference frame has mathematical transformations applied so the two bodies are "effectively fixed" relative to each other in that reference frame (while preserving effects due to rotations, such as centripetal/centrifugal forces).

You still have to care about the where the particle is relative to both masses. The whole point of the calculation is figuring out which way the particle goes, and the simplification I'm suggesting removes a lot of that math. Instead of two masses providing a continuously varying force in both direction and magnitude, you have one mass providing a continuously varying force plus a static offset. This removes multiple degrees of freedom from the problem.

> Swapping between the approximation and proper n-body depending on position relative to other bodies seems like a rather complex scheme, though, and I'm not sure whether that'd be the best approach.

I wasn't suggesting swapping between the methods. If you're in the middle of nowhere, then while the Keplerian portion of the model will be a smaller factor, it won't harm anything.

[aw1621107]

> Instead of two masses providing a continuously varying force in both direction and magnitude, you have one mass providing a continuously varying force plus a static offset.

Ah, so the force vector is constant/infrequently updated, not the position of the second body. My apologies for the misunderstanding.

I'm honestly a bit curious what an that would look like. For example, what would an orbit around the Earth-Moon L1 look like? What would an Earth -> Moon low-energy transfer look like?

I feel like depending on the system you might need to update the "fixed" force vector relatively frequently to get anywhere close to approximating n-body results, which basically sounds like regular integration.

I suppose at some point the question becomes how much fidelity are you willing to sacrifice in the name of decreasing CPU usage.

> I wasn't suggesting swapping between the methods.

My mistake again. Sorry about that.

> If you're in the middle of nowhere, then while the Keplerian portion of the model will be a smaller factor, it won't harm anything.

Wouldn't that arguably be where the most significant errors would be, as that's where the relatively unphysical constant force vector would have the most significant influence?

[db48x]

I found Principia’s code to be quite nice to read too; I recommend it next time you have a lazy Sunday afternoon.