N- Physics and KSP

[Sathurn]

KSP uses a n=1 physics model, with the planets on rails.

While I fully understand that an n=10 model would grind most computer to a halt. What about n=2? or n=3?

I don't have any idea how demanding n=2 to would be. Or how realistic it would be. Would it be even worse that n=1? How would you decide which body was counted as the second one?

Would it come close to being worth it to the game?

[Themohawkninja]

You know, this thread brings up a good point, because I've played Universe Sandbox where you can collide galaxies with the n value reaching many thousands, and it's not dipping below 5 FPS.

As for KSP, adding N-body physics would just add to a game that can already easily kill your CPU just by the massive ships/stations you can build. While n=2 or n=3 probably isn't that bad on it's own, once your ship get's close to say Duna and Ike, the computer would start running physics calculations for each part on your ship being affected by both bodies, which to me sounds bad for a CPU.

[stupid_chris]

Yeah, you'd need to replace the closed spheres that are the current SOIs by inverted functions, meaning a lot more data that would also somewhat need to be calculated by altitude. Then you have to double the calculations if you want n=2, which would get pretty heavy, especially since KSP can barely access half of what a good computer can throw at him.

Before going to n=2, the gravitational model would need to be reworked and that's already likely to be bad for our already struggling CPUs. So technically it's doable, but not right now for sure and not with how Unity currently works :l

[Sathurn]

What you use this function:

Began frame calculation

Find CoM location

Find force of Gravity for CoM = Temporary Gravity Constant for ship (this frame)

Apply to each part.

end frame calculation.

I realize on really large ships (we still limited to 2km render distance) force of gravity would vary, but is that really worth calculating?

edit

Stupid Chris you must be smarter than me. What is an inverted function? could you give an example?

Edited June 19, 2013 by Sathurn

[Bunsen]

The choice between patched conics (n=1) and multi-body gravitation (n>1) was discussed at length when Kerbin began to acquire moons and neighboring planets. The major factor in the decision was not actually the computational load of in-game physics, but orbit forecasting in the map view.

They didn't have maneuver nodes yet, but they knew they wanted something like that. Think about what would have to happen with n>1 when you drag that maneuver node's delta-v around: At every frame, it would have to propagate your hypothetical orbit through a time-varying multi-body potential with enough accuracy to predict exactly where you'll encounter Eeloo several months later. Doing that sort of calculation at the pace of in-game physics, even at significant time warp, isn't that big a deal. Doing an entire orbit's worth 30 times a second while the crazy user screws around with the planned burn, though, that's hard.

[SolarLiner]

What I always wondered is why can't KSP predict n>1 body orbits with maneuver nodes, while Orbiter's TransX MFD can simulate Voyager's path (with all these slingshots) real-time ? IMFD has even a functional quasi-real-time n-body map window. Does something is wrong with Unity ? Or it is Orbiter that has "accelerated" calculation for orbital physics ?

[Sathurn]

Thank you Bunsen, I see where that would be very cpu heavy. You would literally have to pause the game for like 5-10 seconds for every adjustment of the node.

edit: Solarliner, does Orbiter allow for more than one ship at a time? And if it is a recreation is it using some sort of pre-calculated math?

Edited June 19, 2013 by Sathurn

[Pigbear]

Maybe with Unity4 they could without as much lag

[MBobrik]

There are public domain implementations of numerical solvers that would allow n say 20 and still be capable of doing time warp 1 000 000 on low end hardware at reasonable framerate.

.

And because the gravity ultimately applies only to the CoM ( ships big enough to feel tidal forces can't be built in KSP anyway ), the slowdown would only add to part count caused slowdown, not multiply with it.

.

But the devs have already made up their minds, and, I suspect, that the n=1 approximation is just hardcoded at too many places through the entire code to be changeable, so this is not gonna happen.

Someone with a LOT of free time can still write a mod that patches all the places with calls to the numerical approximator or something like that.

Edited June 19, 2013 by MBobrik

[MBobrik]

The choice between patched conics (n=1) and multi-body gravitation (n>1) was discussed at length when Kerbin began to acquire moons and neighboring planets. The major factor in the decision was not actually the computational load of in-game physics, but orbit forecasting in the map view.

.

If your numerical solver can churn out extrapolation of several thousand orbits per second, this would not be more difficult than computing positions during max time warp. And one could still let the solver run asynchronously or iteratively , simply adding as many points to the predicted trajectory per frame as it during a fixed time slice, so on a low end hardware and a very hard to predict chaotic halo orbit, you would move a node and see how your trajectory forecast stretches continuously over a few sec.

[Unit One]

There's another issue with using even n=2, it introduces sometimes very significant orbital perturbation, and right now there's no way people want to keep tabs on the orbital degradation of their 30 satellites in a game. It would be a lot of work, and geostationary orbits would be impossible. In real life constant automated monitoring and thruster fires keep satellites in their orbits, KSP is incapable of that. It's not a matter if it could be done, but rather should be done. (And it shouldn't be done.)

[SolarLiner]

Does Orbiter allow for more than one ship at a time? And if it is a recreation is it using some sort of pre-calculated math?

Of course ! You can do pretty much all of what KSP does, building aside. The sim is way more realistic (and maybe pre-calculated as well), and even solar wind is taken in account when space travelling.

[MBobrik]

right now there's no way people want to keep tabs on the orbital degradation of their 30 satellites in a game. It would be a lot of work, and geostationary orbits would be impossible.

.

AFAIK the RemoteTech mod can do that.

.

EDIT: Another possibility would be of course to add an arbitrary cutoff where the influence from the other bodies is too small, just like the atmosphere cutoff so ships on low to mid orbits would be completely unaffected.

Edited June 19, 2013 by MBobrik

[Unit One]

I don't know of RemoteTech being able to do that, I use RemoteTech in my main save. RemoteTech can begin a fire for a set time and a set delay after giving a signal, though. Unless there's something else amazing about RT's control that I don't know.

That would be a good idea, everything Geosynchronous and below could be protected while still allowing for Lagrange Points and other types of fun.

[Spacial_Anomaly]

EDIT: Another possibility would be of course to add an arbitrary cutoff where the influence from the other bodies is too small, just like the atmosphere cutoff so ships on low to mid orbits would be completely unaffected.

Another thing you have to look out for are numerical approximation errors (because you have a time steps and not a continuous time development, also depending on the method used), so orbits that should be stable "degenerate" over time.

[PLB]

If we do get n>1 calculations then we can see if mechjeb can keep our satellites in orbit, which is exactly how we keep our satellites in orbit in the solar system. We just need to pack some ion rcs (Which is a mod) onboard and replace any empty satellites, like how we do it in real life. Also, we 'could' make it an option to choose n equalling between [n=1-15] or even [n=15+( X% of the current ships in orbit)] if we REALLY want to take our simulating to the extreme. This is AFTER we get past the incapabilities of the 32-bit program KSP, whatever 'after' means.

Edited June 19, 2013 by PLB

[MBobrik]

Another thing you have to look out for are numerical approximation errors (because you have a time steps and not a continuous time development, also depending on the method used), so orbits that should be stable "degenerate" over time.

.

there are stable methods in the sense that in 1 body case all orbits that contain more than a few dozen timesteps per orbit stay stable.

Edited June 19, 2013 by MBobrik

[Technical Ben]

You know, this thread brings up a good point, because I've played Universe Sandbox where you can collide galaxies with the n value reaching many thousands, and it's not dipping below 5 FPS.

As for KSP, adding N-body physics would just add to a game that can already easily kill your CPU just by the massive ships/stations you can build. While n=2 or n=3 probably isn't that bad on it's own, once your ship get's close to say Duna and Ike, the computer would start running physics calculations for each part on your ship being affected by both bodies, which to me sounds bad for a CPU.

Relevant:

Scott Manley may also have done a video on this, and is a bit more confident on film than I am. :#

[tavert]

.

there are stable methods in the sense that in 1 body case all orbits that contain more than a few dozen timesteps per orbit stay stable.

And you can use implicit methods that are technically stable for any timestep. Doesn't change the fact that accuracy breaks down as timestep increases, unless your problem has a closed-form solution.

[drakesdoom]

Perhaps you should consider modifying the current system to look more like n body while staying 1 body. I have theorized that properly shaped SoI's (they are not exact spheres) coupled with very small SoI's at L points could give 90% of n body physics without any additional load of any kind.

[Unit One]

Slightly modifying SOIs might work well to make n=1 simulations more realistic, but n=1 physics and SOIs cannot be used for Lagrange points at all. Lagrange points go beyond a deformed sphere, and Lagrange points cannot be orbited any which way, like planets can.

This image shows just how different the shape of Lagrange orbits are, not resembling any conic at all. As you see, for L1 and L2 points you would need something of an SOI that resembles a bean.

I have an image of a different type of L1 orbit but it's in a book so it might take me a minute.

[drakesdoom]

Slightly modifying SOIs might work well to make n=1 simulations more realistic, but n=1 physics and SOIs cannot be used for Lagrange points at all. Lagrange points go beyond a deformed sphere, and Lagrange points cannot be orbited any which way, like planets can.

This image shows just how different the shape of Lagrange orbits are, not resembling any conic at all. As you see, for L1 and L2 points you would need something of an SOI that resembles a bean.

I have an image of a different type of L1 orbit but it's in a book so it might take me a minute.

You could not simulate a proper L point orbit but you could get the usefulness of the L point by making a micro gravity SOI say 5k meters across. If you pass through it without aiming for it you would be through so fast it would have little effect, but if you knew where it was and aimed for it drifting slowly into it bam craft is stable at L point.

[sjwt]

A 3D N=3 model would kill a CPU on its own.. At the moment you can get specfic solutions to the N body problem, in 2D on Java aps that eat all your CPU and MOAR. Those apps will simulate multiple no mass bodies relative to one or two bodies, or they can simulate 2 or 3 bodies with mass in a simplified optimised system. Adding a 3rd Dimension to any of these and you move into the realms of Supercomputers taking days to do a frame, add more bodies and good by!

[MBobrik]

And you can use implicit methods that are technically stable for any timestep. Doesn't change the fact that accuracy breaks down as timestep increases, unless your problem has a closed-form solution.

.

the accuracy breaks down, and for the best methods I've seen, the inaccuracy reaches a whopping 0.0001 % per orbit when having less than 30 points per orbit... which is, methinks, for the purposes of KSP, negligible

.

A 3D N=3 model would kill a CPU on its own.. At the moment you can get specfic solutions to the N body problem, in 2D on Java aps that eat all your CPU and MOAR.

.

Get yourself better apps

[tavert]

.

the accuracy breaks down, and for the best methods I've seen, the inaccuracy reaches a whopping 0.0001 % per orbit when having less than 30 points per orbit... which is, methinks, for the purposes of KSP, negligible

Keep in mind much of Unity is single-precision. There may not be the facilities within Unity to do this properly.