On Newtonian trajectories vs. patched conics

[Mattasmack]

I've seen a number of conversations here in the forums about patched conics in KSP and whether or how more realistic motion of spacecraft could be calculated using Newton's laws of motion. The threads have contained a lot of speculation about why a Newtonian approach might not work: too much numerical error or drift, high timewarp wouldn't be possible, showing trajectories in map view wouldn't be possible, etc. But I generally didn't see a lot of data to support anyone's conclusions, and I did my share of speculation too. I thought it would be an interesting exercise to generate some data by simulating trajectories of vessels in the KSP solar system using Newton's laws of motion and universal law of gravitation, and seeing what problems come up and whether they can be overcome. I haven't (yet) looked at n-body simulations of the KSP solar system -- I left the moons and planets in their current Keplerian trajectories and just simulated the motion of spacecraft around them.

In short, I believe trajectories based on Newtonian mechanics can be used in KSP. This isn't a suggestion to make the change in KSP; the patched conics approach is good enough (for now at least), and if anything is going to be changed with the physics of the game I think it's PhysX that's the biggest problem right now. My goal here is to just inform discussions on the topic.

I put a much more long-winded article on my website with the details, but the highlights are:

The accuracy of the simulation depends on the numerical integration scheme used and the size of the time step used in the simulation. Using a numerical scheme with a high order of accuracy makes it possible to achieve very good accuracy while taking large time steps (less than 1 cm error after an orbit of Kerbin, with time steps larger than ~20 s). At least up through a fifth-order Runge Kutta method (which is as far as I went), there is always a big gain in efficiency in going to higher-order methods. (By which I mean, the higher order methods get increasingly costly to calculate per time step, but they allow much larger time steps to be taken so overall less computation is required to simulate a given length of trajectory.)

The maximum time step that can be taken for a given amount of error depends strongly on the trajectory -- lower orbits and more eccentric orbits require much shorter time steps than higher ones. Orbits of Kerbol further out than Jool can use time steps of several millions of seconds, as contrasted with time steps of ~20 s for low Kerbin orbits. Using an embedded integration scheme that can adjust its time step to maintain a certain error level is advantageous. I found Dormand and Prince's Runge Kutta method RK5(4)7M to work very well.

This half-way approach (planetary bodies on Keplerian trajectories and vessels on Newtonian trajectories) doesn't seem to have Lagrangian points.

The difference between a Newtonian trajectory and a Keplerian orbit is pretty small for low orbits, but the difference between them grows quickly as orbits get higher, especially for planets with moons. Therefore, if Newtonian trajectories are implemented, each planetary body could have its SOI shrunk to a fairly small radius. Inside the SOI, Kepler's laws apply and orbits would be perfectly stable with no perturbations. Outside of any SOI, in no-man's-land, Newton's laws would apply.

With this approach, the time step size needed for good accuracy is always large enough that 100,000x timewarp is possible even if trajectories for a large number of objects need to be calculated.

The trajectories should be calculated ahead of time, so that they can be displayed in map view. Interpolation inside of a time step is very fast and accurate using Shampine's method of finding an additional solution for position and velocity at the midpoint of each time step and then creating fourth- and fifth-order interpolating functions. The interpolated state can be used to provide the position and velocity of a vessel at each frame and to pinpoint certain points in the trajectory (closest approaches to a target vessel, etc.). Whenever a vessel accelerates the precalculated trajectory would have to be thrown out and a new one calculated, but usually only one vessel is accelerating at a time so it would not be a serious problem.

Edited September 7, 2013 by Mattasmack

[GusTurbo]

Wow, this is a very well thought out post. I don't totally understand it, so I'd like to ask a question.

What practical effect would this have on the game? In other words, what would be different from a gameplay perspective?

[OrbitusII]

*Opens thread*

INFORMATION!!!

Cool ideas, I'll have to read your full article sometime.

So basically what I understand is that every timestep, the orbit is recalculated in case something arbitrarily changes (continually recalculated in case of acceleration) and we have pseudo-n-body gravitational fields using Newtonian physics?

The interesting thing about using more accurate numbers like doubles instead of floats (I think KSP uses floats right now) is that we get a lot more accuracy (several orders of magnitude, if memory serves) in exchange for double the amount of computing power of a float (thus the name "double").

[Captain Sierra]

Getting over laughing from the previous post and after reading it, nice. Glad to see someone actually looking into this crap. The info is actually quite fascinating. I'll have to read the full article sometime.

[Mattasmack]

Wow, this is a very well thought out post. I don't totally understand it, so I'd like to ask a question.

What practical effect would this have on the game? In other words, what would be different from a gameplay perspective?

That's a fair question! I'm having trouble putting an answer in words, so please excuse my rambling.

Ignoring things like relativity, the Newtonian trajectory for a vessel is the correct one. Patched conics is an approximation. The patched conics trajectory is not dramatically wrong, but it is simplified. With Newtonian trajectories, basic things like the amount of time or delta-V to get from one place to another would still be about the same, but the path would be more complex.

With Newtonian trajectories, a vessel in a high orbit around a planet has its path perturbed by the planet's moons or other bodies. It does not come back to the same place it started from after one orbit. Depending on the circumstances, over time the plane of the vessel's orbit could be changed or it might be pulled up or down into a different orbit or even out of orbit entirely. (Contrast with the current situation, where a vessel in an orbit will follow the same orbit forever unless it enters the SOI of another body or the player does something to change it.)

With Keplerian trajectories, if you launch a vessel from low Kerbin orbit to Mun, unless you get an encounter with Mun (that is, the vessel enters Mun's SOI), Mun has no influence on the trajectory whatsoever. With Newtonian trajectories, Mun always exerts some pull on the vessel, which gets stronger and more significant as the vessel approaches Mun. The basic features of a transfer orbit between the two bodies is the same in either case, but two trajectories would differ in the details, especially for trajectories that would skirt the edge of Mun's SOI.

I'll have to see if I can make some plots of similar trajectories in KSP and using Newtonian mechanics in the next day or two.

...

Cool ideas, I'll have to read your full article sometime.

So basically what I understand is that every timestep, the orbit is recalculated in case something arbitrarily changes (continually recalculated in case of acceleration) and we have pseudo-n-body gravitational fields using Newtonian physics?

The interesting thing about using more accurate numbers like doubles instead of floats (I think KSP uses floats right now) is that we get a lot more accuracy (several orders of magnitude, if memory serves) in exchange for double the amount of computing power of a float (thus the name "double").

Thanks! Right, whenever something happens to a vessel that imparts any acceleration (a collision, a rocket or RCS thruster firing, docking/undocking, a decoupler firing, etc.), its old precalculated trajectory is no longer valid and has to be thrown out. If a rocket is firing, that means the predicted trajectory is changing every single frame, so in the map view there would have to be some tradeoff between how often an old trajectory is thrown out and how far out the projected trajectory is shown.

But I believe in most games, most objects in space will be debris (whose trajectories will never change on their own) or vessels in low circular orbits (mapping satellites, space stations, etc.). So the precalculated trajectories will not have to be thrown out very often, except for the case of interplanetary vessels that the player is actively controlling.

Yeah, floats are totally inadequate for this sort of simulation and I didn't even consider trying them. Doubles have roughly 16 decimal digits of precision, which is good enough to give sub-millimeter resolution even out around Eeloo (assuming Kerbol is at the origin). I believe floats have around 7 digits of precision. And of course, these calculations are applied at the level of a whole vessel and give the trajectory of its center of mass. When focused on a vessel the interactions between individual parts would still be done with the origin defined as the vessel's center of mass, which I believe is how it's done now.

Getting over laughing from the previous post and after reading it, nice. Glad to see someone actually looking into this crap. The info is actually quite fascinating. I'll have to read the full article sometime.

Thanks!

[The Destroyer]

Oh my god when I clicked this, it started me at that gif.

Oh god.

[stupid_chris]

I haven't had the time to read everything you wrote up there, actually, I'm not really in the mental state to do so (extremely tired tbh), so I went diagonals and I think I got what you meant. If you imply that what you want by switching to Newtonian based calculations of physics is to get orbital perturbation from moons/other outside sources on high orbits, I'm aafraid this wouldn't work so well. I'm highly doubting this could really work given the limitations of KSP. As soon as you calculate a trajectory by taking in account multiple bodies at the same time, you get into the realm of n-body physics. KSP is currently struggling with Keplerian orbits. The main problem is that the biggest thread on the CPU, the physics calculations, can't be split across multiple cores. That's what causing so much lag to everyone when you get a lot of parts in the physics load distance. Orbits are calculated taking account only one body to try to minimize this thread. The more bodies you get, the more calculations you have to do. Being around Jool would likely be hellish if you took account of every moon on high orbits.

Like I said, I haven't fully read, I'll give it a better look when I'm rested and probably read through the article, but from what I'm understanding now, I'm not so sure that this would play nice for our CPUs. I could be wrong though.

[a humble lich]

First, good article, I was wondering many of this myself. I had a couple thoughts on reading it, from my experience in doing numerical integration.

1. With regards to integration schemes, given how smooth planetary orbits are, you could probably use a much higher order integration scheme. The RK45 that you used is good, I remember using a 7th/8th order Runga-Kutta method that I liked too. Or if you wanted to be super serious, you could use ODEPACK, a standard numerical library for solving ODEs. I remember being impressed on the speed gain I would get using ODEPACK compared with a simpler Runga-Kutta. Whether it is worth the programing time is another question.

2. As for not being able to find stable Lagrangian Points, I would want to see more simulation results, but I would guess that the numerical errors from your integration scheme are causing them to loose stability. Runga-Kutta methods do not conserve energy, so for physical systems where that is important (like planetary dynamics), they will introduce errors in the long term. These effects are often worst around stable points. There exist integration schemes that do preserve energy, but these are generally much more complex. Other possibilities are that perturbations from Minimus are causing you problems, or possibly that you have a bug somewhere (which I'm sure isn't the case, after all, my programs _never_ have bugs, why would anybody else's? :-))

p.s. This is the first time I've posted here!

[Tygroux]

I haven't had the time to read everything you wrote up there, actually, I'm not really in the mental state to do so (extremely tired tbh), so I went diagonals and I think I got what you meant. If you imply that what you want by switching to Newtonian based calculations of physics is to get orbital perturbation from moons/other outside sources on high orbits, I'm aafraid this wouldn't work so well. I'm highly doubting this could really work given the limitations of KSP. As soon as you calculate a trajectory by taking in account multiple bodies at the same time, you get into the realm of n-body physics. KSP is currently struggling with Keplerian orbits. The main problem is that the biggest thread on the CPU, the physics calculations, can't be split across multiple cores. That's what causing so much lag to everyone when you get a lot of parts in the physics load distance. Orbits are calculated taking account only one body to try to minimize this thread. The more bodies you get, the more calculations you have to do. Being around Jool would likely be hellish if you took account of every moon on high orbits.

Like I said, I haven't fully read, I'll give it a better look when I'm rested and probably read through the article, but from what I'm understanding now, I'm not so sure that this would play nice for our CPUs. I could be wrong though.

The gravity part of the KSP physics problem is not really a problem.

You could throw a unity-independant thread to calculate the gravity vector using an average of all gravity body to consider, and then say unity to use that vector. It's relatively easy. Unless unity forbid that for a reason or another, wich is possible.

What is more problematic to thead is physical interactions of part to part(or ground...).

[Evrion]

As I see your idea:

1) Keep current model when no other astronomical bodies are close enough to matter much

2) Use a numerical integration model when multiple astronomical bodies have "significant" affect. (Significant here would have to be interpreted by the programmer)

I would LOVE if KSP would implement n-body physics! I REALLY want to use Lagrange points!

Mostly. It would make fewer orbits stable. It would increase calculations needed with many craft in space. And I suspect that this is the reason SQUAD went with the current model; all craft no the current focus can simply be placed at the appropriate places along their very well known orbits, no real calculations needed, ever.

I hope somebody can figure out a way to implement this and actually test it within the context of this game. As stupid_chris pointed out, physics is the biggest calculation in game right now (mostly part to part calculations though) so I imagine any physics added to the game would have potential issues to deal with. But, it seem like it just might work!

edit:

Thinking about this more, using Newtonian trajectories would increase orbital motion complexity (in a good way in my book!). This would increase the draw for the hardcore physics audience, but decrease the draw for a general audience as it would be harder to fully understand. It would also increase computational demand, even if only a little. Overall, this would decrease the total audience for the game. So I think it is unlikely that SQUAD would want to do this

Edited September 8, 2013 by Evrion

[Hannu]

I think that change to Newtonian physics would not increase processor load too much, if it was made clever way, like Mattasmack suggested. Orbital computations would be much simpler than modeling of interacions between ships' parts. I made a simulation of our solar system's planets and Earth's moon (which made things more difficult by an order of magnitude or two) several years ago. It was able to simulate 300 years in couple of minutes in AMD's cheap processor and one thread so, that largest error in position coordinate was 1/1000. JPL's Horizon gave initial values and reference data. I understood that they should be very accurate values during couple of hundreds of years. I used Runge Kutta 4 method to solve motion equations. It is relatively simple but surprisingly powerful method for this kind of differential equations.

But if there are not any people in Squad who have experience in programming of physical simulations, it would be quite hard to implement one. Probably therefore they have refused even thinking it. If it is made wrong way it can lead to lag and annoying errors. I would be very interested to see real physics in KSP but I understand that it is not a thing which increase selling of the game.

[Geschosskopf]

Because KSP is a computer game, not real life, it is not limited simply to a choice between Kepplerian and Newtonian physics. In a game, it's the OUTPUT that matters, not how the output was generated. And this is a good thing because from the perspectives of both game design and gameplay, n-body gravity is so undesirable that the having no Lagrange points is a small sacrifice to make in keeping things simpler and more playable. But because this is a game, there might be a way to retain the existing gravity system and still have Lagrange points.

First, a clarification. L3, L4, and L5 are already perfectly useable in the game as-is. Thus, any bemoaning the absence of Lagrange points concerns only L1 and L2 which, sadly, not only are the most useful ones but also the only ones that need n-body gravity in real life.

But it seems to me that some industrious modder could create useable L1 and L2 points without needing n-body physics. It's all about the OUTPUT and that output is to have a ship remain in place at points that meets the geometrical specifications of where L1 and L2 are. Not being a modder or knowing any of the inner workings of KSP, I have no idea how to do this but can at least sketch out an idea. It could well be impossible but it hopefully will inspire others to something that might work. So here goes:

The mod creates an invisible, massless, non-clipping rigid strut between the centers of Body A and Body B. Along this strut, at the distances needed for L1 and L2, you have areas that work like docking ports. If a ship enters this area within a small range of velocities, it "docks" to the area. So now the ship is attached to the strut between the bodies and stays there, always in line with the bodies and always at the same distance from them. Of course, it would also be nice if you had some icon on the "docking" area so you could select it as a target. Then it would just be a question of rendezvousing and matching speeds with it, and voila!

Anyway, my 2 cents on the subject.

[arq]

A few thoughts:

Does KSP use floats instead of doubles? Really? Or was that just your simulation. Floats are almost never used because computationally they are almost equivalent to doubles (general-purpose computers are built to work in doubles) so the only thing they save you is 50% memory, which is only a problem if you're tracking millions of numbers (in for KSP orbits it's hundreds or maybe thousands). Many beginning programmers haven't even heard of floats, only doubles.

Orbital physics are handled separately from part physics. The orbital physics just use the motion of the CoM (which is why orbits get jumpy when transferring to the outer planets, the CoM jiggles a little when normal physics are running). This would have very little impact on parts physics.

What the OP is proposing is not n-body physics. Really it's just 1 body moving through a complex environment (it does not affect the environment). However, since even the heaviest 5000 part ship is still a dot next to Gilly, these 1-body physics are an approximation that would take contrived scenarios to even observe a difference.

All of this said, I believe it would be possible to use these 'almost-Newtonian' orbits instead of patched conics. However, I am still not convinced that this would contribute meaningfully to the game. The only big plus would be Lagrange points (though I'm not convinced that would be more than a brief novelty). Then there would be the obnoxious bits like Mun pulling down your LKO ships.

[Evrion]

hmm, "reply with quote" is failing me at the moment.

"First, a clarification. L3, L4, and L5 are already perfectly useable in the game as-is. Thus, any bemoaning the absence of Lagrange points concerns only L1 and L2 which, sadly, not only are the most useful ones but also the only ones that need n-body gravity in real life.?

- Geschosskopf

I don't think this is correct. All Lagrange points depend on n-body interactions. Lagrange points in general are points in space where it is theoretically possible to orbit a central body in exact time with a secondary body. L3, the point exactly opposite the secondary body is kinda worthless in general for spacecraft so I don't mind ignoring it.

L4 and L5 are very interesting ones in that they are stable points of orbit. Or, more plainly, if you miss them by a bit, you will tend to be pulled back into them. This is why Jupiter has Trojan asteroids at it's L4 and L5 points. In KSP these points are not stable in the same way. In KSP you can orbit at those points, or ANY other point on the orbit of the secondary object so long as your orbit matches the secondary object.

In KSP, if you want to use L4 or L5 of, say Kerbin around the sun, then you must exactly match Kerbin's orbit. It is actually not necessary to get the right position on the orbit, just the orbital shape right. If you miss by a little, then you will eventually drift away.

In real life if you want to use L4 or L5 of the Earth, than you must get an orbit that is very close to the Earth's around the sun and be very close to L4 or L5 and you will then be captured by the Lagrange point and stay there. Kind of like being captured by planets now in KSP. This means missing by a little is okay.

TLDR:

Yes you can orbit at the theoretical L4 or L5, but they don't work right.

[Mattasmack]

I haven't had the time to read everything you wrote up there, actually, I'm not really in the mental state to do so (extremely tired tbh), so I went diagonals and I think I got what you meant. If you imply that what you want by switching to Newtonian based calculations of physics is to get orbital perturbation from moons/other outside sources on high orbits, I'm aafraid this wouldn't work so well. I'm highly doubting this could really work given the limitations of KSP. As soon as you calculate a trajectory by taking in account multiple bodies at the same time, you get into the realm of n-body physics. KSP is currently struggling with Keplerian orbits. The main problem is that the biggest thread on the CPU, the physics calculations, can't be split across multiple cores. That's what causing so much lag to everyone when you get a lot of parts in the physics load distance. Orbits are calculated taking account only one body to try to minimize this thread. The more bodies you get, the more calculations you have to do. Being around Jool would likely be hellish if you took account of every moon on high orbits.

Like I said, I haven't fully read, I'll give it a better look when I'm rested and probably read through the article, but from what I'm understanding now, I'm not so sure that this would play nice for our CPUs. I could be wrong though.

I won't respond to all you wrote (since, as you said, you hadn't fully read the post before responding), but I do want to comment on your statement that because the physics calculations in KSP are so costly, something else couldn't be added to the game. The part-to-part physics calculations certainly are costly; on my laptop the game is pretty much always chugging and using all the resources it can, either due to rendering or the physics calculations depending on the situation. But if what you say is the true state of affairs, that nothing else can be added because what is already there is so costly, it's a pretty lousy state of affairs. Either the developers really do need to drop everything else and do optimization (as posters occasionally complain about on the forum), or else expansion of the game is done. But I think your statement is incorrect, as evidenced by the popularity of mods that do add a moderate amount of additional calculation to the game (FAR, ISA Mapsat, MechJeb, etc.).

First, good article, I was wondering many of this myself. I had a couple thoughts on reading it, from my experience in doing numerical integration.

1. With regards to integration schemes, given how smooth planetary orbits are, you could probably use a much higher order integration scheme. The RK45 that you used is good, I remember using a 7th/8th order Runga-Kutta method that I liked too. Or if you wanted to be super serious, you could use ODEPACK, a standard numerical library for solving ODEs. I remember being impressed on the speed gain I would get using ODEPACK compared with a simpler Runga-Kutta. Whether it is worth the programing time is another question.

2. As for not being able to find stable Lagrangian Points, I would want to see more simulation results, but I would guess that the numerical errors from your integration scheme are causing them to loose stability. Runga-Kutta methods do not conserve energy, so for physical systems where that is important (like planetary dynamics), they will introduce errors in the long term. These effects are often worst around stable points. There exist integration schemes that do preserve energy, but these are generally much more complex. Other possibilities are that perturbations from Minimus are causing you problems, or possibly that you have a bug somewhere (which I'm sure isn't the case, after all, my programs _never_ have bugs, why would anybody else's? :-))

p.s. This is the first time I've posted here!

Welcome!

1. Yeah, I thought of trying even higher order schemes -- I know Fehlberg published RK schemes up to 8th order back in the 60's, and I believe Dormand and Prince have an embedded 8th order scheme as well -- but after the 5th order scheme programmer fatigue set in! If I were actually implementing this approach those schemes, and ODEPACK, are things I would definitely look at. For the present, I just wanted to find out if the approach I had in mind would work or not, and the 5th order scheme I used was good enough I think.

2. Oh yes, there are certainly bugs! And that might be why the L-points didn't behave as expected. But I know that, by leaving the planets and moons in their Keplerian orbits, they are not moving as they "should" (i.e., Kerbin and Kerbol should be mutually orbiting their barycenter, but in KSP Kerbol is stationary), and I know that that also upsets the balance of forces that create the L-points to some extent. This is something I might look at more if I have time.

I do think the notion of energy conservation is a red herring though. In the approach I've described here, with planets moving on fixed trajectories, the total energy in the system is not conserved! A vessel can take a gravitational slingshot around a planet and gain energy, and the planet doesn't lose any. Even in a true n-body simulation of the whole solar system, the difference in mass between Kerbol and the planets and spacecraft is so great that I think conserving energy of the system would be very difficult, to no significant gain that I can see.

[Geschosskopf]

Yes you can orbit at the theoretical L4 or L5, but they don't work right.

What do you mean, "they don't work right"? Remember, this is a computer program, not real life, so "working right" is defined in terms of output: the ship doing the expected thing for the player. How the game derives this output doesn't matter at all, so doesn't even have to be close to the real world situation.

So, with the game the way it is right now, you can figure out where the L3, L4, and L5 points are. You can then fly ships there and they will sit there forever. Thus, these Lagrange points "work" in terms of what the player sees without needing to change the underlying game mechanics. Of course, this ignores the fact that with the current system, EVERY point on a planet's orbit is stable the same way for the same underlying reasons, so you don't actually have to go to L3, L4, or L5 to get a stable point in the orbit; anywhere will do. But so what? If you're the type of player who actually cares about using these points, you'll expend just as much effort flying to these specific points whether or not there's anything special about them.

And here's the question... Suppose something along the lines I suggested would actually work to fake L1 and L2. To the player, the results are the same as if n-body gravity was in effect, or at least close enough. If you get the desired output from it, what difference does it make if what's producing that result is real-world math or some hackjob with no basis at all in reality? And if it works for L1 and L2, no doubt it could be extended to work for L3, L4, and L5, although as mentioned that's not necessary. But would you feel better having something like this for those points rather than what we have now?

[Mattasmack]

As I see your idea:

1) Keep current model when no other astronomical bodies are close enough to matter much

2) Use a numerical integration model when multiple astronomical bodies have "significant" affect. (Significant here would have to be interpreted by the programmer)

I would LOVE if KSP would implement n-body physics! I REALLY want to use Lagrange points!

Mostly. It would make fewer orbits stable. It would increase calculations needed with many craft in space. And I suspect that this is the reason SQUAD went with the current model; all craft no the current focus can simply be placed at the appropriate places along their very well known orbits, no real calculations needed, ever.

I hope somebody can figure out a way to implement this and actually test it within the context of this game. As stupid_chris pointed out, physics is the biggest calculation in game right now (mostly part to part calculations though) so I imagine any physics added to the game would have potential issues to deal with. But, it seem like it just might work!

edit:

Thinking about this more, using Newtonian trajectories would increase orbital motion complexity (in a good way in my book!). This would increase the draw for the hardcore physics audience, but decrease the draw for a general audience as it would be harder to fully understand. It would also increase computational demand, even if only a little. Overall, this would decrease the total audience for the game. So I think it is unlikely that SQUAD would want to do this

Yeah, that's essentially it. I do agree that the danger in making any change for the sake of realism is that it makes the game less approachable. But I think this hybrid system in which Keplerian orbits are retained inside a small SOI (which would still be shown in map view when crossing its boundary) mitigates it almost entirely. For example, I would envision the SOI for Kerbin having a limit somewhere in the range 4000 - 7000 km. That's high enough that vessels in low Kerbin orbit and even synchronous orbit would be inside the SOI and so would be perfectly stable. And the trajectories for vessels going through no-man's-land would still be displayed in map view, so although the paths would be more complex, they would still be predictable -- the player will always know where his or her vessel will end up.

A few thoughts:

Does KSP use floats instead of doubles? Really? Or was that just your simulation. Floats are almost never used because computationally they are almost equivalent to doubles (general-purpose computers are built to work in doubles) so the only thing they save you is 50% memory, which is only a problem if you're tracking millions of numbers (in for KSP orbits it's hundreds or maybe thousands). Many beginning programmers haven't even heard of floats, only doubles.

Orbital physics are handled separately from part physics. The orbital physics just use the motion of the CoM (which is why orbits get jumpy when transferring to the outer planets, the CoM jiggles a little when normal physics are running). This would have very little impact on parts physics.

What the OP is proposing is not n-body physics. Really it's just 1 body moving through a complex environment (it does not affect the environment). However, since even the heaviest 5000 part ship is still a dot next to Gilly, these 1-body physics are an approximation that would take contrived scenarios to even observe a difference.

All of this said, I believe it would be possible to use these 'almost-Newtonian' orbits instead of patched conics. However, I am still not convinced that this would contribute meaningfully to the game. The only big plus would be Lagrange points (though I'm not convinced that would be more than a brief novelty). Then there would be the obnoxious bits like Mun pulling down your LKO ships.

On floats vs. doubles: I don't know what is used in KSP currently. I think there might be a limitation in Unity so that part-to-part calculations are done with floats. (Which kind of makes sense, if they're using an engine meant to be useable on GPUs too, since most of their computing power is single-precision.) I assume (I hope!) they use doubles for all trajectories already. I only used doubles in my own simulations.

On n-body physics: That's an important point, and something I perhaps should have emphasized more. I have not looked at n-body simulations at all; I just looked at letting vessels be influenced by gravity from multiple bodies at once. But the vessels don't influence the motion of the planetary bodies (thus breaking Newton's third law, but the ratio of masses between vessel and planet is so large it doesn't matter), and the vessels don't influence each other gravitationally. That means each vessel's trajectory can still be calculated completely independently of the others.

On your last point: my notion of keeping a small SOI around each body in which Kepler's laws still apply is meant to mitigate that problem (and see my earlier comments in this post). Although, when I did some longer-term simulations of a vessel in LKO, I found that the influence of Mun was limited -- the orbit changed shape, but at least over a moderate amount of time the vessel wasn't pushed continually lower or higher such that it would eventually be lost. The question of whether making a change like this would be worth the trouble is, I think, the key one. I believe it is possible within the framework of KSP without hurting the gameplay. But is there a big enough benefit? I don't know the question could be answered without trying it in the game (which none of us are in a position to do), or at least putting some trajectories calculated using both methods in side-by-side comparisons (which I haven't yet done).

[Gojira]

I like this idea. I read the whole post and the rest after.

Theoretically this would make every celestial body's SoI infinite, right?

And yes, iirc KSP uses floats instead of doubles.

Also, what would happen with the trajectory predictions? Would they still be patched conics or would they be more fluid?

Edited September 8, 2013 by Gojira

[Brotoro]

Evrion is correct, Geschosskoph. The L4 and L5 points in KSP do not work like the real ones (they do not have the same effect). Sure, you would stay in the same place relative to the secondary body in KSP if your ship was EXACTLY at the L5 point (or any point EXACTLY on the secondary body's orbit...which is unrealistic), but with a real L4 or L5 point, there is a large volume of space around that point where a ship will end up moving around the Lagrange point and not drift away. This does NOT happen in KSP. If you are even the tiniest bit off from the L4 or L5 points, your ship will drift away over time. So those points DO NOT act like real Lagrange points, hence "they do not work."

[Mattasmack]

I like this idea. I read the whole post and the rest after.

Theoretically this would make every celestial body's SoI infinite, right?

Yes, at least in the simplest application you would just calculate the position of every planetary body and its associated gravitational force on a vessel at each time step. But they could be cut down if more performance is needed. For example, if the distance from a planet is above some limit, don't bother looking at its moons, or if the distance from Kerbol is large enough, don't bother calculating the locations of the inner planets. (Note that finding the location of a body from it's Kepler orbital elements is more costly than calculating the gravitational force once you have the location. So the significant speed-up comes from avoiding calculating the body's location in the first place.)

And yes, iirc KSP uses floats instead of doubles.

Also, what would happen with the trajectory predictions? Would they still be patched conics or would they be more fluid?

The trajectories of all objects can be precalculated (the storage requirements are not too bad) so that they can be displayed in map view without any extra load on the CPU. So although the trajectories would be more complex, an object would still go exactly where the path in map view says it will. (It would be an interesting gameplay mechanic to show patched conics in the map view but calculate the trajectories differently, perhaps justified by the Kerbals not having good computers, but I think it would mostly just be frustrating to the player.) It would probably not be possible to continually update the full length of a trajectory while the vessel is accelerating, but it should take much less than a second to calculate out the full trajectory after acceleration ceases in most cases.

[jebisanaggie]

Excuse my ignorance here, but if you matched your orbit EXACTLY with Kerbin's orbit, wouldn't you also have zero relative velocity, in effect making L4 and L5 span the entirety of Kerbin's orbit?

[Geschosskopf]

Evrion is correct, Geschosskoph. The L4 and L5 points in KSP do not work like the real ones (they do not have the same effect). Sure, you would stay in the same place relative to the secondary body in KSP if your ship was EXACTLY at the L5 point (or any point EXACTLY on the secondary body's orbit...which is unrealistic), but with a real L4 or L5 point, there is a large volume of space around that point where a ship will end up moving around the Lagrange point and not drift away. This does NOT happen in KSP. If you are even the tiniest bit off from the L4 or L5 points, your ship will drift away over time. So those points DO NOT act like real Lagrange points, hence "they do not work."

OK, so you want ships to orbit around the L3/L4/L5 points instead of having to sit exactly on them. Then make a mod that creates that condition. I doubt this would work for L1/L2 without the sort of rigid structure I proposed above but it would probably work at the other points. Just put a "singularity" at the L3/L4/L5 points. That is, something undetectable apart from its gravity to create an SOI in the desired area. Problem solved.

[Kerbart]

Excuse my ignorance here, but if you matched your orbit EXACTLY with Kerbin's orbit, wouldn't you also have zero relative velocity, in effect making L4 and L5 span the entirety of Kerbin's orbit?

Well yes, keyword being exactly.

The nice things about Lagrange points is that they're stable, so if you're off a little bit (within limits) the orbit will correct itself, instead of your craft drifting off further and further over time. And unless you match Kerbin orbit exactly, you will drift off.

[Evrion]

OK, so you want ships to orbit around the L3/L4/L5 points instead of having to sit exactly on them. Then make a mod that creates that condition. I doubt this would work for L1/L2 without the sort of rigid structure I proposed above but it would probably work at the other points. Just put a "singularity" at the L3/L4/L5 points. That is, something undetectable apart from its gravity to create an SOI in the desired area. Problem solved.

L4 and L5 are the only stable Lagrange points. They have the nifty feature that if you wander around them a bit, they pull you back. It's not really an orbit because those points themselves move as the secondary body moves.

If they worked right, then things like this could be done:

http://en.wikipedia.org/wiki/Interplanetary_Transport_Network

If they work by some sort of vague simulation like you suggest than all you can do is stay there, which is not really much different from the current situation. An orbit could be done, but Lagrange "orbits" aren't the same as a regular orbit. There are even some cool things like the "Horseshoe orbit" that become possible if they are more properly simulated.

I understand that it's all in terms of output. A good simulation would allow for all the fun things that can be done with Lagrange points IRL (Look them up!), and quick and dirty approach (a very Kerbal one?) would not really allow for much new and really not be worthwhile.

[arq]

Really you just need to match your orbital period to follow Kerbin. You'd need to use RCS (or better yet an ion engine) to tune it, but it can be done. Probably to within minutes per orbit, if not better.