[WIP] Newtonian Orbital Mechanics plugin (maybe?)

[Mattasmack]

This thread stems from a thread I recently started in the general discussion forum. I believe that in terms of computational effort and numerical accuracy, it should be possible to calculate the trajectories of objects in KSP using Newtonian mechanics rather than Kepler's laws, and do so in a way that doesn't make things harder or more confusing for the average player. Naturally this is not something that the developers would tackle any time soon, and it was suggested that I should try implementing the idea in a mod first to see if it really can be done. So, here I am!

Note that I am not talking about n-body simulations. I want to leave the planetary bodies alone, I just want vessels in space to be subject to gravity from multiple bodies at once. For that matter, as asmi suggested, I'd be happy for starters to just be able to display the Newtonian trajectories in map view.

So, I have already the C++ code I wrote to do my little simulations to test the concept out, and that works reasonably well and is fast. It uses Dormand and Prince's RK5(4)7M scheme with an additional solution at the midpoint of the time step, per Shampine, which is used to calculate a 5th order interpolation function for location. I also added lookup tables for the planetary body locations that speeds the scheme up considerably (since calculating planetary body locations from Kepler orbital elements was the most costly part of the simulations).

What I don't know anything about is modding KSP! I'd appreciate any pointers regarding how to access things like the curves shown in map view, if it is indeed possible at all. Or if someone is interested with helping program the plugin, I'm willing to share my code.

[Superfluous J]

So you're talking that your orbit of each item will be affected by all major bodies in the game? That while I'm orbiting Moho, a teeny tiny little bit of its orbit is affected by Laythe? This could become pretty processor intensive. Imagine having 30 missions and 100 pieces of debris all churning out a couple dozen of these calculations every tick!

You can simplify things, probably greatly, by utilizing the already-present Sphere Of Influence code. If your SOI is Sun, then each planet affects your orbit. Maybe each planet in this case would be the total mass of the planet and all moons, especially for Duna and Ike. Once you're in the SOI of a planet or a moon, Then it and its moons are separated so they affect you singly, but the other planets are still considered point objects. I don't think there's any situation (except maybe approaching Duna or Kerbin, or possibly Jool) where this would cause noticeable errors in the calculations, and you can fix the border cases by making those planets SOI's larger.

I'm excited about this concept. I'd much rather have "true" Newtonian orbits.

[OrbitusII]

Since the Unity Engine (and thus KSP) is written primarily in C#, all you need to do is convert to C# and the Unity syntax.

Here's the script reference to get you started: http://docs.unity3d.com/Documentation/ScriptReference/

The KSP syntax is a little weird, but I wouldn't expect you to need it all that much for something that depends almost entirely on rigidbodies (which are core Unity components). We don't even have that much stuff to go off of, but it's available on the wiki if you need it.

I'd like to see what you can come up with, it was an interesting conversation to say the least.

[Mattasmack]

So you're talking that your orbit of each item will be affected by all major bodies in the game? That while I'm orbiting Moho, a teeny tiny little bit of its orbit is affected by Laythe? This could become pretty processor intensive. Imagine having 30 missions and 100 pieces of debris all churning out a couple dozen of these calculations every tick!

You can simplify things, probably greatly, by utilizing the already-present Sphere Of Influence code. If your SOI is Sun, then each planet affects your orbit. Maybe each planet in this case would be the total mass of the planet and all moons, especially for Duna and Ike. Once you're in the SOI of a planet or a moon, Then it and its moons are separated so they affect you singly, but the other planets are still considered point objects. I don't think there's any situation (except maybe approaching Duna or Kerbin, or possibly Jool) where this would cause noticeable errors in the calculations, and you can fix the border cases by making those planets SOI's larger.

I'm excited about this concept. I'd much rather have "true" Newtonian orbits.

Exactly. Since there are only 17 bodies in the Kerbol system, it's not unreasonable (and is simplest) to have each body influence each vessel all the time (within limitations -- see the original thread for more info, or this very long-winded article on my website for more on my no-man's-land concept for avoiding doing the calculations when in low orbits where they don't really matter). I have tried the simulations, and I can tell you the calculations are not that intensive. It is crucial to use at least a moderate-order integrator that allows long time steps to be taken. That way, for vessels that aren't under acceleration, a calculation only needs to be done every few tens of seconds (if in orbit around a planet) to every few millions of seconds (if in orbit around Kerbol in the outer solar system). The need for more calculations does grow with time warp, and they would need to be done continuously for a vessel that's accelerating.

I have code for the trajectory calculation and interpolation that should be good enough for a proof-of-concept. (Though if it proves promising, higher-order integrators and schemes other than RK should be looked at, and approximations like what you suggest might prove to be necessary.) What I don't know is how to get it into a plugin for KSP, or if the necessary parts of KSP are even accessible to the modder.

[afranius]

Why do you want such large time steps? There are only a few dozen gravity-producing bodies, you can probably do RK3 or something with a small step size and still comfortably run in real time. You might also want to read up on symplectic integrators if you want to preserve energy (you probably do). Having lots of ships in orbit might make things a bit more challenging, but probably not exceedingly so. At worst you might have to run the integrator in a parallel thread.

[Mihara]

I won't pretend to understand much about mathematics involved, but a thought for you: endeavour to do all the computations in a separate process if at all possible.

Then, it will get offloaded to another core, and you will never be hurting for computational resources - almost all of us have several which KSP is not using.

[Mattasmack]

Why do you want such large time steps? There are only a few dozen gravity-producing bodies, you can probably do RK3 or something with a small step size and still comfortably run in real time. You might also want to read up on symplectic integrators if you want to preserve energy (you probably do). Having lots of ships in orbit might make things a bit more challenging, but probably not exceedingly so. At worst you might have to run the integrator in a parallel thread.

Keeping up with real-time is easy, and velocity Verlet would be good enough. But for map view to still work, I need to quickly predict each object's trajectory into the future (and then store that trajectory so that the vessel can follow it). I also need to recalculate the predicted trajectory as quickly as possible so that the player can still see some prediction in map view while his/her vessel is accelerating. And the calculations have to keep up with 100,000x time warp! If any of these don't work, then while the concept might work for simulations, it's a non-starter for KSP the game.

I'm not sure about symplectic integrators. I think I'll have to look at them at some point, although they're not needed for a first cut at the problem. But energy isn't conserved! My plan is to leave the planetary bodies on their current Keplerian trajectories, so a vessel getting a gravitational slingshot around a planet will gain energy without any other object losing it.

I won't pretend to understand much about mathematics involved, but a thought for you: endeavour to do all the computations in a separate process if at all possible.

Then, it will get offloaded to another core, and you will never be hurting for computational resources - almost all of us have several which KSP is not using.

Agreed!

[trepnick]

So for those of us with almost zero understanding of the mathematics involved here and no understanding of the Wikipedia pages for Kepler and newtons laws, what exactly does this improve about KSP gameplay? Will we get gravitational effects like Lagrange points, or would a full n-body model be required for that? Lagrange points are honestly the only improvement I've ever heard of as resulting from a better model, n-body or otherwise...

[Guest]

That's a novel approach, good luck on it. I've once had a similar idea, but instead using Keplerian equations for ships only, with planetary orbits being assumed constans. I also wanted to do more culling of forces that are meaningless in the current situation, for example around Jool, the Mun wouldn't be taken into account. Anyway, the end result should be the same, and your method seems much better than mine.

[asmi]

That's a novel approach, good luck on it. I've once had a similar idea, but instead using Keplerian equations for ships only, with planetary orbits being assumed constans. I also wanted to do more culling of forces that are meaningless in the current situation, for example around Jool, the Mun wouldn't be taken into account. Anyway, the end result should be the same, and your method seems much better than mine.

Keplerian equations is what is used by KSP now (patched conics are based on Keplerian laws).

[KrazyKrl]

Well, the cool thing about n-body, is that not only does it add cool orbital mechanics. But it's more gooder of learning for the people that do play KSP. Sure, at the beginning, people will feel overwhelmed by Lagrange points and orbital weirdness. But then they will learn that ALL bodies exert a force, and you can use gravity assists from them all at the same time. It'll add MUCH more depth to orbital mechanics. And it would enable something like The Interplanetary Transport Network.

Sure, it MIGHT be more complex at points, but it's more realistic; and it adds just so much to the game. Right now the orbits are simple ellipses, and planetary transfers are mundane to say the least.

I don't see more complexity in a game where you need to worry about the aerodynamic profile, thrust to weight ratio, and total delta-v of your vehicle; just to make your vehicle launch to orbit. Then just have an ellipse when you approach a planet. N-body would only really apply when you are doing interplanetary transfers. So until you get to that point in your space program, the extra complexity is not very apparent.

[Blaylock1988]

You might as well include orbital perturbations like the J2, J3 and J4 effects, mainly on kerbin. Station Keeping with a high traffic space around kerbin could become a nightmare with 3rd body effects and J effects without some sort of automated station keeping system. This could become game-breakingly realistic. On the other hand, we could finally get sun-synchronous orbits and Lagrange points!

[Mattasmack]

You might as well include orbital perturbations like the J2, J3 and J4 effects, mainly on kerbin. Station Keeping with a high traffic space around kerbin could become a nightmare with 3rd body effects and J effects without some sort of automated station keeping system. This could become game-breakingly realistic. On the other hand, we could finally get sun-synchronous orbits and Lagrange points!

Yeah, I was kind of disappointed to learn that sun-synchronous orbits depended on the shape of the earth, not the influence of other bodies, because it meant any approach based on point masses wouldn't have them. In the back of my mind I have the idea of replacing the point mass of Kerbin with a small ring of masses (say, 4 - 8 of them) in its equatorial plane to see if that would have the same effect. It's not something I anticipate doing any time soon, though.

[NovaSilisko]

All I can say: GLHF

[Bezzier]

Anything new on this topic?

[BFGfreak]

This might be FAR for space if you can get it to work properly. I wish you luck on your endeavor and hope you don't go crazy in the process.

[Guest]

Was there any progress? And if it died, could we get the code in it's current form? It looked like a very promising mod.

[Cheaterman]

I actually posted a thread myself explaining RK4 and showing the solution to a n-to-1 body physics problem. However the issue here is that you'll need to be able to change the current ("on-rails") trajectory while warping - assuming you can do it, you'd simply need to integrate enough. And to solve the potential CPU performance issues, just consider the bodies in the adjacent system - ie, Duna doesn't affect you in Kerbin's SOI while both Kerbin and Duna would while you're orbiting Kerbol (this is to ignore Jool's Moons most of the time - they would not influence you as long as you're not orbiting Jool itself).

[roady1990]

Wouldn't using Runge-Kutta methods introduce the problem that they're not really energy conserving? and could thus make your orbits smaller or larger after longer periods of time?

[Itsdavyjones]

well this is the first i heard about this, and i wish you luck to get this to work, for this sounds like fun.

[BLUAV8R]

LOVE the idea but this would really mess up my munar sattelite network over long periods of time xD stupid tidal orbit decaying

[Camacha]

I think this decaying things could all be fixed if kOS could be made to run while not in focus too. They got something like that to work for SCANsat and life support, so why not for kOS? That way you could beautifully automate stationkeeping with realistic associated costs.

[Autochton]

I think this decaying things could all be fixed if kOS could be made to run while not in focus too. They got something like that to work for SCANsat and life support, so why not for kOS? That way you could beautifully automate stationkeeping with realistic associated costs.

At the cost of physically simulating every vehicle in the game. You'd need to have propulsion to have station-keeping, and for propulsion you need fuel, electricity, comms if you have RT, simulating the structure of the ship to account for things like shifting centers of mass or other mishaps... It's just not feasible.

What might be possible, though, is to have a sort of passive watcher on it, that alerts you (á la Kerbal Alarm Clock) if a satellite needs station correction. You might set certain parameters its orbit needs to remain within, for example, and have it alert when it deviates from those. Then you can switch to it and correct or not as necessary.

[scorchdestroya]

Will ths make halo orbits possible?

[Mattasmack]

Was there any progress? And if it died, could we get the code in it's current form? It looked like a very promising mod.

Not much progress to speak of, unfortunately. I started learning Unity and plug in development, but after seeing just how many objects are associated with KSP and how little documented they are, I moved this project down several slots on my to-do list. Plus real life has intervened for the past six weeks or so. My wife and I moved last month and my stuff just arrived from storage. The living room and my (eventual) office are full of boxes, and the computer I'd prefer to use for software development is busted. There isn't really any code to speak of to release.

I still hope to go somewhere with this project eventually, but it isn't my top priority at this time.

Wouldn't using Runge-Kutta methods introduce the problem that they're not really energy conserving? and could thus make your orbits smaller or larger after longer periods of time?

Using an inherently energy-conserving method isn't really important, especially since having the planetary bodies follow Keplerian orbits means the whole system doesn't conserve energy in the first place. Plus, I was envisioning using the Newtonian trajectories only at high enough altitudes above each planetary body that they would be used only where an orbit shouldn't be expected to be stable anyway. With a decent integration scheme and reasonable error limit, any numerical drift would be small compared to perturbation of the orbit by other bodies, and therefore not a problem.

Incidentally, I went ahead and did an N-body simulation of the Kerbol system using this RK5(4) method just for fun, and over an error limit range of a few orders of magnitude the results were essentially the same for simulation lengths of 100 years. Over astronomical time periods an inherently energy-conserving method is probably important, but not over the length of a game.

Will ths make halo orbits possible?

Unfortunately no. Having the planets and moons continue to follow Keplerian orbits means the balance of forces that make L-points and halo orbits exist is upset. Or at least, that's what I found in some simple tests back in September. I talked about them a bit more in the thread in the general discussion forum. It's something I'd like to explore further someday.