Orbit Tessellation developer diary for Kerbal Space Program 2

Those are all quite old now of course, but even modern GPUs may not have 64-bit ALUs and rely on emulation instead. Intel Gen11 in Ice Lake, for example: https://01.org/sites/default/files/documentation/intel-gfx-p...

In mobile architectures 64-bit ALUs can be an optional feature that is omitted for lower end configurations. I know this is true of PowerVR.

    Some napkin/WolframAlpha math:
    if you wanted to use simple x,y,z coordinates,
    with the sun at the center
    and be able to represent locations at 30 AU (Neptune)
    with an accuracy of 1mm, e.g. 30AU vs 30.000...0001AU
    you'd need ~16 decimal digits of precision
    which is the same number of bits as a double (FP64)
    of course there's better ways to do this,
    in the surrounding smarter comments

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.

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.

That's fine, glad we got it cleared up.

> 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.

For a basic example-numbers implementation, replacing an n-body simulation that updates every 10 seconds, I was imagining that you might update the force vector 1/100th as often, every 1000 seconds. That's plenty fast to accurately handle a multi-day orbit around a lagrange point or a low energy transfer. The paths the craft take should look completely normal.

If you then combine a normal single-influence orbit with that force vector, you could summarize 1000 seconds of orbit into one moderately complex equation. So instead of doing a moderately complex calculation every 10 seconds, you'd do two of them every 1000 seconds, an estimated 50x CPU savings.

If you're not very close to anything, there's no benefit over just running an n-body calculation every 1000 seconds. But the hard-to-handle case is orbits that are low enough to need rapid updates, but high enough that it's noticeably wrong to use an ellipse. And it's easy to end up with a lot of things in those orbits.

> 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?

Treating the forces as constant over a stretch of time, when they actually are almost constant, shouldn't have all that much error, unless I'm missing something glaring.

As you get further and further away from the most influential mass, this system gets closer and closer to simply being an n-body simulation with a timestep of how often you update the force vector.