N-body physics

[runner78]

They also had problems, http://universesandbox.com/blog/2016/02/n-body-problem/ i don't know how they solved it in the end.

[mcwaffles2003]

19 minutes ago, runner78 said:

They also had problems, http://universesandbox.com/blog/2016/02/n-body-problem/ i don't know how they solved it in the end.

They say how they solved it in the link you sent. At large timesteps it simplifies the universe into many 2 body problems. I feel with most things staying on rails while craft are n-body or even just 3 or 4 body will allow for plenty of timewarp and this will be very useful in cases of binary systems

[runner78]

At that date it was a proposed idea.

[runner78]

If you switch from n-body to 2-body on timewraps,  the pre calculated orbits would change every time. The n-body problem does not depend on the number of additional bodys.

Calculate the orbit lines would be a problem too, you need precalculate n-body affected vessel in worst case years in the future, every time you change the velocity. 

[mcwaffles2003]

3 minutes ago, runner78 said:

If you switch from n-body to 2-body on timewraps,  the pre calculated orbits would change every time. The n-body problem does not depend on the number of additional bodys.

it does depend on the number of bodies, hence "n"-body. if there are 1000 bodies it runs as a 1000-body simulation, this is why i speak about an on rails and 3/4-body hybrid. this would allow the creation of lagrange points while keeping calculations somewhat simple and allow for pretty accurate representation of dynamics in binary systems and the like

[Guest]

1 hour ago, mcwaffles2003 said:

They say how they solved it in the link you sent. At large timesteps it simplifies the universe into many 2 body problems. I feel with most things staying on rails while craft are n-body or even just 3 or 4 body will allow for plenty of timewarp and this will be very useful in cases of binary systems

No, that wouldn't work. Even if you have one single object as n-body it means you'll have to compute all the intermediate states (and coarser steps will lead to bigger errors). With patched conics or a set of 2-body problems you can compute the state of the system at any point in time in a single pass. That's a qualitative difference and it's a crucial one if you want the game to support campaigns spanning thousands of years.

Edited October 4, 2019 by Guest

[mcwaffles2003]

2 minutes ago, Brikoleur said:

Even if you have one single object as n-body it means you'll have to compute all the intermediate states 

With patched conics or a set of 2-body problems you can compute the state of the system at any point in time in a single pass

So 2 body is more simple than one body? and somehow 4 body is equivalent to 1000 body computationally, despite n-body algorithms scaling as O(n^2)? I understand that every timestep will need to be calculated, but asserting that that's a difficult computation and is taxing to a CPU anywhere near what 200+ rigid body dynamics system is seems a bit much. Not to mention this is a very parallelizable problem, as seen with how performance increases in things like universe sandbox with more cores, showing significant improvements in speed up to and beyond utilizing 8 threads.

I dont see how running this is as taxing as many seem to believe, and as I've mentioned earlier, hybridize this with an on rails system for all major bodies to reduce complexity further. Utilizing these kind of algorithms shows great promise to expanding the capabilities for KSP to simulate more and more niche conditions like binary systems (rask/rusk). My cheap $100 phone runs N-body games like orbits just fine im sure a mid-tier laptop would do just fine as well

[runner78]

13 minutes ago, mcwaffles2003 said:

So 2 body is more simple than one body?

You need minimum 2 body for an orbit 

[mcwaffles2003]

3 minutes ago, runner78 said:

You need minimum 2 body for an orbit 

I too was confused about that statement, lol

[Guest]

@mcwaffles2003 It's a qualitative difference. 

If you have even one object simulated with n-body and you want to timewarp ahead 100 years, you have to compute all the intermediate steps. The coarser the steps, the bigger the error, and because of the nature of the beast the error will compound. 

If you don't, you can compute the state of the entire system in one go. It doesn't matter if you timewarp 1 second, 1 year, 100 years, or 1,000,000 years.

This is a scalability problem and it is not a trivial one. That you can run a pretty complex n-body simulation on your phone in real time doesn't mean much. If your phone is running at near maximum power, then a computer that's 100 times more powerful could timewarp ahead at equal precision at 100x timewarp. So, say, timewarping ahead 100 years would only take 1 year real time. Most players would not find that acceptable.

[mcwaffles2003]

5 minutes ago, Brikoleur said:

@mcwaffles2003 It's a qualitative difference. 

If you don't, you can compute the state of the entire system in one go. It doesn't matter if you timewarp 1 second, 1 year, 100 years, or 1,000,000 years.

This is a scalability problem and it is not a trivial one. That you can run a pretty complex n-body simulation on your phone in real time doesn't mean much. If your phone is running at near maximum power, then a computer that's 100 times more powerful could timewarp ahead at equal precision at 100x timewarp. So, say, timewarping ahead 100 years would only take 1 year real time. Most players would not find that acceptable.

You're making some strong assumptions there, such as this factor of 100x, which unless you can provide reference I am going to assume you are pulling that number because its pleasing to you and fits a narrative. On the other hand, here's a random video of Universe sandbox 2:

This is actually a reference, of a game built on unity, running N-body type problems. Somehow this game is managing to run at timesteps of more than 1 year/second and seeing as there are 3.154e+7 seconds per year that means its running at over 3.154e+7x

This seems a bit drastic to me personally for timewarping and I think if we settle for a mere 10,000x  the game will be able to still manage a very fair bit of accuracy.

[runner78]

I think, US2 using some trick, probably 2-Body simulation between 2 timesteps. the accuracy decreases with the timewrap. Unsuitable for an space flight management.

[Guest]

20 minutes ago, mcwaffles2003 said:

You're making some strong assumptions there

I'm not making any kind of assumptions. I'm simply pointing out a fact: that computing the state of an n-body simulation at a point in time requires multiple steps that scale with time and accuracy, whereas computing the state of a patched conic or 2-body simulation can be done in one step. It's a qualitative difference which makes patched conics or 2-body a much, much simpler problem.

Whether the n-body problem is soluble or not is a different matter, but it is an indisputable fact that it is much more complex and much more computationally intensive. 

[mcwaffles2003]

9 minutes ago, Brikoleur said:

I'm not making any kind of assumptions. I'm simply pointing out a fact: that computing the state of an n-body simulation at a point in time requires multiple steps that scale with time and accuracy, whereas computing the state of a patched conic or 2-body simulation can be done in one step. It's a qualitative difference which makes patched conics or 2-body a much, much simpler problem.

Whether the n-body problem is soluble or not is a different matter, but it is an indisputable fact that it is much more complex and much more computationally intensive. 

But youre not saying how computationally intensive it is, you are simply saying more. I've provided an example of a game doing a harder calculation than I have described, running at over 10,000,000x and all you've been responding with is essentially is "it's more complex and isn't feasable"

I'm a reasonable person, seriously, but please reference me to something to back up the limitations you are purporting. These calculations arent that difficult, reference 4 positions, find the difference between 1 of those positions and the other 3, reference the 3 large bodies masses, based on mass and distance find the acceleration imparted onto the 1 craft body, make a time step. this is not that hard, I've written orbital approximation code in under 100 lines total. Not to mention this is a parallelizable problem that scales well with more cores easily

Edited October 4, 2019 by mcwaffles2003

[runner78]

Unity make by default 50 physic timesteps per second.

Timewrap 1 Second = 1 Year with the same accuracy as realtime, you need 157,680,000,000 sub-steps per second.

[Guest]

10 minutes ago, mcwaffles2003 said:

But youre not saying how computationally intensive it is, you are simply saying more. I've provided an example of a game doing a harder calculation than I have described, running at over 10,000,000x and all you've been responding with is essentially is "it's more complex and isn't feasable"

I didn't say it wasn't feasible. In fact I said more or less the opposite: 

5 hours ago, Brikoleur said:

Difficulty of implementation isn't the problem, the effects on gameplay are.

It is indisputably more complex. Again, the computational complexity isn't the issue, but the gameplay effects are. I've no doubt that there are solutions or workarounds to the gameplay problems, given sufficient time and budget, but I also think it's entirely reasonable that Star Theory chose to go with patched conics and simply avoid these complexities altogether. 

[runner78]

17 minutes ago, mcwaffles2003 said:

Not to mention this is a parallelizable problem that scales well with more cores easily

I forgot to mention: n-body is not very suitable for parallel computing, you need all current body positions for each step . With many bodies you can make chunk of bodies to run in parallel und synchronize it at the end of the step, but with a small amount of bodies, the overhead would be greater than the benefits.

[mcwaffles2003]

3 minutes ago, runner78 said:

I forgot to mention: n-body is not very suitable for parallel computing, you need all current body positions for each step . With many bodies you can make chunk of bodies to run in parallel und synchronize it at the end of the step, but with a small amount of bodies, the overhead would be greater than the benefits.

not if all the bodies exerting gravity (non craft bodies) are on rails, then you can put each craft on a separate thread and run simultaneously. Also, care to explain how US2 scales so well with multiple cores?

Edited October 4, 2019 by mcwaffles2003

[Terwin]

As far as I have seen, the most telling argument against n-body physics is that it is harder to understand for newcomers and has a very real ability to anger or frustrate those who do not expect their satellites to come crashing down for no obvious reason.

The bar for entry in this game-space is already much higher than for most other games, so it is in T2I's best interest to keep everything as simple as possible for the purposes of keeping their audience as broad as possible. 

I expect that if Patched Conics required twice as much work and processing power as n-body, that T2I would still use patched conics so as to keep the barrier to entry as low as possible.

As such, I do not expect n-body physics to be the default setting unless and until the average high-school student with a sport letter-jacket can explain what a Lagrange point is.

And if it will not be the default setting, I seriously doubt it will be available in the release that needs to be ready before the end of the current fiscal year, unless it was already done before the announcement(it sounds like it was not).

 

The bar for entry is far more important for audience-size(and thus revenue) than any reasonable amount of additional processing power, and as indicated by the effort being put in on context-sensitive help/tutorials, lowering the bar for entry is a primary concern for KSP2.  I have no doubt that n-body will be a mod available within months of the release date, but as something that raises the bar for entry(and thus lowers potential revenue), I cannot see it included as the default setting.

[runner78]

2 minutes ago, mcwaffles2003 said:

not if all the bodies exerting gravity (non craft bodies) are on rails, then you can put each craft on a separate thread and run simultaneously

That would be easier, but also better to chunk crafts together, if you have 100 n-body effected bodies, 100 busy threads slow down each other (many thread share the same core, an result in many context switches).

[mcwaffles2003]

3 minutes ago, Terwin said:

As far as I have seen, the most telling argument against n-body physics is that it is harder to understand for newcomers and has a very real ability to anger or frustrate those who do not expect their satellites to come crashing down for no obvious reason.

The bar for entry in this game-space is already much higher than for most other games, so it is in T2I's best interest to keep everything as simple as possible for the purposes of keeping their audience as broad as possible. 

I expect that if Patched Conics required twice as much work and processing power as n-body, that T2I would still use patched conics so as to keep the barrier to entry as low as possible.

As such, I do not expect n-body physics to be the default setting unless and until the average high-school student with a sport letter-jacket can explain what a Lagrange point is.

And if it will not be the default setting, I seriously doubt it will be available in the release that needs to be ready before the end of the current fiscal year, unless it was already done before the announcement(it sounds like it was not).

 

The bar for entry is far more important for audience-size(and thus revenue) than any reasonable amount of additional processing power, and as indicated by the effort being put in on context-sensitive help/tutorials, lowering the bar for entry is a primary concern for KSP2.  I have no doubt that n-body will be a mod available within months of the release date, but as something that raises the bar for entry(and thus lowers potential revenue), I cannot see it included as the default setting.

I get this argument but it makes me sad knowing patched conics fails in the Ike/duna for realistic orbits and any binary system is impossible without special conditions

[Arugela]

5 hours ago, runner78 said:

If you switch from n-body to 2-body on timewraps,  the pre calculated orbits would change every time. The n-body problem does not depend on the number of additional bodys.

Calculate the orbit lines would be a problem too, you need precalculate n-body affected vessel in worst case years in the future, every time you change the velocity. 

What if the got rid of the orbit lines and simply had pathing from the vehicle given gravitational effects and trajectory.

 

Quote

 

1 hour ago, Terwin said:

As far as I have seen, the most telling argument against n-body physics is that it is harder to understand for newcomers and has a very real ability to anger or frustrate those who do not expect their satellites to come crashing down for no obvious reason.

The bar for entry in this game-space is already much higher than for most other games, so it is in T2I's best interest to keep everything as simple as possible for the purposes of keeping their audience as broad as possible. 

I expect that if Patched Conics required twice as much work and processing power as n-body, that T2I would still use patched conics so as to keep the barrier to entry as low as possible.

As such, I do not expect n-body physics to be the default setting unless and until the average high-school student with a sport letter-jacket can explain what a Lagrange point is.

And if it will not be the default setting, I seriously doubt it will be available in the release that needs to be ready before the end of the current fiscal year, unless it was already done before the announcement(it sounds like it was not).

 

The bar for entry is far more important for audience-size(and thus revenue) than any reasonable amount of additional processing power, and as indicated by the effort being put in on context-sensitive help/tutorials, lowering the bar for entry is a primary concern for KSP2.  I have no doubt that n-body will be a mod available within months of the release date, but as something that raises the bar for entry(and thus lowers potential revenue), I cannot see it included as the default setting.

 

 

The bar for entry is not more important.

 

There is no such thing as a bar for entry. Any game can allow players to figure it out. As in this game with somewhat automated and simple things like lego parts and SAS. Or they can provide info and a community to help. If you simplify the game it has less to do in it. That is the most important thing.

Edited October 4, 2019 by Arugela

[runner78]

10 minutes ago, Arugela said:

What if the got rid of the orbit lines and simply had pathing from the vehicle given gravitational effects and trajectory.

 by by maneuver node 

Same math as before: 1 (earth)year tractory line precalculate with the same accuracy as realtime, you need 157,680,000,000 calculation steps.

[Arugela]

What if you thin out the calc when low gravity or no gravity and leave the calcs for curvs. And still generalize them a bit. You are talking a flight plane not the actual flight.

You could average a calculation based on a forumla based on the planets given statistics at certain points. maybe a point of exit. Then compare to thinned out real time calcs. Maybe every so many seconds or minutes. Change the intensity at different spots as needed.

Why can't you have maneuver nodes. You just need to do them differently. Heck they could be completely made from averaged calcs. the body could preserve an average over given times. Maybe 1 second, 1 minute, 1 hour, 1 day, 1 week, 1 month, and 1 year. 7 distinct data points for each body to use for a predicted path. Any simplified forms of data that can be taken from those data points. And you could always just update those numbers from each other also and updated a few variable stored in a simplified value updated and reduced in ram. Or is there a way to do it without reducing a value and without increasing a effective divisor. Any interesting formulas out there? Averages of infinitely increasing values or infinite values. Possibly with a finite range.

Edited October 4, 2019 by Arugela

[mcwaffles2003]

2 minutes ago, runner78 said:

 by by maneuver node 

Same math as before: 1 (earth)year tractory line precalculate with the same accuracy as realtime, you need 157,680,000,000 calculation steps.

care to put those numbers into perspective or do you just like saying big numbers without reference?

 

did you know the game file is approximately 34,000,000,000 bits? thats such a big number that no computer could probably ever hold it