[WIP] Newtonian Orbital Mechanics plugin (maybe?)

[roady1990]

I'm not too sure it isn't that important, since the greater accuracy of such methods could potentially also allow you to use greater step-sizes. And thereby make the computation more efficient.

Though obviously... I do not really know how much it will or will not matter.

Regardless,

I think I remember reading a paper some time ago, that allowed stepsizes of some 50days for simulating jupiters orbit along milions of years with good accuracy.

I'll try to find it.

Hmm... seems like it was a multistep method, which complicates matters when you want timewarping. (and would make it need another method to initialise values after changing anything)

In any case here it is: http://adsabs.harvard.edu/cgi-bin/bib_query?1990AJ....100.1694Q If nothing else, it's interesting reading matter.

Also I think the reason the keplerian orbits do not display the L4 and 5 points is because the the major objects don't revolve around the barycenters. (eg the mun revolves around kerbal which is in its own orbit, but kerbal doesn't orbit around the centre of mass of the mun/kerbal system)

I'd expect L1 trough 3 to be more tolerant of this inaccuracy, but well... they're unstable.

Edited November 23, 2013 by roady1990

[Camacha]

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.

I am not sure. Let's not forget that mods seem to be able to use more than one core on a system. If I could suddenly use my 4 cores instead of barely a single one, a lot more is possible. Implement some tricks to reduce the continuous load and you are getting somewhere.

[Mattasmack]

I'm not too sure it isn't that important, since the greater accuracy of such methods could potentially also allow you to use greater step-sizes. And thereby make the computation more efficient.

Though obviously... I do not really know how much it will or will not matter.

Regardless,

I think I remember reading a paper some time ago, that allowed stepsizes of some 50days for simulating jupiters orbit along milions of years with good accuracy.

I'll try to find it.

Hmm... seems like it was a multistep method, which complicates matters when you want timewarping. (and would make it need another method to initialise values after changing anything)

In any case here it is: http://adsabs.harvard.edu/cgi-bin/bib_query?1990AJ....100.1694Q If nothing else, it's interesting reading matter.

...

Thanks for the link to the article, it is indeed an interesting read. You're right that it being a multistep method rules it out for this application, I think. Since we can't know ahead of time what paths players will put vessels on, it is important to use a method that can adapt its time step to maintain stability and a specified error limit. (Such a method can also calculate orbits with high eccentricity much more efficiently than fixed time step methods.) The moderate-order RK method I've been looking at also has the property that an interpolating function for position can easily be calculated of the same order as the RK method itself. That's valuable for use in the game because it makes it much cheaper computationally to find locations like AP, PE, ascending and decending nodes, etc., and to find each vessel's location frame-by-frame without having to do integration steps each frame. (Which is the sort of consideration that usually doesn't come up for pure simulations.)

... Also I think the reason the keplerian orbits do not display the L4 and 5 points is because the the major objects don't revolve around the barycenters. (eg the mun revolves around kerbal which is in its own orbit, but kerbal doesn't orbit around the centre of mass of the mun/kerbal system)

I'd expect L1 trough 3 to be more tolerant of this inaccuracy, but well... they're unstable.

Exactly. I did one quick simulation with Kerbol and Kerbin following Kepler orbits around their barycenter, and in that case an object placed at the L4 point hardly drifted away at all. (It still drifted slightly -- a few tens of meters over a few years -- probably because I didn't keep enough sig. figs when entering the orbital parameters for the two bodies.) But I did that simulation mostly for my peace of mind, to ensure that the reason the L-points weren't working wasn't that I had screwed something up in my code. Once the rest of the bodies in the Kerbol system are added in, that can't be done any more.

I am not sure. Let's not forget that mods seem to be able to use more than one core on a system. If I could suddenly use my 4 cores instead of barely a single one, a lot more is possible. Implement some tricks to reduce the continuous load and you are getting somewhere.

If I do manage to implement these orbits I'd be perfectly happy to abstract away stationkeeping, at least at first. E.g., press a button to turn on 'stationkeeping', and it just moves the vessel back onto a Keplerian orbit. The costs could be abstracted as well, just remove fuel at a fixed rate (dependent on the orbit, the vessel's size, etc.) as long as stationkeeping is enabled.

[Cheaterman]

I used to support such threads, but nowadays I'm more like "okay put L1 and L2 [for each body that needs it] as invisible SOIs": you get in there using Hohmann, do a capture burn, and voilà.