KSP2 Physics... more than 2 bodies?

[licht77]

Hi! Is already known if KSP2's physics model will have more than 2 bodies interacting? eg. lagrange points are calling...

[The Aziz]

Except Rausk twins, no. Still the same patched conics system.

[mcwaffles2003]

Patched conics is just so much more simple to calculate while providing a decent amount of accuracy. Meanwhile 3+ body dynamics are more computationally intensive which would bog the game down a lot as more ships are travelling simultaneously as well as it just being far more daunting to new players. There will be some 3 body systems though so some of us wanting that experience won't be left out and as the mechanic is already in the game, I assume mods will quickly be there for those of us that would like such a system to be more prevalent.

[GoldForest]

22 minutes ago, mcwaffles2003 said:

Patched conics is just so much more simple to calculate while providing a decent amount of accuracy. Meanwhile 3+ body dynamics are more computationally intensive which would bog the game down a lot as more ships are travelling simultaneously as well as it just being far more daunting to new players. There will be some 3 body systems though so some of us wanting that experience won't be left out and as the mechanic is already in the game, I assume mods will quickly be there for those of us that would like such a system to be more prevalent.

No doubt Principia will get a 2.0 version soon after launch. 

[Majorjim!]

It’s Unity… hell no there won’t be anything like that. It’s a physics engine designed for PPUs, ported to GPUs then ported to CPUs.. 

[mcwaffles2003]

2 hours ago, Majorjim! said:

It’s Unity… hell no there won’t be anything like that. It’s a physics engine designed for PPUs, ported to GPUs then ported to CPUs.. 

But it was already confirmed there will be N-body, just in select areas

On 10/28/2022 at 12:27 AM, GoldForest said:

No doubt Principia will get a 2.0 version soon after launch. 

I hope so, I wonder how much of it will have to change to get ported over

[GoldForest]

1 hour ago, mcwaffles2003 said:

But it was already confirmed there will be N-body, just in select areas

I hope so, I wonder how much of it will have to change to get ported over

We're probably looking at a complete rewrite since KSP 2's code will be little to nothing like KSP 1's

[K^2]

5 hours ago, Majorjim! said:

It’s Unity… hell no there won’t be anything like that. It’s a physics engine designed for PPUs, ported to GPUs then ported to CPUs.. 

PhysX isn't used for orbital calculations. It's not what it's for. The trajectory computation is custom.

That said, numerical integration of gravitational interactions is notoriously unstable. You either have to make the time step very small even with RK4, or have to rely on very collocation methods. Either one brings its own limitations. Now, technically, since KSP2 will allow us to time warp with engines lit, you have to do this anyways - you can't just keep the ship on conic section rails if its engines are firing, but if the engineer Intercept hired to do physics really knows his stuff, he might have implemented a perturbation based approach, which allows you to basically run a step as if its on rails, then make corrections for external force. If that external force is a constant within the time step, as engine's thrust basically is, you can get wonderful precision with RK4 or even a velocity Verlet method. The math for it is a bit fancy, but that engineer has a background in finite element analysis, IIRC, so I'm cautiously optimistic.

If this is, indeed, what's being done to improve the precision of trajectory computation while time-warping with engines on, then it's a fantastic reason to stick with patched conics. N-body is fun and all, but if that limits the time warp to a value so low the interstellar is basically unplayable, then it's not worth it.

[mcwaffles2003]

1 hour ago, GoldForest said:

We're probably looking at a complete rewrite since KSP 2's code will be little to nothing like KSP 1's

Im not a programmer but I don't think the majority of what makes up principia is KSP necessarily. I think it just takes data KSP provides and that could be changed by just making sure the right variables go in the right places when KSP arrives. Though, I imagine continuous thrust under ward could change things. 

We'll see, but like I said.. Im not a programmer, Ive written code, but Im no where near fluent, I just get the gist.

[GoldForest]

5 minutes ago, mcwaffles2003 said:

Im not a programmer but I don't think the majority of what makes up principia is KSP necessarily. I think it just takes data KSP provides and that could be changed by just making sure the right variables go in the right places when KSP arrives. Though, I imagine continuous thrust under ward could change things. 

We'll see, but like I said.. Im not a programmer, Ive written code, but Im no where near fluent, I just get the gist.

I'm not a programmer at all either, but from what we've been told and my understanding, anything from KSP 1 will not work in KSP 2 without major overhauls. Modders might be able to get away with reusing some code from KSP 1 plugins, but not all of it. A large portion more than likely will have to be rewritten. I suspect some devs will decide to completely rewrite their mod's code from the ground up, to make it better suited for KSP 2, seeing as KSP 2's code won't be paperclips and rubber bands like KSP 1's is.

[mcwaffles2003]

38 minutes ago, GoldForest said:

I'm not a programmer at all either, but from what we've been told and my understanding, anything from KSP 1 will not work in KSP 2 without major overhauls. Modders might be able to get away with reusing some code from KSP 1 plugins, but not all of it. A large portion more than likely will have to be rewritten. I suspect some devs will decide to completely rewrite their mod's code from the ground up, to make it better suited for KSP 2, seeing as KSP 2's code won't be paperclips and rubber bands like KSP 1's is.

I think that largely depends on the type of mod. Im not saying any KSP 1 mods would work on KSP 2, but surely cosmetic mods for instance would translate over much more easily than something like realism overhaul or kerbalism

[GoldForest]

19 minutes ago, mcwaffles2003 said:

I think that largely depends on the type of mod. Im not saying any KSP 1 mods would work on KSP 2, but surely cosmetic mods for instance would translate over much more easily than something like realism overhaul or kerbalism

From my understanding, models have to be redone entirely to support PBR, so any cosmetic mod like Restock has to be redone. The textures might be able to be reused, but the models need to be redone. 

[K^2]

1 hour ago, GoldForest said:

From my understanding, models have to be redone entirely to support PBR, so any cosmetic mod like Restock has to be redone. The textures might be able to be reused, but the models need to be redone. 

Models themselves should be fine. People might have to re-export with tangents built, but that's about it. Textures on the other hand, yeah. There are different ways to set up PBR shaders, but typically you'll end up with at least one extra map containing things like metalicity and roughness of materials. So that'd have to be made from scratch for every model.

2 hours ago, mcwaffles2003 said:

Im not a programmer but I don't think the majority of what makes up principia is KSP necessarily. I think it just takes data KSP provides and that could be changed by just making sure the right variables go in the right places when KSP arrives.

Supporting thrust during time warp is going to be a big deal. You'll also care way more about integration stability, so I'm pretty sure @GoldForest  is right here, and it's pretty much a clean re-write. But I haven't looked at the Principia code, so maybe they already set it up in a way that'd make it a lot more straight forward.

[Majorjim!]

8 hours ago, K^2 said:

PhysX isn't used for orbital calculations. It's not what it's for. The trajectory computation is custom.

That said, numerical integration of gravitational interactions is notoriously unstable. You either have to make the time step very small even with RK4, or have to rely on very collocation methods. Either one brings its own limitations. Now, technically, since KSP2 will allow us to time warp with engines lit, you have to do this anyways - you can't just keep the ship on conic section rails if its engines are firing, but if the engineer Intercept hired to do physics really knows his stuff, he might have implemented a perturbation based approach, which allows you to basically run a step as if its on rails, then make corrections for external force. If that external force is a constant within the time step, as engine's thrust basically is, you can get wonderful precision with RK4 or even a velocity Verlet method. The math for it is a bit fancy, but that engineer has a background in finite element analysis, IIRC, so I'm cautiously optimistic.

If this is, indeed, what's being done to improve the precision of trajectory computation while time-warping with engines on, then it's a fantastic reason to stick with patched conics. N-body is fun and all, but if that limits the time warp to a value so low the interstellar is basically unplayable, then it's not worth it.

Thank you for the insight! 

[Yakez]

I feel people miss the hype of Rusk twins.  On one hand we have 2 body system everywhere just like in KSP1. But this small 3 body interaction addition for only one instance is still huge chunk of code done (maybe even bigger chunk than everything else).

I bet it would be relatively easy to implement as mod for everything else in the game. But what stopping it to be just an extra difficulty toggle? Default game with 2 body interactions and hard mode with 3 body interactions for people who have "beaten" Rusk twins in their playthrough?

[tstein]

On 10/27/2022 at 8:43 AM, licht77 said:

Hi! Is already known if KSP2's physics model will have more than 2 bodies interacting? eg. lagrange points are calling...

It is possible to  create lagrange points without the complete simulation of the NBodies. The lagrance points effectively are local minima energy state wise  so there are ways to implement them artificially with zones where certain levels of forces are "neutralized" artificially.

 

That said it woudl not be terribly  hard to implement for specifically  kerbin - moon-  ship  sets.

2 hours ago, Yakez said:

I feel people miss the hype of Rusk twins.  On one hand we have 2 body system everywhere just like in KSP1. But this small 3 body interaction addition for only one instance is still huge chunk of code done (maybe even bigger chunk than everything else).

I bet it would be relatively easy to implement as mod for everything else in the game. But what stopping it to be just an extra difficulty toggle? Default game with 2 body interactions and hard mode with 3 body interactions for people who have "beaten" Rusk twins in their playthrough?

Not in fact...  NBodies simulation is   very little code, but it is a code that is computationally  very expensive.  One can implement an N-Body  simulation with an Rk4 integrator in an afternoon. The problem is you cannot predict the future without   stepping into the future and that makes  orbit prediction quite expensive (specially considering time acceleration)

On 11/18/2022 at 4:55 AM, K^2 said:

 

That said, numerical integration of gravitational interactions is notoriously unstable. You either have to make the time step very small even with RK4, or have to rely on very collocation methods. Either one brings its own limitations. Now, technically, since KSP2 will allow us to time warp with engines lit, you have to do this anyways - you can't just keep the ship on conic section rails if its engines are firing, but if the engineer Intercept hired to do physics really knows his stuff, he might have implemented a perturbation based approach, which allows you to basically run a step as if its on rails, then make corrections for external force. If that external force is a constant within the time step, as engine's thrust basically is, you can get wonderful precision with RK4 or even a velocity Verlet method. The math for it is a bit fancy, but that engineer has a background in finite element analysis, IIRC, so I'm cautiously optimistic.

 

If you want  the whole N Body system  to   change all the time yes, but if someone just wants the ships to be constantly under effect of gravity of the N-closer bodies  and the bodies themselves just have a few cycles or "pre computed  pattern and after those they are pushed into the previously  exactly known position) it is feasible.

 

Btw For planetary body levels  an Rk4 works  quite well even with a huge 1 hour step. IT takes   tens of years  of simulation before you  see  weird stuff and KSP we are not trying to predict  centuries of effect of jupiter in orth cloud.

[Drakenred65]

There was a n body simulation of kerbal space.

 

it started chucking moons around…

[RKunze]

On 11/18/2022 at 8:55 AM, K^2 said:

That said, numerical integration of gravitational interactions is notoriously unstable.

Actually, N-Body gravitational interaction per se is chaotic, and it is not easy to design a planetary system that's actually stable over longer periods.

That said, you can at least avoid the additional chaos and instability introduced by the inevitable numerical errors in a simulation by choosing a "symplectic integrator" that preserves the system invariants even in the face of numerical errors (for a newtonian system, that would be the sum of potential and kinetic energy). You'll still get inaccurate results, of course, but instead if going completely out of control (as with a non-symplectic integrator such as Runge-Kutta), the orbits just wobble a bit around the "real" position.

[K^2]

17 minutes ago, RKunze said:

That said, you can at least avoid the additional chaos and instability introduced by the inevitable numerical errors in a simulation by choosing a "symplectic integrator" that preserves the system invariants even in the face of numerical errors (for a newtonian system, that would be the sum of potential and kinetic energy).

That sounds great on paper, and is the correct way to approach many systems. Why don't you go ahead and write out a simplectic integrator for an n-body gravitational interaction. We can treat the sources of gravity as "on rails," as in KSP, but their positions are a function of time. As a hint, the total of potential and kinetic energy of the ship you're simulating is not a conserved quantity in this system. Let me know once you figure out the invariant to use.  

3 hours ago, tstein said:

Btw For planetary body levels  an Rk4 works  quite well even with a huge 1 hour step. IT takes   tens of years  of simulation before you  see  weird stuff and KSP we are not trying to predict  centuries of effect of jupiter in orth cloud.

1 hour steps will skip through some SoI's entirely, meaning your predicted and real trajectory will end up different depending on whether you go into time warp or not. Keep in mind that it's a significant requirement Intercept has been trying to satisfy, one that KSP failed hard at, that the trajectory you get when you plot the course is the one you actually get. How do you propose eliminating jumps between having encounter and not having an encounter in this setup? In a patched conics, I can solve for encounter and make sure that's included as a time step. How do you solve that with RK4?

Moreover, RK4 tends to gain energy orbiting a single body. Not even getting into an n-body situation, there are ways to intentionally turn it into a kraken drive. How do you fix that?

[Strawberry]

We dont know how rask and rusk work on the backend outside of it being a novel solution. My guess is whatever code rask and rusk uses takes the advantage that there are only three bodies in play, and they're of equal size and distance. Im guessing that applying whatever rask and rusk has going on in the backend to other systems will be far from trivial work.

[RKunze]

3 hours ago, K^2 said:

Why don't you go ahead and write out a simplectic integrator for an n-body gravitational interaction. We can treat the sources of gravity as "on rails," as in KSP, but their positions are a function of time. As a hint, the total of potential and kinetic energy of the ship you're simulating is not a conserved quantity in this system. Let me know once you figure out the invariant to use.

I could be tempted. But then, I'd probably cheat and simply look at the Principia sources, since they did all the hard work already 

[tstein]

14 hours ago, K^2 said:

 

1 hour steps will skip through some SoI's entirely, meaning your predicted and real trajectory will end up different depending on whether you go into time warp or not. Keep in mind that it's a significant requirement Intercept has been trying to satisfy, one that KSP failed hard at, that the trajectory you get when you plot the course is the one you actually get. How do you propose eliminating jumps between having encounter and not having an encounter in this setup? In a patched conics, I can solve for encounter and make sure that's included as a time step. How do you solve that with RK4?

Moreover, RK4 tends to gain energy orbiting a single body. Not even getting into an n-body situation, there are ways to intentionally turn it into a kraken drive. How do you fix that?

That is not the idea .  A system like the one in question does not need to  run on same dt for all body categories and neither the N-Body  must  be truly quadratic.  Planetary bodies are the only ones massive enough to  really affect each other, so  you have an integration loop  running with dt of 1 hour (in kerbal smaller scale maybe go down to 15 min) where the  velocities and accelerations are  derived from the gravitational  pull  ONLY among the massive bodies .  A second loop running in  a tigher dt runs for all  non  super massive bodies and they  get their derivatives calculated from the effect of the bodies in the first group upon them.    The position of the celestial bodies between each iteration is  a simple linear or quadratic interpolator between the previous point and the next one, the  ships  have much   more precise dt.   For each of the celestial bodies there is a final step every M iteractions where the whole energy state fo the system is adjusted to help erase numeric instability errors.

 

That is enough for a GAME. You have  celestial bodies behaving as an N-Body system   with a precision enough that a casual observer cannot   say something is not  right, and you have ships  behaving as if  under effect of  N-Bodies ( again  one can optimize and use only an n clsoer ones where n <N)

14 hours ago, Strawberry said:

We dont know how rask and rusk work on the backend outside of it being a novel solution. My guess is whatever code rask and rusk uses takes the advantage that there are only three bodies in play, and they're of equal size and distance. Im guessing that applying whatever rask and rusk has going on in the backend to other systems will be far from trivial work.

I think those conditions are more related to    having a multi body system that is stable.   When I wrote my first orbit integrator  I was amazed  how many times I had to try to change masses and velocities until I got a system that was stable (nothing being thrown into the void) in the first 30  orbits.

[K^2]

2 hours ago, tstein said:

A second loop running in  a tigher dt runs for all  non  super massive bodies and they  get their derivatives calculated from the effect of the bodies in the first group upon them.

Cool. So what's the dt for your space ships? How many iterations per second are you running now to make sure every probe stays in the correct orbit of planets and moons, while the player is running 1M factor time warp for an interstellar ship? 1 minute is probably too coarse for some orbits, and you need to be running hundreds of hours of simulation for every real-time second. How?

2 hours ago, tstein said:

For each of the celestial bodies there is a final step every M iteractions where the whole energy state fo the system is adjusted to help erase numeric instability errors.

Big oof. Double precision math has about 16 orders of magnitude, and games usually run on single precision, which is closer to 7 orders of magnitude. What do you imagine happens to the kinetic energy of your spacecraft when you try to include them in energy normalization along with the planets? And if you don't consider the planets, the energy of the space craft is not conserved. Your correction is absolutely useless, when for any given space craft, every planetary body is effectively an infinite pool of energy to within any numerical precision you can reasonably throw at this problem without grinding it to an absolute halt.

2 hours ago, tstein said:

That is enough for a GAME.

If I put some probes to orbit the Mun, send a rocket to Debdeb under maximum time warp, and when I switch back to the Mun all my probes are gone, it's not good enough for the game. And you do not have the necessary stability in the above to allow for this use case. If you really think it's so simple, you can go ahead and implement it. What you described above would take a couple of hours to put into code. Doesn't need to be complex. Kerbol, Kerbin, Mun all in their KSP orbits. A single satellite orbiting the Mun. 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, corresponding to 1M times warp. All we need to find on the other end is Kerbin and Mun where they're supposed to be and the satellite in roughly the same orbit. That'd be enough for a game. Good luck.

[tstein]

1 hour ago, K^2 said:

Cool. So what's the dt for your space ships? How many iterations per second are you running now to make sure every probe stays in the correct orbit of planets and moons, while the player is running 1M factor time warp for an interstellar ship? 1 minute is probably too coarse for some orbits, and you need to be running hundreds of hours of simulation for every real-time second. How?

Big oof. Double precision math has about 16 orders of magnitude, and games usually run on single precision, which is closer to 7 orders of magnitude. What do you imagine happens to the kinetic energy of your spacecraft when you try to include them in energy normalization along with the planets? And if you don't consider the planets, the energy of the space craft is not conserved. Your correction is absolutely useless, when for any given space craft, every planetary body is effectively an infinite pool of energy to within any numerical precision you can reasonably throw at this problem without grinding it to an absolute halt.

If I put some probes to orbit the Mun, send a rocket to Debdeb under maximum time warp, and when I switch back to the Mun all my probes are gone, it's not good enough for the game. And you do not have the necessary stability in the above to allow for this use case. If you really think it's so simple, you can go ahead and implement it. What you described above would take a couple of hours to put into code. Doesn't need to be complex. Kerbol, Kerbin, Mun all in their KSP orbits. A single satellite orbiting the Mun. 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, corresponding to 1M times warp. All we need to find on the other end is Kerbin and Mun where they're supposed to be and the satellite in roughly the same orbit. That'd be enough for a game. Good luck.

 

 

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) The planets energy normalization was not applied with the ships mixed, each  ship  was computed in a LOCAL  frame of reference (you always need to have those because the graphic coordinate system already demands it, so to keep it for the physics was not that much more work, that combined with the fact that we limited the number of celestial bodies affecting a single  body to a rather low number was enough to keep things pretty stable) . We did not try to  get a final perfect energy state, just a dampening function  to keep things stable (and it did work for our time frames).    we could not get a transfer from one planet to other that ended with a single meter deviation on the final Pe, but we did not try that, we simply assumed  (And displayed)t hat the player could not have such level of precision before  reaching the terminal  local frame of reference.

 

There were a few other tricks we had to create, but  after 20 years I do not remember everything anymore. Unfortunately the game development flopped  because  of internal administrative issues, but it did work pretty well for the type of scenario we had  .

 

Under that system  your mun probes would not be gone because they are simulated in a LOCAL frame of reference, but they do receive attraction of any body whose the gravitational pull was large enough  comparing  the origin of that local frame of reference to the origin of the other celestial body frame of reference.  In our game we did not had time warp because it was a persistent  real time game  and the idea was that the whole system would  have just a few orbit in the whole game lifetime (although the moon systems of the large planets  would score up  quite a good number of revolutions).

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..

 

[GigFiz]

53 minutes ago, tstein said:

not that hard to keep stable by cutting some corners of realism

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.

2 hours ago, K^2 said:

Double precision math has about 16 orders of magnitude, and games usually run on single precision, which is closer to 7 orders of magnitude

In one of the dev diaries, they noted that, at the scales they are working at and the precision they need, you blow way past the limits of 64-bit calculation (and moving to double precision brings its own set of issues at large numbers), so it has to calculate things as a section within a section in order to reach the precision necessary. If, in order to keep framerates and performance high, you are doing only one section at a time like that, you need something to keep things stable and accurate everywhere else in the meantime with the minimum amount of resources, which sure sounds like you've circled back around to rails again.

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...