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

[magister94]

The way i currently understand the game(correct me of I\'m wrong), is that only one body of mass influences the ship at a given moment. I would love to see both kerban and the mun have influence on my orbit at the same time.

[Millitron]

This has been discussed dozens of times, and I feel I should warn you that quite a lot of people are tired of repeating this discussion over and over again, and will probably have snarkier responses than mine.

At any rate, what you\'re basically asking for is a solution to the N-body problem, which is unfeasible if you also want to have the orbital map and time compression. It isn\'t that it can\'t be done, just that it would require reworking the vast majority of the game, and the only things it would change would be allowing Lagrange points. The current system, called the patched conics approximation, is more than adequate for our needs. It\'s so accurate, that\'s what NASA used to get to the Moon in real life.

So, basically its a ton of work for very little reward, along with opening up the possibilities for tons of new bugs.

[GeneralIssue]

Beyond that, a lot of people who clamor for L points don\'t realize that they are pseudo-stable, and given the relative inaccuracy of Kerb ships and instruments (stock, of course Mechjeb changes things a bit), actually entering and maintaining station in a N-body modeled Lagrange point would take a degree of pilot/autopilot control that simply isn\'t possible in our little 1/6th scale universe filled with over-eager green dudes.

[FourTee2]

Wait, isn\'t it 1/10?

[GeneralIssue]

Er... yeah, it is. My bad. :-X

[RC1062]

Just in case people come to complain about this being mentioned before; The search function is currently not working.

[Sean Mirrsen]

...and the only things it would change would be allowing Lagrange points.

I keep getting mildly annoyed at this particular notion in these discussions. While I agree that rewriting the orbital code at this stage would be prohibitively difficult (should\'ve done it while it was feasible), everyone seems to suddenly forget that the N-body solution does a whole lot more than just add L-points. It allows you to have, for instance, orbits that make sense. It allows you to plot a course between several bodies without compensating for drift you cannot see or SOI switches you cannot adequately account for. It allows you to overshoot the Mun without getting stuck in the Sun\'s SOI with no gravity of Mun or Kerbin to actually get you back. These simple important things are the ones being expected of the simulated orbits, not L-point silliness.

The current system, called the patched conics approximation, is more than adequate for our needs. It\'s so accurate, that\'s what NASA used to get to the Moon in real life.

Indeed. See, patched conics can be made to work well in simple situations. They\'re plain math, not physics, easily solvable by the most primitive of calculators, which the trajectory computers of the Moon mission essentially were. Now, the crappiest korean-made cellphone has more processing power than those computers. We can afford a little more complexity. Patched conics are a neat, but ultimately clunky solution. Do you remember how many problems were had with this pure-math approach? SOI stutter, reversing orbits, orbits that cause ships to suddenly jump thousands of miles due to a periapsis point miscalculation, problems with SOI-switching debris in persistence, probably more that I cannot remember. With propagated orbits, the worst we would have to deal with would likely be accuracy jitter, orbit display versus flight time shenanigans and timewarp optimization, because there are no arbitrary points in the simulated orbit to break at. Squad just went for a solution that was simpler to implement at the time, which is very understandable, but so far it\'s the only thing undermining an otherwise near-perfect game of LEGO rocket science.

[semininja]

Patched conics have another advantage over an n-body system in that n-body orbits are almost always unstable, while orbits in the current simulation are only affected by one SOI, and are therefore not pulled into instability every time they pass the Mun.

[RC1062]

Patched conics have another advantage over an n-body system in that n-body orbits are almost always unstable, while orbits in the current simulation are only affected by one SOI, and are therefore not pulled into instability every time they pass the Mun.

Which would be awesome! Of course if it ever was implemented I suppose there could be an option to turn it off...

But it wouldn\'t happen for years...

[FourTee2]

...and are therefore not pulled into instability every time they pass the Mun.

I take it this 'instability' is the Mun affecting the orbit in a realistic manner?

[semininja]

I take it this 'instability' is the Mun affecting the orbit in a realistic manner?

It is, but it makes for a very difficult game for many new players, because they will have problems trying to stay in an orbit.

[Kryten]

Yes, but this instability is hard to compute in advance, leading to problems when timewarping. I\'ve you\'ve played orbiter, which does have an n-body simulation, you\'ll know what kind of effects it can have; if you leave something in low earth orbit, and turn on the highest warp, it ends up leaving the solar system at multiple times light speed...

[Sean Mirrsen]

Patched conics have another advantage over an n-body system in that n-body orbits are almost always unstable, while orbits in the current simulation are only affected by one SOI, and are therefore not pulled into instability every time they pass the Mun.

One person\'s disadvantage is another person\'s fun. What\'s the fun in perfectly stable orbits that never change? It would add a great management layer to the game if you would have to make sure that all your long-term orbital constructions are capable of adjusting their orbits. You\'d add solar panels, autopilot and ion thrusters (or something of the kind), the game would simulate the capabilities of the craft for manuevering, and then whenever it\'s in orbit and its autopilot is active, it\'d 'simulate' the craft returning to its planned orbit, or simply counteracting the gravity of whatever tries to pull it away. You\'d be able to remotely command the satellites to shift orbits without having to pilot them manually or even so much as loading them into a scene, because all they\'d be is a parametrized dot on the map. Hell, you\'d be able to have deep space missions with constantly firing thrusters as well. With just patched conics, you\'re unlikely to be able to do something of this sort, because a packed ship on rails is just an equation that cannot change dynamically.

[FourTee2]

One person\'s disadvantage is another person\'s fun. What\'s the fun in perfectly stable orbits that never change? It would add a great management layer to the game if you would have to make sure that all your long-term orbital constructions are capable of adjusting their orbits. You\'d add solar panels, autopilot and ion thrusters (or something of the kind), the game would simulate the capabilities of the craft for manuevering, and then whenever it\'s in orbit and its autopilot is active, it\'d 'simulate' the craft returning to its planned orbit, or simply counteracting the gravity of whatever tries to pull it away. You\'d be able to remotely command the satellites to shift orbits without having to pilot them manually or even so much as loading them into a scene, because all they\'d be is a parametrized dot on the map. Hell, you\'d be able to have deep space missions with constantly firing thrusters as well. With just patched conics, you\'re unlikely to be able to do something of this sort, because a packed ship on rails is just an equation that cannot change dynamically.

I agree wholeheartedly! But Couldn\'t one (read: the devs) simply turn off physics at ridiculously high warps? There are certainly situations in which an N-body simulation would be beneficial, but I would assume that people warping at ludicrous speed aren\'t really looking for an accurate simulation...

[Millitron]

I keep getting mildly annoyed at this particular notion in these discussions. While I agree that rewriting the orbital code at this stage would be prohibitively difficult (should\'ve done it while it was feasible), everyone seems to suddenly forget that the N-body solution does a whole lot more than just add L-points. It allows you to have, for instance, orbits that make sense. It allows you to plot a course between several bodies without compensating for drift you cannot see or SOI switches you cannot adequately account for. It allows you to overshoot the Mun without getting stuck in the Sun\'s SOI with no gravity of Mun or Kerbin to actually get you back. These simple important things are the ones being expected of the simulated orbits, not L-point silliness.

Indeed. See, patched conics can be made to work well in simple situations. They\'re plain math, not physics, easily solvable by the most primitive of calculators, which the trajectory computers of the Moon mission essentially were. Now, the crappiest korean-made cellphone has more processing power than those computers. We can afford a little more complexity. Patched conics are a neat, but ultimately clunky solution. Do you remember how many problems were had with this pure-math approach? SOI stutter, reversing orbits, orbits that cause ships to suddenly jump thousands of miles due to a periapsis point miscalculation, problems with SOI-switching debris in persistence, probably more that I cannot remember. With propagated orbits, the worst we would have to deal with would likely be accuracy jitter, orbit display versus flight time shenanigans and timewarp optimization, because there are no arbitrary points in the simulated orbit to break at. Squad just went for a solution that was simpler to implement at the time, which is very understandable, but so far it\'s the only thing undermining an otherwise near-perfect game of LEGO rocket science.

You can overshoot the moon and not get stuck in a solar orbit right now. The only times you get stuck, are when you accidentally get a gravity-assist from the moon as you fly by, and end up over kerbin\'s escape velocity, which is realistic. This is so common because a typical TMI burn gets you pretty close to Kerbin-Escape Velocity, and not much more is needed from the moon to tip you over the edge.

Accounting for drift and plotting trajectories involving multiple bodies is planned, thats actually the 'patched' part of patched conics. It\'s patching the individual conics together. It just hasn\'t been implemented yet because it\'s a little complicated, and there\'s bigger fish to fry right now, i.e. docking. Since you can do it by eye well enough right now, it isn\'t too high on the list of things to do, but it hasn\'t been forgotten.

Plus, how do you handle the physics calculations for dozens of vessels at 10,000x timewarp? That seems extremely computationally expensive.

As for orbital perturbations by the moon, I would suspect that if it was really desired by players, the devs could fake it somehow.

[giucam]

I don\'t see why time warping would be a problem with an N-body system. I mean, i\'ve been doing a little 2D simulator (before finding out kerbal ) with N-body physics and i can warp without problems. (the actual physics engine isn\'t mine, http://www.ifa.hawaii.edu/faculty/barnes/treecode/treeguide.html).

If the elapsed time since the last frame is, say, 50ms, at 1x i advance the engine for those 50ms. If i want a speed of 2x i advance it for 100ms, 10x 500ms. Obviously computing more time requires more cpu time, so if i warp to 1000x the actual speed will be maybe 900x, but i don\'t think that\'s a problem. What matters is that the accuracy of the physics doesn\'t change with the warp speed, because the engine internally advances with steps of few ms.

EDIT: now that i think about it i was wrong: the engine warp speed is not affected by the cpu time it takes, even if it is 100000000x. If the cpu is not fast enough it will just have fewer fps.

[RC1062]

But the number of computations probably increase exponentially per plane...

[socket7]

http://en.wikipedia.org/wiki/N-body_problem

If you can accurately solve the N-Body problem for over 2 bodies you\'d win yourself a Nobel prize.

[Millitron]

I don\'t see why time warping would be a problem with an N-body system. I mean, i\'ve been doing a little 2D simulator (before finding out kerbal ) with N-body physics and i can warp without problems. (the actual physics engine isn\'t mine, http://www.ifa.hawaii.edu/faculty/barnes/treecode/treeguide.html).

If the elapsed time since the last frame is, say, 50ms, at 1x i advance the engine for those 50ms. If i want a speed of 2x i advance it for 100ms, 10x 500ms. Obviously computing more time requires more cpu time, so if i warp to 1000x the actual speed will be maybe 900x, but i don\'t think that\'s a problem. What matters is that the accuracy of the physics doesn\'t change with the warp speed, because the engine internally advances with steps of few ms.

Well, the issue isn\'t with time-warping with a single ship, its with time-warping with 100 'vessels'. Since the physics have to be calculated from the scene origin, and distant vessels are very far from the scene origin, you hit huge inaccuracies due to poor floating-point math. This would be a problem even without timewarp if we\'re talking an N-body solution, because the patched conics approximation skirts physics completely. If you include timewarping though, the inaccuracies become absolutely ridiculous, leaving vessels (or worse yet, parts of vessels) dozens of kilometers away from where they should be.

Even if a way around the Must-Be-Near-Scene-Origin problem can be found, it will be extremely computationally complex for any world with more than a few vessels.

http://en.wikipedia.org/wiki/N-body_problem

If you can accurately solve the N-Body problem for over 2 bodies you\'d win yourself a Nobel prize.

We aren\'t talking about a solution, we\'re talking about an approximation, which isn\'t all that hard.

If Harv can actually solve it though, he totally should. 8)

[giucam]

@RC1062

Actually the engine internally is 3D, i just live on the z=0 plane.

@millitron

I don\'t know really well how the engine i\'m using works internally, but afaik it handles big distances pretty well.

I\'ve being simulated the Earth with the Moon around the Sun in a 1:1 scale and warping up to 20x and an year keeps taking 365 days.

EDIT: i forgot, 1 sec is 1 day in my simulation.

[socket7]

We aren\'t talking about a solution, we\'re talking about an approximation, which isn\'t all that hard.

I\'d argue that patched conics ARE an approximation.

Keep in mind we don\'t eve have patched conics yet. we just have conics, which is why orbits look so screwy when changing SOI. 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.

[RC1062]

How the heck would an orbit be displayed? Orbits would have to go around different bodies but you\'d need to know where the body would be...

Wow...

[giucam]

I didn\'t talk about orbits, i don\'t know. I was just saying that time warping isn\'t a problem.

I\'ll think about it anyway.

[Sean Mirrsen]

http://en.wikipedia.org/wiki/N-body_problem

If you can accurately solve the N-Body problem for over 2 bodies you\'d win yourself a Nobel prize.

The N-Body Problem is only a problem in a pure math environment. I.e. the solution to the problem is an equation one can use to predict the position of a given object within a system of given interacting objects at a given point in time. In a physics environment, the only problem is running the simulation fast enough, and since you only have a finite (and very limited) number of acting bodies, as opposed to reacting bodies (planets can be kept on rails for all we care, we\'re not going to deorbit them anyway), and bodies are never both active and reactive, the amount of needed calculations is very much reduced.

I really think that Squad needs to at least try. They did pull off the PQS, after all. Can\'t they assign someone to testing the applicability of a numeric integrator system for orbits in KSP? Even if just as a support feature for those deep space constant-thrust missions? No time detracted from actual developing of the game, and potential for a great (and maybe optional) feature.

[socket7]

I really think that Squad needs to at least try. They did pull off the PQS, after all. Can\'t they assign someone to testing the applicability of a numeric integrator system for orbits in KSP? Even if just as a support feature for those deep space constant-thrust missions? No time detracted from actual developing of the game, and potential for a great (and maybe optional) feature.

Squad is not EA. They cannot just 'assign someone' to examine complex physics problems without taking someone off developing the game itself. Attempting to make N-body work the way they want would require taking time away from the development of the game.

Secondly, you are assuming that Squad has not already looked at the N-body problem. I assure you, HarvesteR is well aware of the N-body problems, its potential solutions, it\'s pro\'s and it\'s cons. We have this discussion once a month or so. Squad tried, and they decided that patched conics would work better for what they wanted to do with the game.

I love discussion about the N-body problem, but please don\'t say Squad hasn\'t tried or needs to put more people on it.

Cheers 8)