KSP2 Physics... more than 2 bodies?

[tstein]

32 minutes ago, GigFiz said:

If you have to do that already, why not just cut the whole issue out, stick with 2-body and save the dev-hours and computational power? I get that Lagrange points and better gravity assists (apparently. I've seen it mentioned that they are easier with principia, at least) are cool, but at that point cost/benefit doesn't seem to really make sense.

 

Because people (in my case back then my  boss) ask for N-Body.  A developer does what he is asked to do.

 

I agree there are simpler way to implement some of these concepts. Lagrange points can be simulated with invisible  anchors that  force local minima energywise and that is  far simpler to do than an N-Body simulation on a CPU budget.

32 minutes ago, GigFiz said:

Plus, as I saw someone here point out some time ago (and assuming their statement is accurate), NASA uses 2-body math to plan their missions, and that's worked out pretty well for them (we aren't exactly running planet formation simulations here. Even if our space programs go for hundreds, or even thousands of years, that's just a drop in the bucket); so hey, good enough for the space goose...

I  really think they do not use it anymore. Maybe they used in past, but they even had an open source  simulator that you can download and compile and run. I will see if I can find it when I get home, I remember downloading and compiling it once in the past.

 

edit: GMAT is one of the softwares they use: https://sourceforge.net/projects/gmat/

you can chose several forms of simulation and integrations

Edited December 13, 2022 by tstein

[Bej Kerman]

3 hours ago, K^2 said:

Your goal is to simulate 40 Kerbin years (4 light years at 0.1 c trip to Debdeb) in approximately 6 minutes of real time

6 minutes would be tedious - half that time is already enough tedium for a trip to Jool without BetterTimeWarp. Make it 30 seconds (42,075,901x time acceleration) 

[K^2]

4 hours ago, tstein said:

Sorry to burst your bubble , but I already did implement it (not alone we were a team of 11 back in 2002). We used 10 ticks per second for every  ship (we had a max count of  64 ships in that game, but it was 2003, so the CPU power available was  much more restricted as well, but  doing things in 64 was never a problem because  back then we did not use cookie cutter game engines, we always had to write the game engine)

And you propose to handle time warp how? You'd be running 10⁷ ticks per second, so you have 400 CPU cycles per tick. I'm not sure I can compute gravity from the sources, so just getting the forces, in 400 cycles. How do you propose handling collisions in these 400 cycles as well? I don't think you thought this through at all.

4 hours ago, tstein said:

each  ship  was computed in a LOCAL  frame of reference

That makes absolutely no difference in a central potential problem. There is a way to make perturbation theory work for you here, and compute the change of orbital parameters, which basically means working with conics and then making corrections, which is exactly what I was talking about for the Rask/Rusk optimization, but just the change of coordinates is more than 400 cycles here. You'll have to increase the time step, and that means the energy error will still grow, because your perturbations are not and cannot be normalized, because there is a genuine energy exchange between the craft and the planets that are effectively infinite sources.

4 hours ago, tstein said:

In nowhere I said that  it would be easy to reach the necessary  speed for a huge timewarp, I just said that the simulation itself with the precision needed for a game is not that hard to keep stable by cutting some corners of realism..

My dude, warp is the whole point. That's the whole point here. If I needed to make a simulation that keeps a simple satellite stable for the amount of real time a person is willing to sit in front of the screen and stare at it, it's a trivial task. We're talking about doing this a million times faster for a million times longer time period. If you haven't noticed, the actual impact on complexity here is 10¹². You are talking about a toy problem, and for KSP2 you need to solve one that's literally a trillion times more complex.

The actual code part here is easy. If you still think you understand the problem, go ahead an implement it. 40 Kerbin years of simulation in 6 minutes, and I'm not even asking for anything complex. Just a simple orbit around the Mun. I don't even care if your planets are on rails, honestly, because actually simulating movements of planets would be the first thing I'd axe for a game. And so would any reasonable developer. But keeping stable orbits around bodies in a complex system at the time scales and simulation speeds required is a bananas sort of task. It's not impossible, but everything you've said doesn't even scratch the surface of the amount of labor that has to go in. And the mathematics involved makes even my brain hurt.

[MK2-DroneCore]

It's Not necessary if you orbit the Moon and calculate the Jupiter's Gravity.

limited 3 body trajectory is ok

[K^2]

16 hours ago, MK2-DroneCore said:

It's Not necessary if you orbit the Moon and calculate the Jupiter's Gravity.

limited 3 body trajectory is ok

Agreed. The trouble is that even integration around a single body is nontrivial. The moment you go off conic rails, things get complicated. You either have to do perturbation, which is very mathy, or get exceptionally fancy with integration methods - also mathy and computationally expensive.

There are definitely ways to make this happen, but it's a whole lot of work.

Edited December 20, 2022 by K^2

[Ryaja]

It might be modded in.

[K^2]

9 minutes ago, Ryaja said:

It might be modded in.

I'm sure there will be mods for it. Adding influences of additional bodies might actually be very straight forward, as engine thrust under time warp is a thing in KSP2, apparently. If that's handled in a clever way, you might just add gravity of relevant bodies as "thrust", and let the game's simulation deal with it. Hopefully, the game handles thrust as a change to orbital parameters directly, rather than converting to Cartesian, applying forces, and converting back, which is what KSP did, and which is why there's so much jank around stability. Small errors in Cartesian can result in orbital elements bouncing all over the place. Whereas, if you compute the deltas for orbital elements directly, then small errors remain small. If KSP2 does the latter, this might work out of the box. Otherwise, precision will suffer greatly once you go beyond something simple like Kerbin-Mun transit or switch to high time warp. The problem is that either way this won't work at all with game's trajectory planning without some heavy modding there as well. So it will be consistently very wrong if you just hack in n-body physics. Whether it'd be possible to apply the same fix to the planning is hard to say, because we don't know how it's going to be handled and how the mod API will work with that.

tl;dr: I don't know how good a mod like this will be for general play, but I'm sure there will be something for people to play with Kerbin/Mun Lagrange points if they want.

[Ryaja]

49 minutes ago, K^2 said:

I'm sure there will be mods for it. Adding influences of additional bodies might actually be very straight forward, as engine thrust under time warp is a thing in KSP2, apparently. If that's handled in a clever way, you might just add gravity of relevant bodies as "thrust", and let the game's simulation deal with it. Hopefully, the game handles thrust as a change to orbital parameters directly, rather than converting to Cartesian, applying forces, and converting back, which is what KSP did, and which is why there's so much jank around stability. Small errors in Cartesian can result in orbital elements bouncing all over the place. Whereas, if you compute the deltas for orbital elements directly, then small errors remain small. If KSP2 does the latter, this might work out of the box. Otherwise, precision will suffer greatly once you go beyond something simple like Kerbin-Mun transit or switch to high time warp. The problem is that either way this won't work at all with game's trajectory planning without some heavy modding there as well. So it will be consistently very wrong if you just hack in n-body physics. Whether it'd be possible to apply the same fix to the planning is hard to say, because we don't know how it's going to be handled and how the mod API will work with that.

tl;dr: I don't know how good a mod like this will be for general play, but I'm sure there will be something for people to play with Kerbin/Mun Lagrange points if they want.

The nice thing is since they already coded it for rask and rusk it will be much easier to port

[K^2]

5 minutes ago, Ryaja said:

The nice thing is since they already coded it for rask and rusk it will be much easier to port

I have a feeling we're getting something greatly simplified for the Rask and Rusk system. (Aside, can we all just agree to call it the Risk system? I'm just going to do that.) A very simple way to handle a system like that is to have an SoI with a custom attractor in the planets' SoI overlap and at the opposing outer boundaries acting as L1-L3. That would let you place things in halo orbit, do low-energy transfers and captures, etc, without breaking the underlying assumptions the game has to make about everything being on-rails. You'd have to be a bit cheating about the attractors themselves, but a cylindrical symmetry with harmonic attractor in the radial direction and a very weak harmonic repulser in the radial direction is probably close enough. That way there is still an analytical solution to the trajectories in the Ln SoIs that would let you set up a quasi-stable halo orbit, and the capture trajectories passing through these will have the characteristic "spiraling in" movement. It's simple. It works with everything else in the game. It's good enough for Risk system. I would imagine something like this is what Intercept has gone with.

[Jacke]

The Lagrange points L4 and L5 are only stable equilibria if the mass ratio of the 2 large bodies is greater than 24.96.  As I assume Rask and Rusk will be about the same mass, that means all the Lagrange points would be unstable equilibria.

[K^2]

5 hours ago, Jacke said:

As I assume Rask and Rusk will be about the same mass, that means all the Lagrange points would be unstable equilibria.

There are dynamically quasi-stable orbits near L1-L3. That's good enough for a lot of tasks.

[MK2-DroneCore]

Although Pricipia is going to detonate my computer's Meomery. I still recommend the way it runs: 

Your spaceship's movement is instantly calculate by a accurate integrator, But  future's trajectory is calculate by a less-accurate integrator,which allows use a longer step-length and Absolutly-Harmless to your computer. We get TCM but system will automaticly generate them and do these burns.