[Suggestion] Multiple bodies of gravity have influence on ship at the same time

[PakledHostage]

The last discussion we had about it, someone showed graphs of a 3-body solution vs patched conics and they were 99% the same or so.

I don\'t know if you are referring to my post here, here, or even if you\'re referring to one of my posts at all... But I have been involved in these discussions before.

Below is the plot that I posted in the 'N Body Gravity why not?' thread back in December. I plotted it in Excel but the data comes from my trajectory planner (the physics engine is mine and I use it to plan all of my KSP missions, so I trust the results).

At the time, I noted that:

1. The initial orbital velocity (2266.9 m/s at 152 km altitude) was the same for both test cases

2. The Munar periapsis was the same in both cases (140 km)

3. The length of TMI burn required to yeild the 140 km high Munar periapsis was 0.8 seconds longer (85.0 seconds vs. 84.2 seconds) for the 3-body case than in the patched conic case.

4. In the 3-body case, the Mun\'s initial orbital speed was set to the 542.5 m/s used in the game (rather than the 547.4 m/s that it requires for a 12000 km radius circular orbit).

5. All three curves were plotted in Kerbin-centric coordinates. (i.e. the coordinate frame moves about the barycentre together with Kerbin in the 3-body case.)

6. If you\'re paying close attention, you might have noticed that the Mun\'s orbit crosses the Y axis at something less than 12000 km in the plot above. This is an artefact of Note 4, above. I should have plotted the Munar position for the patched conic case, not the 3-body case.

Now reading this thread this afternoon, I decided to go back and make another plot. This time, I compared a trajectory in the “KSP patched conic†model with a trajectory having the same initial conditions in the 3-body model. Only this time, I set the Mun’s orbital speed in the “patched conic†case (where the Mun moves on rails) to the same 547.4 m/s that is required in the 3-body model to yield a 12000 km radius circular orbit. (Using 542.5 m/s for the Mun’s initial speed results in it having an 11573 km x 12000 km elliptical orbit.)

And even though Kerbin and the Mun wobble around their mutual barycentre in the 3-body model, there still isn\'t a huge difference in the results when I transpose the 3-body model results into Kerbin-centric coordinates:

In short, the KSP patched conics work just fine at simulating even complex orbits like a free-return trajectory. I personally see very little benefit to revising the physics to a 3-body model, although some benefit could be realised by adjusting the Mun`s orbital speed upwards a bit.

Edit: Fixed a blunder in the plot that I posted earlier this afternoon.

[Kymlaar]

It may not be a big deal when you\'re simply calculating out 3 bodies, but what about more than that? And as for the 3+ body problem, the problem only exists because all bodies are effected by one another. If we accept that the planets, moons, and star are all on rails than the calculations no longer result in conservation of energy issues and many of the irregularities go away. So long as the gravitational bodies all remain on rails you should even be able to calculate the trajectories at high speeds.

I understand that this is a problem which is partially caused by the framework being used currently, but I worry that Squad is setting themselves up for a headache by using a 'quick-fix' which will result in the end code being more complicated than necessary.

PakledHostage: How long did the data take to come up with in all three of the cases? It looks like you\'re doing the exact thing I\'m talking about, so having some hard calculation on the time that set of calculations took would be beneficial to the discussion I believe.

[Coupon]

I\'d rather have high time warps than multiple bodies of gravity. At least it\'s still more realistic than those star wars space games.

[Kymlaar]

I don\'t see a problem with high time warps if you\'re only calculating the effect the orbital bodies have on your ship, and not on each other or you on them. If they\'re on rails that\'s all that would be required, and it would make for a relatively simple equation. This would also avoid the 3-body problem that was being discussed earlier.

[PeriapsisPrograde]

Implementing 3 body solutions in the Kerbin system would destabilize any orbits.

The force of gravity F = mMG/r^2.

F = ma, so ma = mMG/r^2

Solve for a is easy: a = MG/r^2

Plug in the values for the Mun: a = (9.76e20)(6.67e-11)/(1.2e7)^2.

The acceleration caused by the Mun is approx 4.52e-4 m/s^2!!

That is a dV of 1.627m/s per hour in LKO, or ~0.07% of the total orbital speed.

To compare, earth\'s moon only exerts 0.119 m/s dV per hour, or ~0.0015% of total orbital speed.

Munar orbits are even more unstable because of Kerbin\'s influence.

Also, that 0.07% is significant. That means your entire orbital velocity is countered every 1,430ish orbits, instead of every 66,000.

I have made the KSP system for Orbiter. It confirms this problem.

[semininja]

Just a note regarding those calculations: the variable ® does not represent radius of the body, but rather distance between the centers of mass of the two bodies...

[Iskierka]

Which he was actually using (1.2e7 m = 12000 km), but he missed one significant aspect in that such orbital disturbance is only usually a significant issue when you have orbital resonance. Unless the orbits are timed just right so that the satellite being considered passes the mun at the same point in the absolute reference frame, the effect of the mun\'s gravity will tend to cancel itself, as it finds itself pulling oppositely at other passing points.

The mun may provide ~0.07% of the orbital speed in dv per hour, but per orbit, Kerbin provides a whole 628% of the orbital speed in dv, and in LKO, ~1570% per hour. Perhaps it\'s a non-negligible effect, but it\'s a long, long way from being dominant. (For a reference of what\'s generally considered 'stable', having the SoI about three times more expansive than the current orbit is fairly widely accepted, and without orbital resonance effects LKO is well within this with respect to the mun.) I suspect any such orbiter experiments probably suffered from time warp inaccuracies, which, surprise surprise, KSP\'s patched conics is intended to prevent. Orbiter already has concerningly large numerical precision issues in LEO at high warp rate, the 1/11th size of Kerbin isn\'t going to help that.

[areyla]

You guys seem to be in the know. I\'ve been starting to play, and I had a few questions.

What gravity model does Kerbin have - similar to WGS84? Newtonian?

Does Kerbin orbit Kerbol elliptically (same question for Mun and Kerbin)?

Does KSP take into account center of gravity / center of mass differences for orbit attitude dynamics and control?

What velocity does the speed indicator measure - is there an inertial frame of reference?

Does everything lie in an 'ecliptic' or are there out of plane orbits for celestial bodies too?

I personally think N-body physics would be cool for KSP - although extremely difficult. You can add Lissajous and Lyapunov orbits and many other 'cool' orbital mechanical phenomena. Some of you say there is no solution to the N-body problem as if it were impossible to work with. There exists simulations for specific circumstances of the n-body problem - solutions if you will. There just isn\'t a global solution like in the 2-body case -> elliptical orbits, patched conics.

Lissajous orbits

I don\'t seem to see it addressed, but for a 2-body problem the solutions are planar, yes. But for n-body (3+) problems you start to get non-planar behavior. When considering the Jacobi for your body you get key-hole behaviors which become important when you have limited propellant.

http://svs.gsfc.nasa.gov/vis/a010000/a010600/a010636/ The artemis program took advantage of a lot of n-body problem dynamics to reach the moon from earth orbit on low propellant. As you can see - at the right distances the n-body solution differs dramatically from 'patched conics' simply because 2 bodies cannot give you the same behavior. You even start to get solutions where the orbits are 'pseudo periodic' in that a single velocity component returns to zero but the orbit never physically passes through the same point in space, it traverses a surface.

I\'m not sure but the SAS seems to take care of much of the orbital stability (attitude-wise), but for a real body decays in attitude lead to decays in orbital behavior (the two are coupled behaviors). Has anyone played with attitude behaviors in KSP?

Thanks for reading

-Areyla

[Kymlaar]

For destabilizing orbits, that\'s definitely a problem but we already deal with problems. It\'s one that could be resolved as new features are implemented (speed maintenance auto-pilots for when we\'re not in control, better planning, things like that.

If we don\'t have to deal with that ever, than we\'re going to end up with silly things like debris needing to wait until it\'s pushed out of the buffer. We\'re also going to have magical satellites that stay up forever, and effectively break immersion.

Don\'t get me wrong, I can certainly accept that. I just worry that there might be really cool things that we\'ll miss out on later on because of it, like space station resupply missions needing to involve transference of RCS fuel and things like that.

[boolybooly]

IMHO Unity has enough trouble with the solar orbit and the Kraken and sufficient CPUs have trouble with running KSP at all already that dreams of n-body have to be considered unrealistic and impractical pie in the sky. My solution to the grass always being greener on the other side of the hill thing is to be happy with what we have, which is quite a lot more than we had two years ago which was precisely nada.

Also as an afterthought, I wonder if Lagrange points 1 + 2 could be modelled as small SOIs with their own conditions which permit Mun synchronous orbit of Kerbin.

PS suggestions normally belong in the development forum

[snuffy5000000]

Hey, forgive me if I\'m wrong here but I\'m not quite understanding why an N-Body sim would be necessary. The planets and moons are on rails and the largest player-launched stuff is far too small for objects to have a noticeable effect on each other. I mean, yes, in the real world they would exert force on each other but in a KSP any effect would be so small it would be eaten up by floating point errors anyway.

Just make it so that every celestial object exerts force on each player objects and no object exerts force on a celestial object. Basically only objects on rails have gravity and only objects with no gravitational pull can be affected by it. This would mean that the force on a ship would be the sum of n one-body problems, here n being the number of gravity wells. In the current game this would take at most 4 times longer than a patched conic sim which would be a single two-body problem per object. The upshot is that every celestial body would effect the players ship at once though the players ship could not effect other bodies.

Or am I totally missing the point?

[PakledHostage]

PakledHostage: How long did the data take to come up with in all three of the cases? It looks like you\'re doing the exact thing I\'m talking about, so having some hard calculation on the time that set of calculations took would be beneficial to the discussion I believe.

That isn\'t an easy answer to give because my orbital trajectory planning utility is written in VB and has a GUI interface. Much of the processing time required to produce the data for a plot like the ones on the previous page is dedicated to updating the GUI. And I don\'t have time to port my physics library to something more computationally efficient. Sorry.

Even so, I think it is something of a moot point... This topic pops up from time to time (I am not sure why this old thread was revived again yesterday), only to get beaten back down. Each time, good ideas are proposed but the response is always the same: It doesn\'t fit with the game\'s current architecture. The Unity engine is too limited.

At this point, I tend to agree with BoolyBooly. Aspects like orbital perturbations, correct orbital velocity of celestial bodies and Lagrange points aren’t simulated, but we know about those limitations and we can work around them.

[Wyrm]

Hey, forgive me if I\'m wrong here but I\'m not quite understanding why an N-Body sim would be necessary. The planets and moons are on rails and the largest player-launched stuff is far too small for objects to have a noticeable effect on each other. I mean, yes, in the real world they would exert force on each other but in a KSP any effect would be so small it would be eaten up by floating point errors anyway.

Just make it so that every celestial object exerts force on each player objects and no object exerts force on a celestial object. Basically only objects on rails have gravity and only objects with no gravitational pull can be affected by it. This would mean that the force on a ship would be the sum of n one-body problems, here n being the number of gravity wells. In the current game this would take at most 4 times longer than a patched conic sim which would be a single two-body problem per object. The upshot is that every celestial body would effect the players ship at once though the players ship could not effect other bodies.

Or am I totally missing the point?

Yes. You have described exactly an N-body problem, and if you do this, then you cannot put bodies on rails because 'on the rails' refers to bodies orbiting according to analytical solutions, and there are no analytical solutions when n > 2 (where n refers to the number of interacting bodies, not the number of gravity wells: here, Kerbin is one, the Mun is two, Mimas is three, Kerbol is four, and your spacecraft is five. The current simulation uses two-body dynamics, which do admit analytical solutions).

[snuffy5000000]

I\'m sorry I don\'t mean to argue but I\'m not sure I communicated correctly what I was suggesting.

By 'on rails' I mean the orbits of Kerbin, Mimas and the Mun are hard coded ahead of time, simply circular paths offset by the position of their parent body. This means that they are not reactive bodies in the simulation, and as such they cannot be shifted off their predetermined path. At a given time, they are always in the same place. So there wouldn\'t be 5 interacting bodies, in fact no two bodies would interact because only the player\'s ship would be effected at all by gravity. My understanding of the n-body problem is that a 2 body problem is body A affects B and B affects A, and a three body problem is body A affects body B and C while body B is also affecting A and C and C is affecting A and B. In my suggestion body A\'s position is a function on the time, i.e. at a given time, position is the same, and body B is affected by the gravity from body A. In this way body A, B, C and D are all defined by a fixed function, not dependent of any other body, and body E (your ship) is affected by A, B, C and D. hence 4 one body problems, not one 5 body problem.

This is obviously a naive solution but this game is about flying your ship, not simulating the movement of the planets, so this would maybe be enough.

[PakledHostage]

I\'m sorry I don\'t mean to argue but I\'m not sure I communicated correctly what I was suggesting.

By 'on rails' I mean the orbits of Kerbin, Mimas and the Mun are hard coded ahead of time, simply circular paths offset by the position of their parent body. This means that they are not reactive bodies in the simulation, and as such they cannot be shifted off their predetermined path. At a given time, they are always in the same place. So there wouldn\'t be 5 interacting bodies, in fact no two bodies would interact because only the player\'s ship would be effected at all by gravity.

Ideas like yours were what I was thinking about when I posted above that some good ideas get proposed each time this topic comes up. Your suggestion would reduce the amount of computation required to predict the spacecraft\'s motion and would ensure that the planets remain in their intended orbits, but it would still require orders of magnitude more computation than what is required for the current system of patched conics.

There are a handful of relatively simple equations that predict an object\'s motion in a 2-body system. The game relies on these relatively simple 2-body equations for time warp and updating the map display. There is no similar set of equations for the system of n gravitational attractors that you are suggesting.

[snuffy5000000]

@PakledHostage Ah yes, I\'m sure the devs have thought much more about this than I have and there is definitely no \'simple\' answer.

I\'m sure that they will eventually find a more elegant solution than patched conics which doesn\'t really seem to fit with a real time interactive engine but in the mean time there is plenty more game play stuff to do

Anyway I\'ll let this thread die as it does seem to have been rezzed from some time back.

[Thiel]

@PakledHostage Ah yes, I\'m sure the devs have thought much more about this than I have and there is definitely no \'simple\' answer.

I\'m sure that they will eventually find a more elegant solution than patched conics which doesn\'t really seem to fit with a real time interactive engine but in the mean time there is plenty more game play stuff to do

Anyway I\'ll let this thread die as it does seem to have been rezzed from some time back.

That would require a total rewrite of essentially all the code in the flight scene which would set the game back to square one and even with the smoothest coding it would still take an order of magnitude more computing power. Just face it, Patched Conics are here to stay.

[snuffy5000000]

@Thiel Honestly it doesn\'t bother me, I only interjected because I thought that people were assuming that it was n-body resolution or bust and wanted to say that there is a third solution to the problem which I think would work well in KSP. I personally have no problem with how it works now though and I\'d rather see more fun features than a lengthy rewrite of the engine. Just contributing for the sake of discussion.

Also in general changing out one method of resolving the force of gravity for another should not the colossal undertaking that people are suggesting, modular code is our friend. Though I totally understand that Unity may introduce unavoidable stumbling blocks.