LaGrange Points

[PeriapsisPrograde]

Now that we have a Mun, why not go for something besides landing on it?

The challenge is simple. Get to as many LaGrange points in the Kerbin/Mun system as possible. Bonus points if you can visit all five with one stack.

Only stock parts may be used. Good luck!

[SteevyT]

Because of the way gravity is simulated, Lagrange Points don\'t actually exist in the game. You could get to where they should be, but it wouldn\'t do much good.

[Stevenator1]

Theoretically cant you get very VERy close to theM? you should be able to get to a point right where your kerbal orbit changes into a solar orbit, and kill off all of your velocity. That would be as close as you can get to actually hitting the point, but you will never be completely still. I shall working on hitting the point between the earth and the sun tonight!

[Letum]

Because of the way gravity is simulated, Lagrange Points don\'t actually exist in the game. You could get to where they should be, but it wouldn\'t do much good.

What makes you think this?

[SteevyT]

Because it had to be done that way to allow the time warp to work. It\'s buried somewhere in the development section if you want to find the discussion about it.

[Millitron]

What makes you think this?

KSP simulates gravity using the patched conics approximation. The one big downside of the patched conics approximation is that it can\'t add up forces for more than two bodies. Since lagrange points require 3 bodies (in this case Kerbin, moon, and ship), there are no lagrange points in the game.

[RedRockets]

Great questions!! Have wondered about this myself.

[Stevenator1]

Wait just a minute.... So your gravity is never calculated between the sun, kerbal, and your ship? Though that is an easy and minimal lag way of simulating gravity, I think that a way needs to be developed to allow gravitational computation to be done between 3 bodies.

[Millitron]

Wait just a minute.... So your gravity is never calculated between the sun, kerbal, and your ship? Though that is an easy and minimal lag way of simulating gravity, I think that a way needs to be developed to allow gravitational computation to be done between 3 bodies.

No, your gravity is only ever calculated between your ship and the most influential celestial body. This is what allows the map, and by extension, timewarp to work. If physics was still calculated constantly, you could never timewarp, because that would need an insane amount of calculations per second. I mean, at 1000x timewarp, 1 second equates to about twenty minutes. Thats 20 minutes worth of calculations that must be crammed into 1 second. With patched conics, you can predict the path ahead of time, and then there\'s no physics calculations involved, which drastically simplifies the computations, and makes it doable, even at 10,000x.

The only realism that gets lost is LaGrange points, which I have a sneaking suspicion could be faked with some cleaver trickery.

[trbinsc]

Also, it\'s a engine limitation, PhysX can\'t handle multiple bodies. If Harv could do it, he would.

[Ivan Ivanovich]

The only realism that gets lost is LaGrange points, which I have a sneaking suspicion could be faked with some cleaver trickery.

Ahhh... no. There\'s more than that lost, e.g. going out of Kerbals influence into Kerbols influence, it\'s fairly easy to get stranded in an orbit around Kerbol because even if you get close enough toe Kerbal to be influenced by it (and at least slingshot out of the system due to it), you remain in a Kerbol orbit.

Same applies between Mun and Kerbal.

[Technical Ben]

KSP simulates gravity using the patched conics approximation. The one big downside of the patched conics approximation is that it can\'t add up forces for more than two bodies. Since lagrange points require 3 bodies (in this case Kerbin, moon, and ship), there are no lagrange points in the game.

From what I\'ve heard, it\'s always difficult to calculate more than 1 body of gravity. Games or for real maths. So that\'s why you hardly ever see it.

[Millitron]

Ahhh... no. There\'s more than that lost, e.g. going out of Kerbals influence into Kerbols influence, it\'s fairly easy to get stranded in an orbit around Kerbol because even if you get close enough toe Kerbal to be influenced by it (and at least slingshot out of the system due to it), you remain in a Kerbol orbit.

Same applies between Mun and Kerbal.

No. You can still slingshot fine. Think of it this way. When you are slingshotting around Kerbin, the force of gravity applied on your ship by Kerbin is several orders of magnitude more than the FoG applied on your ship by the sun. Essentially, the force applied by the sun is negligible compared to the force applied by Kerbin. If you get stranded in the game, you would\'ve gotten stranded in real life had the same situation occurred. Reaching stellar escape velocity is NOT an easy thing. Voyager 1 and 2 managed it by sling-shotting around Jupiter and Saturn, which due to their immense size, provided a much greater delta V than a sling-shot around, say, Mars would have.

From what I\'ve heard, it\'s always difficult to calculate more than 1 body of gravity. Games or for real maths. So that\'s why you hardly ever see it.

It is. In fact, there simply is no good solution for anything more than the 3 body problem. If you\'re dealing with more than 3 bodies, you have to make use of any simplifying assumptions you can, and even then your solution will just be approximate.

Orbiter solves the N-body problem using the integration approach. This lets Orbiter have 3 bodies for its gravity calculations, i.e. (Sun, Kerbin, and ship). The problem with this is, even on 1x timewarp, the calculations are much more complex than in KSP, and they just get worse and worse the more you timewarp. Orbiter is notoriously buggy at high timewarps, and its because the calculations for the increasingly complex integrations are less and less accurate the faster you timewarp.

[Technical Ben]

Does using a mesh for gravity (AKA an aether, or an actual time/space type 3d wieghted mesh) solve the problem?

[Millitron]

Does using a mesh for gravity (AKA an aether, or an actual time/space type 3d wieghted mesh) solve the problem?

No, because each point in the aether would be calculated by adding up all the forces from the celestial bodies, and it would have to be calculated at every physics step. So you still have the same problem, you just pushed it back a little. Instead of having the problem when applying the forces to the ship, you have it when you first calculate them, since you\'d need to recalculate every point in the mesh at every physics step.

[Bobsama]

Is there any way that the gravity calculation could become modular? That way, thread 1 calculates Kearth\'s gravity influence, thread 2 calculates the Mun\'s, thread 3 calculates the Sun\'s, and thread 4 puts it all together? I\'m just curious. Or if there\'s a cheap & scalable way to estimate it.

[SteevyT]

Is there any way that the gravity calculation could become modular? That way, thread 1 calculates Kearth\'s gravity influence, thread 2 calculates the Mun\'s, thread 3 calculates the Sun\'s, and thread 4 puts it all together? I\'m just curious. Or if there\'s a cheap & scalable way to estimate it.

Unfortunately, there is no way to scale it. You either make simplifying assumptions so you can use simple, stable equations (KSP\'s route), or you us processor heavy integration techniques that could become buggy when you go into a reasonable warp for a Mun transfer (Orbiter\'s route).

[Millitron]

Is there any way that the gravity calculation could become modular? That way, thread 1 calculates Kearth\'s gravity influence, thread 2 calculates the Mun\'s, thread 3 calculates the Sun\'s, and thread 4 puts it all together? I\'m just curious. Or if there\'s a cheap & scalable way to estimate it.

Maybe? I don\'t know enough about Unity or PhysX to say. I know Harv said that neither work well with multi-threading, but he didn\'t say they CAN\'T use it.

Though that would only improve things by a factor of 4. We\'re talking about timewarping to 10,000x; I don\'t think an improvement of a factor of 4 would make much of a notice-able difference at those scales.

I\'m going to say that I doubt it, but I won\'t rule it out 100%.

[Bobsama]

Maybe? I don\'t know enough about Unity or PhysX to say. I know Harv said that neither work well with multi-threading, but he didn\'t say they CAN\'T use it.

Though that would only improve things by a factor of 4. We\'re talking about timewarping to 10,000x; I don\'t think an improvement of a factor of 4 would make much of a notice-able difference at those scales.

I\'m going to say that I doubt it, but I won\'t rule it out 100%.

Well on time compression, plenty of us did huge missions without it. Another option in the name of accuracy may be to limit the warp based on a processor benchmark tied to a minimum quality standard.

[tofof]

If you get stranded in the game, you would\'ve gotten stranded in real life had the same situation occurred.

To put it shortly: wrong.

To put it not shortly: wrooooooooooooooooooooooooooooooonnnnnnnnnnnnnnnnnnnnnnggggggggggggggggggggg.

Consider the following situation:

You create an elliptical orbit typical of a Mun-shot, with an apoapsis of around 12.5 Mm. (About 1Mm further than it needs to be), aimed such that you will reach your apoapsis at the same time the Mun first crosses the arc of your outbound orbital path.

Convention: Consider a coordinate system in which Kerbin is the origin, the \'spawn\' position of the Mun is on the +x axis, the apoapsis point of the vessel\'s orbit is on +y. In this system, the Mun will move CCW from 0 degree angle toward 90 degree angle.

What should happen:

As the Mun gets closer and closer, its gravity pulls the ship more and more in the +x direction. The (very minor) effect on the y-component of the ship\'s velocity is a small decrease. Kerbin\'s gravity, of course, continually decelerates the ship as projected, such that the ship never reaches a point further than 12.5 Mm from Kerbin. We\'ll assume that the timing is such that the ship ends up on a collision course in the x-direction with the Mun, but it could end up captured or flung hyperbolic, irrelevant.

What happens:

As the Mun gets closer, suddenly Kerbin fails to exert any pull on your ship whatsoever. As this was effectively the only thing slowing your y-component velocity, your ship shoots past the Mun (ahead of it). By the time you\'re out of the Mun\'s SOI (back in Kerbin\'s), you\'re well past 12.5 Mm altitude, and Kerbin\'s gravity is no longer strong enough to capture you. You end up on an escape trajectory from Kerbin and become stranded in Kerbol orbit.

Thought experiment:

Remove Kerbin\'s influence for aproximately 2 Million meters of flight time (10.5 to 12.5 Mm altitude), turn it back on when you reach 12.5 Mm altitude, and now try to claim that everything is still the same, no change to your apoapsis has occurred, no stranding is possible from this effect.

Ahhh... no. There\'s more than that lost, e.g. going out of Kerbals influence into Kerbols influence...

This poster had it very right.

[Millitron]

What happens:

As the Mun gets closer, suddenly Kerbin fails to exert any pull on your ship whatsoever. As this was effectively the only thing slowing your y-component velocity, your ship shoots past the Mun (ahead of it). By the time you\'re out of the Mun\'s SOI (back in Kerbin\'s), you\'re well past 12.5 Mm altitude, and Kerbin\'s gravity is no longer strong enough to capture you. You end up on an escape trajectory from Kerbin and become stranded in Kerbol orbit.

At the distance necessary to enter the Moon\'s SOI, Kerbin\'s pull is much weaker than the moon\'s; its negligible in comparison. Further, the moon\'s effect on the ship\'s Y-velocity is only a slight decrease early in the mission. As the ship gets further from Kerbin, remember the moon is beginning to pull in front of the ship. It is no longer decreasing the Y-velocity, but instead is increasing it significantly. Its perfectly reasonable that you end up on an escape trajectory.

[PeriapsisPrograde]

At the distance necessary to enter the Moon\'s SOI, Kerbin\'s pull is much weaker than the moon\'s; its negligible in comparison. Further, the moon\'s effect on the ship\'s Y-velocity is only a slight decrease early in the mission. As the ship gets further from Kerbin, remember the moon is beginning to pull in front of the ship. It is no longer decreasing the Y-velocity, but instead is increasing it significantly. Its perfectly reasonable that you end up on an escape trajectory.

I feel the need to chip in my two cents here.

The 'slight decrease' and 'negligible' inaccuracies are the problem. As others have said, (This thread has helped my understanding of KSP\'s physics model significantly) KSP only simulates a two-body problem (Ship, barycenter). LaGrange points require a third body (Ship, body 1, body 2) The barycenter of the two bodies causes a 'hole' into which the gravitational pull of the two bodies cancel out, causing you to get stuck in it. Since KSP only simulates one body\'s gravity at a time, it can never cancel out from another body. LaGrange points don\'t exist.

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

http://en.wikipedia.org/wiki/Barycenter#Astronomy

[Millitron]

I feel the need to chip in my two cents here.

The 'slight decrease' and 'negligible' inaccuracies are the problem. As others have said, (This thread has helped my understanding of KSP\'s physics model significantly) KSP only simulates a two-body problem (Ship, barycenter). LaGrange points require a third body (Ship, body 1, body 2) The barycenter of the two bodies causes a 'hole' into which the gravitational pull of the two bodies cancel out, causing you to get stuck in it. Since KSP only simulates one body\'s gravity at a time, it can never cancel out from another body. LaGrange points don\'t exist.

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

http://en.wikipedia.org/wiki/Barycenter#Astronomy

Right, I established that already. I\'ve been arguing that the loss of LaGrange points is the only true noticeable loss of realism in the game.