Possible Lagrangian points to be used?

[Rizz]

Hello, KSP community!

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

I wasn't sure if these physics were already incorporated into the game, hence why I'm not placing this in the challenges section of the forums. BUT, I was wondering if it was possible to securely occupy or even orbit a Lagrangian point?

Here's my basic understanding of what Lagrangian points are(, for those who don't want to read the wall of text that is the wiki article in the link above). Lagrangian points are specific spots involving two body's of mass in which you can remain stationary in from your point of reference.

http://upload.wikimedia.org/wikipedia/commons/e/ee/Lagrange_points2.svg

Occupying any of these green dots within the plane that they orbit should, in fact, provide a stationary position relative to both of those bodies (given that you have the correct lateral velocity to orbit the larger of the two bodies). This is simply due to the fact that the gravity from both bodies cancels out any would-be changes to your orbit, thus making it stationary.

HARD MODE:

It IS possible to orbit a Lagrangian point. Occupying the point would be cake in comparison, considering that the plane of an ideal orbit of a Lagrangian point doesn't even contain the point itself. Because the gravitational pull of the larger body outweighs the other, it will have more of an influence on you than the smaller one the farther you are from the L-Point. In effect, the space in which you could orbit a Lagrangian point is in the shape of a bowl; the bottom of which being the Lagrangian point itself and the surface of that bowl spreading out from there towards the larger body occupying the space in which an orbit is achievable. If my attempt to make an accurate visualization on where you can do this failed, perhaps this article would suffice:

http://www.scilogs.eu/en/blog/go-for-launch/2009-05-28/how-to-orbit-a-lagrangian-point

So, Kerbals... can it be done?

[mrxak]

I believe only L4 and L5 can be faked, but the physical model used by KSP doesn't allow true Lagrangian points.

Edited August 15, 2012 by mrxak

[Rizz]

Yeah, I was afraid of that. I remembered the orbits in the maps from space only take into account gravity coming from one mass at a single time. But still, if they could implement this feature in a future version of the game, that would be amazing. It would be one helluva challenge to achieve, even with mods.

[Tigga]

I'm hoping for better craft/body interaction as well. I can't think of any technical reason why it shouldn't be possible, though it's going to be more computationally expensive to plot trajectories and calculate reference point changes, though I'd expect it to be fine as these changes only have to be calculated for one craft, and this simplifies things greatly. Keeping large bodies on rails would be fine.

[vexx32]

It is possible, but the system is unable to handle it without glaring inaccuracies. It could have been modelled with n-body physics, but it requires complex integration, which becomes exponentially more complex the more bodies you're taking into account. Most computers these days could not take the extra CPU load (which would be significant).

[bsalis]

I think people only really care about L1 and L2. They can probably be done as special case SOIs, but I don't see it happening.

[Neomatt]

I can't think of any technical reason why it shouldn't be possible.

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

Okay, if planets/moons stay on rails, it becomes more of a "how different bodies interact with one ship", so the problem is kinda moot. But I'm not sure how CPU-intensive planning a trajectory (with all bodies having different attraction at different points in time) could be.

[illectro]

Let me be clear, there is no real scientific problem with incorporating an N-Body version of the on-rails system, the CPU power required is easily supplied by a regular desktop CPU. I ran simulations of the kerbin system using an accurate, but relatively inefficient, 4th Order Runge-Kutta integrator - my simulation calculated at at rate of 30 days per second, that's 2-3 million times clock speed. It would do better to replace it with a symplectic integrator, which is more or less uses patched conics with perturbations applied, this would be faster still.

Here's an example showing how minmus orbit wobbles due to the influence of Kerbol

If the plugin system ever supports replacing the on-rails calculation you can be sure I'll be in there making a proper calculator and making videos about low energy transfers using the interplanetary superhighway

[samstarman5]

Lagrange points have already been covered and answered by the development team on this forum. They can not be implemented with the current set up, and changing the set up to allow them would break too many other things. They are not going to happen.

[rkman]

Here's an example showing how minmus orbit wobbles due to the influence of Kerbol

That's... interesting.

If the plugin system ever supports replacing the on-rails calculation you can be sure I'll be in there making a proper calculator and making videos about low energy transfers using the interplanetary superhighway

You have my blessing and i'd be among the first to at least try it, but i think it would be quite a feat to run dozens craft on 'n-body rails' in fast-foreward without running into problems with accuracy/repeatability.

[Tigga]

Okay, if planets/moons stay on rails, it becomes more of a "how different bodies interact with one ship", so the problem is kinda moot. But I'm not sure how CPU-intensive planning a trajectory (with all bodies having different attraction at different points in time) could be.

It's not really if you can determine the positions of the attractors as a function of the time, which you can if they're on rails. You could even make some further simplifications, neglecting masses if they're insignificant, which most of them are likely to be, and if you get down to one mass being significant you can go on rails again.

[vexx32]

Wouldn't work -- there are far too many objects in the Kerbal universe even currently for this to work easily. You'd have to play without timewarp because of the glaring inaccuracies it would otherwise produce, assuming you're correct in your explanation.

I suggest you look up how an n-body physics simulation is calculated, because gravity work in 3 dimensions, and getting a solution for multiple bodies is ridiculously complex, involving (as I said before) complex integration, which is exponentially more complex the more bodies you want to take into account. I agree you could simplify it somewhat, but that's not easily possible without introducing inconsistencies.

Seeing as we're getting further planets in 0.17, I suggest that unless you yourself can work out a method of calculating a n-body solution easily and accurately, there's no point discussing it. Even the patched conics system took HarvesteR a while to get his head around. Using the inbuilt n-body mechanics of PhysX (the physics engine) would force the team to remove timewarp completely, and it would still be rather complex. An alternate solution would have to be worked out, a new way to do it. At least, last time this was discussed, that's what I remember of Harv's conclusive answer.

[Tigga]

I suggest you look up how an n-body physics simulation is calculated, because gravity work in 3 dimensions, and getting a solution for multiple bodies is ridiculously complex, involving (as I said before) complex integration, which is exponentially more complex the more bodies you want to take into account. I agree you could simplify it somewhat, but that's not easily possible without introducing inconsistencies.

It's not a n-body simulation that's being proposed though. N-body is bad because it scales with n squared (every body interacting with every other body). Splitting your bodies into planetary on-rails bodies (attract stuff, don't get attracted) and ship "real" bodies (don't attract stuff, get attracted) and it now scales with n. Calculate the sum of the forces on a body (won't be more than 10 objects realistically, especially if you make approximations ignoring insignificant objects, and the maths is trivial) and apply them to the body. All this stuff is going to be trivial to compute.

The tricky bit is the time integration for projected trajectories. Most of the time your insignificant object sweep will pretty much give you one object, and you'll be on cubic rails, however when you're not forward stepping in time is potentially intensive. It's pretty hard to judge how much so until you've actually done it. I've little doubt it'd be possible for "free" motion, but having something that updates as you thrust would be a bit trickier. You'd probably have to deal with a low quality projection while thrusting, which might not be ideal. It's the sort of thing I'd feel I'd have to implement to discover.

[illectro]

I suggest you look up how an n-body physics simulation is calculated, because gravity work in 3 dimensions, and getting a solution for multiple bodies is ridiculously complex, involving (as I said before) complex integration, which is exponentially more complex the more bodies you want to take into account. I agree you could simplify it somewhat, but that's not easily possible without introducing inconsistencies.

I suggest you ask someone who wrote N-Body integration code professionally and actually knows the limits of what's possible. Please stop perpetuating the myth that there is some fundamental computational problem that is beyond the capabilities of todays computers, I've written simulations using 'toy' algorithms that are millions of times faster than real time and more accurate than the existing patched conics. There is no fundamental problem except a lack of time on the developers part, there are many more intersting things for them to devote their efforts to.

[vexx32]

Well, last I heard, the answer was "it's not possible at this time", and that was not to do with time constraints. I apologise if there was a misunderstanding, but I wasn't intending to say it is beyond today's computers (although I realise it was poorly typed and I should not have tried to be all science-y late at night... it ends badly, a lot of the time). Anyway. From memory, I believe the reason it could not be done was due to the fact that for KSP to remain an entertaining game, the time-warp functionality must remain, and thus n-body physics could not be used, as it is extremely difficult if not impossible to calculate n-body physics at such a high rate of time warp without some sort of simplification resulting in errors in calculation that would make it pointless to be trying to be so accurate in the first place.

But hey, I'm not the one working on it, and I'd prefer to get an official statement on this (sigh, again) as to why it cannot be done at this point in time. Harv said something about it a while back, before the forum conversion, and I cannot for the life of me find it anymore.

[thesandbar]

Simple (in my book): Extend all present spheres of influences. Whatever's in >1 sphere will have n-body but only for the spheres it's in. It will seem realistic but it won't be =D

[Cykyrios]

You know, Kerbin's SoI is already inside Kerbol's (otherwise, it wouldn't orbit it). So extending SoI wouldn't help at all, since it would mean you can orbit Kerbin at altitudes where you should be orbiting Kerbol.

And n-body aren't used because the patched conics allow for an instantaneous display of your trajectory with one simple calculation, while an n-body simulation would require to simulate an orbit very fast (and thus with less precision) with several thousands of steps.