A potential way to solve the N-body problem.

[Eric S]

I don't think we'd need a full N-body implementation anyway. Just increasing the number of gravitational sources from one to two would be sufficient to give us Lagrange points, and that's the main thing we're really likely to notice, right?

You're not as likely to notice Lagrange points as you think you are. Lagrange points in reality are more stable orbits precisely because of the issues that N-Body physics bring to having stable orbits. So what's really being said is "We want N-body physics so we can get Lagrange points to solve the problems of N-body physics." Even with the EML4/EML5 "stable" Lagrange points, you're talking orbits that are stable only for millions of years, instead of orbits that are stable forever that you get in KSP.

Of the five L-points in any given pair of bodies, three are inherently unstable in one axis, and the other two (and one of the first three) are in a position barely distinguishable from placing something in the same orbit as the smaller of the bodies farther ahead or behind in a patched conics system, unless the two bodies are closer in size than normal (Duna/Ike, for example), at which point the Lagrange points would be even less stable.

Even the two stable points aren't as trivially accessible as you'd expect. We've found all of one asteroid caught in the SEL4/SEL5 points to date. Dust in space isn't any more common in EML4/EML5 than elsewhere, so getting captured there isn't trivial either.

Of the two L-points that can't be approximated easily in a patched conics system, the main use for them is for solar observations in the case of SEL1, and stellar observations for SEL2. SEL1 makes for a nice place for solar observations because the earth never occludes the sun there and it's far enough from the earth to minimize interference from earth without being so far away to make communication difficult. SEL2 is used for stellar observations because the earth permanently occludes the sun, reducing the interference of said sun when trying to see dim items very far away. On the other hand, because the points are unstable in a full N-body system, most missions that go there are of a duration of a few years at most due to the instability of those L-points meaning that they need to do frequent station keeping. The Halo orbits people talk about using in the unstable Sun/Earth or Sun/Kerbin L-points aren't really a stable orbit, just the orbit that required the fewest course corrections.

One other thing we'd get with N-body physics would be the Interplanetary Transport Network. As nice as it would be to have, I think that this wouldn't be remotely accessible to the majority of KSP players.

None of this even considers the fact that N-body physics for more than three bodies doesn't work "on rails" (in fact, it only works for three bodies if the orbit of the middle body is circular) but just as physics warp, which would break large amounts of KSP.

TLDR: N-body physics, or even simplified 3/4 body physics, would eliminate anything really being "on rails" for a reward that the majority of KSP players would find difficult to take advantage of. Yes, the geek side of me wants Lagrange points, but the realist says that we don't need them, we really are saying "We want N-body physics so we can get Lagrange points to solve the problems of N-body physics."

[AngelLestat]

two main questions that nobody is asking is:

what we want?

and...

how can we get it?

We want lagrange points... so.. the other things does not matter.

We need real simulation of orbits between planets? NO. Any solar system who has life is enought stable to avoid any planet collision in a range of 4000 millons years. So fixed elliptic orbits is fine (or how you called on-rails).

But if if want lagrange points we need to calculate n-body physsics for all planets? NO. Only for the craft having into account the 2 gravitational body positions. That is it!

besides, all lagrange points are fixed points between 2 objects. So why not make zones in game that in case your craft is in the desired point with the desired vector speed, then you enter in a stable fixed orbit in the lagrange point.

And no calculations are needed.

this is how you delimit and solve programming problems.

Edited November 5, 2013 by AngelLestat

[Eric S]

besides, all lagrange points are fixed points between 2 objects. So why not make zones in game that in case your craft is in the desired point with the desired vector speed, then you enter in a stable fixed orbit in the lagrange point.

Aside from the dirty feeling of a "magic" solution, you've got some unintended consequences going on if anyone wants to try to dock with this craft that is now not following the physics of the game. They can be in normal physics, which means that they are going to diverge from the target's trajectory, or they're locked into the magic orbit, which means that they can't maneuver to dock with the target.

[boomerdog2000]

besides, all lagrange points are fixed points between 2 objects. So why not make zones in game that in case your craft is in the desired point with the desired vector speed, then you enter in a stable fixed orbit in the lagrange point.

And no calculations are needed.

This also presents the issue of if you land on said lagrange point since now it has a gravity field. Unless you're suggesting just 1 fixed orbit that is the only one you could have around the lagrange point. If that's the case I disagree because that seems very railroady and not in the spirit or physics of the game.

[AngelLestat]

Eric S and boomerdog2000.

The fixed orbit works in time warp mode only..

And when you are out of time warp you use n-body physsics that only had into account the craft, not the planets.

Doing this you can have stable lagrange points where you can place your sattelites or crafts.

This is the only way, becouse we dont have computers to mantain a perfect orbit like our real satellites do.

And we can not make so much calculation in timewarp mode if we had more than 20 crafts in different orbits.

So yes.. they need to be fixed orbits.

And we keep the realism of the game. it does not matter how we accomplish that.

[Kasuha]

The fixed orbit works in time warp mode only..

And when you are out of time warp you use n-body physsics that only had into account the craft, not the planets.

Doing this you can have stable lagrange points where you can place your sattelites or crafts.

There is no way this could work. In "stable orbits" mode there are no lagrange points so your ships would slip out. I understand it works in your imagination but sorry, there's no way it could be made to work in reality.

And lagrange points are way less fun than you think, too.

[Eric S]

This is the only way, becouse we dont have computers to mantain a perfect orbit like our real satellites do.

We have this now. Because we don't have N-body physics and no atmospheric drag above 70km, orbits don't drift or decay. You're thinking of Lagrange points as the solution to a problem we don't have. Park a satellite 60 degrees ahead/behind the Mun in an orbit that matches the Mun including the orbital period, and it will stay there until the end of time, which is more than you can say for something dropped into EML4 or EML5 in reality.

I'll admit that exactly matching the Mun's orbital period could be easier, but even if you're off by 10 seconds, it would take 6 years for the satellite to drift back into the Mun's SoI. If you were asking for a way to do very precise burns so that you could more easily match the desired orbital period, I'd agree and endorse the goal.

To be honest, I don't think the Kerbin-Mun Lagrange points would be stable enough to use, since there's Minmus adding to the mix. Then again, without running it in a simulator, I can't say for certain that Minmus would interfere enough.

As for this only working in time-warp (I think you mean on rails, which isn't exactly the same thing), I find that even more bothersome.

[AngelLestat]

There is no way this could work. In "stable orbits" mode there are no lagrange points so your ships would slip out. I understand it works in your imagination but sorry, there's no way it could be made to work in reality.

If you speak of my imagination like the way to think, simul and solve things, then your are right.. It works in my imagination, but I can understand if does not work in yours. Try to critic using facts and logic next time.

We have this now. Because we don't have N-body physics and no atmospheric drag above 70km, orbits don't drift or decay. You're thinking of Lagrange points as the solution to a problem we don't have. Park a satellite 60 degrees ahead/behind the Mun in an orbit that matches the Mun including the orbital period, and it will stay there until the end of time, which is more than you can say for something dropped into EML4 or EML5 in reality.

On the other hand you made a very good point explaning why it will be pointless in mostly all cases implement lagrange point using this system.

[mdosogne]

It's been said before, but it seems worth repeating...

We want:

- 1000000x time warp without a supercomputer

- more realistic orbital mechanics

We don't need N-body physics, because:

1. Ships have no significant gravitational influence on each other (or anything but the attention of players and the kraken).

2. The planets should be left on rails to prevent the kerbol system from disintegrating, and because there is nothing in the game capable of displacing their orbits.

3. The current single-SOI simplification of physics means that orbital calculations are simple and smooth when close to a body (i.e. within 10% of the current SOI radius).

In-between celestial bodies (at elevations over 10% the current SOI radius), there is room for significant improvement by applying the sum of the gravitational influences on a ship imparted by the celestial bodies within ~10 times their current spheres of influence (NOT N-body orbital physics). I believe the formula is simple enough to sum the forces of 10 celestial bodies (more than what's needed for the Kerbol system) applied to 100+ ships without significantly influencing CPU usage, especially since a 1-second calculation interval is plenty when you're in high enough orbit for this physics model to kick in (see #3).

That can be done with much less computational power, and the processing required scales as a function of the (number of ships+debris) * (time warp). At higher orbits (where higher time warps can be used) the physics time step can be increased without significant detrimental effect.

Station-keeping (i.e. keeping an orbit stable) could be a feature handled by any ship with power + RCS + an advanced electronics module. This could periodically drain RCS fuel from inactive ships, requiring resupply missions for space stations, etc. That means you can't ignore a ship in orbit for 10 years, but that adds to the challenge and gameplay!

[KvickFlygarn87]

It's been said before, but it seems worth repeating...

We want:

- 1000000x time warp without a supercomputer

- more realistic orbital mechanics

We don't need N-body physics, because:

1. Ships have no significant gravitational influence on each other (or anything but the attention of players and the kraken).

2. The planets should be left on rails to prevent the kerbol system from disintegrating, and because there is nothing in the game capable of displacing their orbits.

3. The current single-SOI simplification of physics means that orbital calculations are simple and smooth when close to a body (i.e. within 10% of the current SOI radius).

In-between celestial bodies (at elevations over 10% the current SOI radius), there is room for significant improvement by applying the sum of the gravitational influences on a ship imparted by the celestial bodies within ~10 times their current spheres of influence (NOT N-body orbital physics). I believe the formula is simple enough to sum the forces of 10 celestial bodies (more than what's needed for the Kerbol system) applied to 100+ ships without significantly influencing CPU usage, especially since a 1-second calculation interval is plenty when you're in high enough orbit for this physics model to kick in (see #3).

That can be done with much less computational power, and the processing required scales as a function of the (number of ships+debris) * (time warp). At higher orbits (where higher time warps can be used) the physics time step can be increased without significant detrimental effect.

Station-keeping (i.e. keeping an orbit stable) could be a feature handled by any ship with power + RCS + an advanced electronics module. This could periodically drain RCS fuel from inactive ships, requiring resupply missions for space stations, etc. That means you can't ignore a ship in orbit for 10 years, but that adds to the challenge and gameplay!

Clap, clap, clap! You solved this in a brilliant and awesome way! Kudos to you, good sir!

[frizzank]

The main thing I keep hearing from this is that people want lagrange points. You don't need complex calculations or N-body physics to have them. Just put gravity wells at fixed points around the planets and moons and it is completely possible in the current system. You would want to put some kind of marker in the map view otherwise you would inadvertently hit one and through off your orbit.

[vexx32]

Eeeh, it's possible that way, but if you read up on lagrange points, they act markedly different to a simple gravity well. From memory, only one or two of them are even actually stable, and which ones are stable depends entirely on the arrangement of other planets and moons.

[Kasuha]

The only two stable lagrangian points are L4 and L5 (trojan points in case of Jupiter) L1 to L3 need orbit keeping to hold a probe in there.

http://en.wikipedia.org/wiki/Lagrangian_point#Stability

[Kegereneku]

All this really only matter if we want actual Lagrange Point -which require N-body math- or if we accept simplification for the sake of Gameplay.

Some earlier post here said (and proved) that KSP's Celestial Bodies wouldn't be stable on the long run if their orbit were actually calculated.

Any solution the Developers come with will certainly keep satisfying the following point :

- Eternally Stable Orbit (as the devs said nothing wrong must happen unless it's provoked by the player)

- Enough Time-Warp to go anywhere of importance

- No needless calculations which doesn't serve the game.

Would N-body orbit really be worth it ? I don't know.

For the eternal question of Lagrange point...

If we go with gameplay-oriented simplification/cheat, I know at least two unintended consequence with the idea of "fake gravity well" acting as Lagrange point.

- It give a misleading idea of what they are, but you could just call them "Kergrange Point" or something.

- They will systematically interfere with any trajectory passing trough their SOI and for multiple-moon Jovian System it would certainly pose problem. But you are not forced to put "Kergrange point" at place it would be unstable anyway.

[mdosogne]

I for one, don't want lagrange points if they're modeled as a 'gravity well' extension of patched conics, because:

1. Taking a look at the gravity field around a lagrange point, you'll notice that it's not at all round like that of a planet, so modeling it as a zero-radius planet/moon with its own gravity is not at all realistic

2. You would need a negative gravity well for L1, L2, L3, which just sounds like an invitation for the Kraken.

3. It would mean yet another SOI change and its associated discontinuity in your flight plan, which is one of the things that bugs me most about patched conics: instead of displaying my flight plan relative to the currently focused object, it abruptly changes at the SOI boundary.

The SOI boundary greatly complicates planning small adjustments to my insertion vector prior to entering the SOI (for me, it's mostly a guessing game; I try one direction, check projected periapsis, and try another direction). Far from the SOI is where a small burn would have a great effect on my approach, where I want to use my fuel. Instead of guessing, I find myself waiting to enter the SOI, and then spending as much as 3km/sec correcting the orbit to not completely miss the encounter. Had I been able to plan the maneuver at 50 times the SOI radius, that would have been maybe a 30m/sec burn, allowing me to aerobrake or gravity assist at 5km periapsis. Changing to a polar orbit around the Mun, I find myself accidentally escaping its SOI before getting the altitude necessary to shift from equatorial to polar orbits with less than 300m/sec burn.

That is my reason for wanting new orbital mechanics; lagrange points are a bonus. Maybe there's other ways of correcting this SOI boundary problem other than using N-body or similar approximations - for example plotting the projected orbit based on the currently focused object instead of the SOIs it enters/exits. Maybe I'm asking too much...

[Superfluous J]

3. It would mean yet another SOI change and its associated discontinuity in your flight plan, which is one of the things that bugs me most about patched conics: instead of displaying my flight plan relative to the currently focused object, it abruptly changes at the SOI boundary.

I wholeheartedly suggest you try conic mode 3, and up your conic patch limit. I have mine set at 8 and am considering going higher. There does not seem to be any performance hit. 3 is just too low once you're leaving Kirbin.

The SOI boundary greatly complicates planning small adjustments to my insertion vector prior to entering the SOI (for me, it's mostly a guessing game; I try one direction, check projected periapsis, and try another direction). Far from the SOI is where a small burn would have a great effect on my approach, where I want to use my fuel. Instead of guessing, I find myself waiting to enter the SOI, and then spending as much as 3km/sec correcting the orbit to not completely miss the encounter. Had I been able to plan the maneuver at 50 times the SOI radius, that would have been maybe a 30m/sec burn, allowing me to aerobrake or gravity assist at 5km periapsis. Changing to a polar orbit around the Mun, I find myself accidentally escaping its SOI before getting the altitude necessary to shift from equatorial to polar orbits with less than 300m/sec burn.

Are you opposed to mods? If not, you should really look into PreciseNode. That, along with a higher conic patch limit, makes planning those tiny maneuvers a lot easier. It also lets you swap between conic modes which is GREAT. As a bonus, you can up your conic patch limit in the game if you find that you're one or two low (or high, though I've never found this to be a problem) and see EXACTLY what your maneuver is going to do for you. Assuming you can execute it of course

[NeilC]

It's been said before, but it seems worth repeating...

<...>

there is room for significant improvement by applying the sum of the gravitational influences on a ship imparted by the celestial bodies within ~10 times their current spheres of influence (NOT N-body orbital physics). I believe the formula is simple enough to sum the forces of 10 celestial bodies (more than what's needed for the Kerbol system) applied to 100+ ships without significantly influencing CPU usage, especially since a 1-second calculation interval is plenty when you're in high enough orbit for this physics model to kick in (see #3).

<...>

Minor point:

If you do this, timewarp may break. To get the position of a craft at the tesired time, you are no longer changing the "time" input variable in a linear 1D patched conic equation, instead you must simulate the entire orbit from present up to the desired time. Let's assume you're right that 1 second is a decent physical timestep for that problem. Now go to 100,000x timewarp. Can you do this calculation for all craft in existence in 1/100,000th of a second?

You might argue that yes, you can. On decently modern hardware, you might be right.

MAJOR POINT:

If you do this, maneuver nodes will definitely break. Instead of calculating the sim on an ongoing basis, scaled by timewarp, maneuver nodes require that you calculate the entire new orbit at a refresh rate high enough to allow dragging the handles. Can you simulate an entire 1.5 year trip to Jool, with a timestep small enough to ensure stability of the calculation, at 30Hz? Even on a massively overclocked i7?

The answer is no. Emphatically, NO.

The devs have taken multiple-gravity calculations off the table, and are sticking with patched conics. This discussion has been had over and over again and always comes to the same place. The first 2 or 3 times I've been a part of it, I was also arguing for some Lagrangian implementation - because cool, right? But you know what's also really, really cool? Maneuver nodes.

The gameplay tradeoffs for N-body aren't worth it. Patched conics are a better solution for KSP.

[Kasuha]

MAJOR POINT:

If you do this, maneuver nodes will definitely break. Instead of calculating the sim on an ongoing basis, scaled by timewarp, maneuver nodes require that you calculate the entire new orbit at a refresh rate high enough to allow dragging the handles. Can you simulate an entire 1.5 year trip to Jool, with a timestep small enough to ensure stability of the calculation, at 30Hz? Even on a massively overclocked i7?

The answer is no. Emphatically, NO.

The answer is YES, if you're smart.

Most of that trip is spent in interplanetary space where gravitational potential is smooth. You can calculate that with way higher time step than close encounters. If you know what you are doing, you can do it.

Plus, even if that projected trajectory has some minor errors, you can just cache it and drag the ship along it if it doesn't accelerate. It would become new kind of rails for the ship, applicable until changed.

No, I don't see technical problems with this. I see other problems. And I think getting Lagrangian points is not worth facing these other problems. Current implementation is simple, easy to understand, easy to handle. It is good implementation. Even with that, most players are sticking to equatorial orbits because inclination adds too much of chaos to their handling. There is no need to make it even more complicated.

Edited November 7, 2013 by Kasuha

[NeilC]

The answer is YES, if you're smart.

I'd love to see it done! You mentioned you had some previous experience with these calcs. Care to put your compiler where your mouth is? Please, be smart!

My gut says that any adaptive-timestep method is going to waste a significant portion of its 1/30th of a second just calculating dt_next for a few hundred timesteps.

Besides, what if you want to gravity assist around Duna on your way to Jool? Or do any other post-encounter orbit prediction? You can't use large timesteps in deep gravity wells.

Any time you go from a closed-form solution to an iterative simulation, you have introduced a huge technical problem that must be overcome. Leaving the orders-of-magnitude lower performance out of it, you suddenly have to deal with numerical precision, solution stability, repeatability.... it's not a simple system anymore. You can hand-wave that away if you'd like, but until I see an experiment to back up the idea that maneuver nodes could be implemented using a simulation-based orbital solver I will remain highly skeptical.

[sjwt]

And this brings us to the end of this discussion. Squads stance is no 3 Body physics will be introduced, nor will any part implementation be on the table. Unfortunately due to the nature of these discussion they allways degenrate sooner or later, and hence why its on the no to suggest list.