to those with better math than I

[Amram]

Before its said, Im not advocating for application of a complete N-body solution into KSP. I understand why we don\'t have such, KSP is hard enough on CPU\'s as it is, and from what i understand, the really accurate N-body solutions are particularly brutal and VERY time consuming. However, if it can be had for reasonable load.....and I had a thought.

To begin, a fairly simple assumption I\'ve made, pretty much everything in this is based off this, so if i\'m wrong here, it doesn\'t bode well for the rest. I assume gravity in KSP is computed for one body, whichever dominates the current SOI, and is a single acceleration towards its center of gravity(generally the actual center point for planetoids), magnitude being dependent on range, and mass of the body in question. Correct?

If so, then could N-body be reasonably approximated if one were to find the relevant vectors to more than one body, then sum them up into a single vector? To reduce load, don\'t work the result for permanent bodies, or for those with far too great a disparity in mass, and restrict the maximum bodies permitted to apply their influence(largest take priority). Mun-Landers should not be permitted to influence the Mun for example, both because its a permanent orbiting item and is far too massive in comparison.

If dealing with a medium sized asteroid, Mun, Kerbin, Kerbol, and the player\'s craft. If the players craft masses enough, and the asteroid is small enough, possibly permit the players craft to influence the asteroid.

Gravitational vector from Players craft to Mun, to Kerbin, to Kerbol, to Asteroid, combine, apply as single gravitational vector influenced by all 4 bodies.

Gravitational vector from Asteroid to Mun, to Kerbin, to Kerbol, to Players craft(if not too disparate), combine, apply as single gravitational vector influenced by all 4 bodies.

Mun, Kerbin, Kerbol considered immune to gravitation perturbations, and treated as if on rails if they aren\'t already, assuming they are though.

One thing I definitely do not know, does KSP work the gravity for each part in your craft, or does it work it out for the craft as a whole?

Horribly flawed concept? Or could this maybe be a rough concept for a workable N-body approximation that is enough for KSP? Also, given my rather distinct lack of programming and scripting experience, would this maybe be doable for KSP or still too much math for the gains given how demanding KSP already is.

Would this be just as fatally flawed regarding the mathematical scene origin as it is to have physics for de-orbiting debris? I would think the margins for error much more tolerable when dealing with additional bodies in this case, but, well, usual disclaimer: i\'ve been spectacularly wrong before, lol.

Thoughts?

Apologies if this isn\'t the place for such posts. Its not a feature request per se, since its a shot at fleshing out or shooting down a concept, so this seemed to be the place for it.

[vexx32]

I believe KSP works gravity out for your craft as a whole, and the centre of mass is assumed (I think) to be the command pod, which causes circular orbits to do funny things in the Map view as the craft rotates relative to the orbit vector.

As to whether it could work, I suspect it could. However, one must set the bounds for reasonable determination of what gravity will affect the object(s) in question. For example, even the most nearby stars should not influence a craft unless one is already outside of a star\'s SOI, so when traversing interstellar space, gravity could be utilised in some form.

The problem with this is because we have multiple craft flying about in most people\'s persistence files, if we always calculate relative to the body the currently focused craft is orbiting, then objects that are orbiting something else (say, the focused craft is orbiting Kerbol, while some other crafts are orbiting Kerbin) will have errors in their orbital calculations.

In order to avoid this, there needs to be some way to calculate orbits and suchlike for each object individually, rather than relative to the focused object. I don\'t know if PhysX is capable of this, but as with your suggestion for N-body simulation (without actually simulating it), it could perhaps be cobbled together in a way that PhysX could handle it.

In short, good idea, but there\'re a few things that need to be worked out first.

[ferram4]

@Amram:

You are correct in assuming that gravitational forces are only caused by one body currently.

However, the main problem with your idea is that it throws time warping out the window. The main reason for the two-body solution rather than solving the N-body problem is the fact that the two-body problem has an exact solution. The worst part of it is solving Kepler\'s equation for true anomaly as a function of time, but once that is done, everything else in the orbit can be calculated exactly at whatever time is desired.

The N-body problem would require (for accurate results anyway) that the game never go above 2x warp, or it would ask the processor to do supercomputer feats of calculation for 10,000x warp. Even your simplification would involve this to be calculated for each ship, and would effectively remove time warp from the game or else create huge amounts of lag as the game pauses to compute a few more minutes worth of trajectories.

It would also make the game slower on load due to the fact that the trajectory of each ship in orbit would have to be calculated out for run time. Not fun for us or the computer.

Oh, and as a side note, we would have to say goodbye to all stable orbits around Kerbin or the Mun. Eventually the other body would perturb all ships into re-entry, an escape trajectory or Mun-splat.

[Amram]

Stable orbits need an exclusion rule to allow them to not become a tedious nightmare to maintain.

What about treating all craft below an altitude threshold as only local SOI gravity, no additional influences. Perhaps Geostationary plus a margin when mostly circular orbit, and 1/7 geostationary when eccentric. Say 10% margin. Thats roughly 500,000m for non-circular orbits to come under the Mun\'s influence as well, and 3,800,000m for sufficiently circular orbits. Sufficiently circular being say, apoapsis not more than 125% periapsis?

regarding time warp: couldn\'t we just plant everything on rails when warping, thats what is done in KSP already isn\'t it? You\'ll get some odd anomalies when something ignores another body, but it already does exactly that, so we\'d lose nothing compared to what we already have. When not warping, you get higher accuracy in the orbits of minor items.

A highly cluttered environment would be a problem, since it piles on the workload. Craft to craft should should never be factored, there might actually be a tiny amount of micro gravity, but not worth fussing over I think. Im not sure it would be too great a problem though given the exclusion rule provided above. Not much in orbit will be in an eccentric orbit for most people at sufficient altitude to exceed the 1/7th of Geo altitude, and not much is likely to be orbiting higher than Geo is circular. Should keep this restricted to craft and objects transitioning between bodies.

So, to summarise/recap.

single body gravity when in a circular orbit at less than Geo +%margin, say 110%, 3,815,240 for Kerbin?

single body gravity for all non circular orbits until exceeding 1/7th Geo altitude, 495,500m for Kerbin?

Circular defined as Apoapsis less than 125% of Periapsis

no N-body approximating when time warping, everything goes to rails, just like we do now.

craft cannot become additional bodies of influence for other craft

Improved?

[Alchemist]

The only reason why there isn\'t multibody solution off-rails is becaus that would let to completely different results between on-rails and off-rails in some cases.

Unless you use n-body solution on rails, too. But that might be too heavy or unrtable in high warp.