Nbody physics. Only for ship parts?!(multithreaded rigid body.)

[Arugela]

https://pdfs.semanticscholar.org/e74e/9c6feafccd37cfcfdea893ba36436a7c9dc2.pdf

This is going to be stupid, but can this be applied to only ship parts and not the general universe? If so can we have loose parts and then start to simulate proper connections to the parts and get a better overall result. Lets say the parts aren't unrealistic. We have compartmentalized components in real construction. Can we do more realistic physics for ship connects and then simulate connections between them. And then even possibly have the connections and parts simulated separately or something that allow multithread/core part simulation. Couldn't we get real flex for this?(This would require parts made of parts for individual part flex over ship flex.) The connections between parts could even be part of ship construction. You could choose different types of welding or other things to connect the part with more realistic connection strengths. Would it help to make the connections like objects? Technically they are. A weld is a bunch of metal.

If physics can be multi core in general. Can that be increased to make up for the parts connection and increase overall parts count? Or is that not the limit of parts count?

Could gpu compute then be used to aid the cpu or vice versa?

Edited September 3, 2020 by Arugela

[JcoolTheShipbuilder]

as in, principia, but planets are still on rails? hmmm, interesting concept

[Incarnation of Chaos]

Rigid body simulation is the actual issue, as it requires knowing the previous state of the previous part. Which in English means that you cannot multithread it (well you technically could, but the result would be each thread waiting for the last in sequential order. So it would actually be SLOWER)

You can do multi-core, multiple thread, gpu accelerated physics for ships, but it will require a different way of handling vessels, likely involving particles, and it would take time, money and specialized developers to make. 

Doing a full N-body simulation of the system in reality wouldn't be that computationally expensive if they developed it from the ground up, and used a system of culling like KSP2 where systems wouldn't be fully loaded until you encountered their outer boundaries  (you'd still have to simulate the interactions with the system in the background, so I'm not actually sure how much you're saving )

The issues with n-body come mostly from the inherent chaotic nature, relative reference frames and etc. That would all be alien to anyone who hadn't touched principia in KSP, and it would also make orbits unstable.

But you don't want to simulate the systems/celestials; you want the ships. And for that, it literally isn't even a talking point. There's ways to do it, but it has very little to do with n-body (this is referring to gravitation!). Where the ship physics has to do with forces, acceleration, joints, deformation etc.

This has been beaten to death on multiple threads though, so to summarize the same conclusion that they all reached.

It's not impossible, but it's not going to happen due to the breaking of compatibility, and the specialist resources needed. Especially anything on a GPU. The last nail in the coffin though?

KSP2 is still using rigid body for vessels, but they've developed a system to treat large numbers of relatively static parts as a single one for the calculations. This will in their opinion allow part counts in the thousands.

That remains to be seen, but they've been bullish about this from day one. And it doesn't require any fancy new physics or developer skills, just going from a naive implementation of the same code to a more well optimized version.

[Arugela]

 

6 hours ago, Incarnation of Chaos said:

Rigid body simulation is the actual issue, as it requires knowing the previous state of the previous part. Which in English means that you cannot multithread it (well you technically could, but the result would be each thread waiting for the last in sequential order. So it would actually be SLOWER)

You can do multi-core, multiple thread, gpu accelerated physics for ships, but it will require a different way of handling vessels, likely involving particles, and it would take time, money and specialized developers to make. 

Doing a full N-body simulation of the system in reality wouldn't be that computationally expensive if they developed it from the ground up, and used a system of culling like KSP2 where systems wouldn't be fully loaded until you encountered their outer boundaries  (you'd still have to simulate the interactions with the system in the background, so I'm not actually sure how much you're saving )

The issues with n-body come mostly from the inherent chaotic nature, relative reference frames and etc. That would all be alien to anyone who hadn't touched principia in KSP, and it would also make orbits unstable.

But you don't want to simulate the systems/celestials; you want the ships. And for that, it literally isn't even a talking point. There's ways to do it, but it has very little to do with n-body (this is referring to gravitation!). Where the ship physics has to do with forces, acceleration, joints, deformation etc.

This has been beaten to death on multiple threads though, so to summarize the same conclusion that they all reached.

It's not impossible, but it's not going to happen due to the breaking of compatibility, and the specialist resources needed. Especially anything on a GPU. The last nail in the coffin though?

KSP2 is still using rigid body for vessels, but they've developed a system to treat large numbers of relatively static parts as a single one for the calculations. This will in their opinion allow part counts in the thousands.

That remains to be seen, but they've been bullish about this from day one. And it doesn't require any fancy new physics or developer skills, just going from a naive implementation of the same code to a more well optimized version.

I wonder if they will back port that into ksp1. I had a similar idea about letting users define such things in the vehicle area.

I was saying nbody because I thought someone said it reduced some calculations per part in relationship to ships and gave higher parts count.

Edited September 8, 2020 by Arugela

[Incarnation of Chaos]

13 hours ago, Arugela said:

I wonder if they will back port that into ksp1. I had a similar idea about letting users define such things in the vehicle area.

I was saying nbody because I thought someone said it reduced some calculations per part in relationship to ships and gave higher parts count.

Even if you could, you would break compatibility with all other KSP versions potentially. One of the main reasons they're making KSP2 however is because the code from KSP2 is not weighed down by the years of dependencies and cruft that KSP is, and these might very well prevent a backport of the feature to KSP1.

There is plenty in the meantime that could be done to further optimize KSP1, but at this point I'm not even sure if SQUAD has the staff on hand. They seem to be in maintenance mode, rather than actively developing major features/changes to the game's core code. This would imply to me that anything of this magnitude is unlikely, but stranger things have happened in games.

As for the last one...

You'd have to give me the link (Unless it's that paper), because N-body isn't anything to do with calculating the interactions between parts. It's calculating interactions between massive bodies like planets, asteroids, and stars, with the vessel physics being somewhat separate. I say "Somewhat" because there is one case i could think of, which is where the craft is being pulled by multiple bodies. In an N-body simulation, this would just "Emerge" from the fact that the code is simulating how such a situation would play out IRL. Where in a Patched Conics Approximation, it would require special code to handle.

But KSP doesn't deal with such situations at all, since it uses "Spheres of influence", and treats your ship as always being dominated by the influence of one gravity well. So i don't see that happening for KSP. KSP2 would have a situation like this at Rask and Rusk, but we'd have to see their solution there before calling it either way.

Edited September 8, 2020 by Incarnation of Chaos
Flubbed the Enter Key