Reinvent the parts physics system?

[CiberX15]

This is probably something the devs have already thought of but I can’t help wondering if they need to move away from a real physics system for the parts of the craft.

I’m very familiar with Unity, the engine KSP 2 and 1 are made in, having been working on a heavily physics based game myself for the past three years. And one thing I ended up doing on my game was moving away from physics sims in favor of scripted control when needed. Basically it’s the difference between trying to puppeteer a ragdoll vs simply animating an object.

Both sides have their advantages and disadvantages, but it’s possible to milk the best out of both worlds.

KSP 2 is clearly using real physics sims for all of the rocket parts connected to the rocket, and this is what causes the vast amount of bugs and performance issues in the game. Thousands of parts needing to be physically simulated while also colliding with each other, slowing the game down when they aren’t shaking the craft apart colliding with other parts of the ship.

If all the parts were not individually simulated but instead all grouped into a single rigidbody (the component that tells the engine to simulate physics for a given object) then only a single calculation would need to be run per ship. Literally hundreds or thousands of times easier for the computer to process depending on the part count of the craft.

This would be extremely stable, but also, perhaps a bit boring. While I tend to land on the stiffer side of the wobbly rockets debate, I do actually prefer some wobble. Not in craft that look like they should be stable, but when I build a giant noodle, I expect it to physically behave like a giant noodle.

This is where you can get into faking it with scripted physics though. Instead of actually physically simulating every part, feed the forces into a script that makes them bend on their connection point based on how much force there is. 

For example, if the ship is turning, X amount of force is delivered in a given direction to a given part. The part would bend at its connection point. So at its base, or around a radial decoupler etc. Parts connected to that part would move with their parent and similarly bend from their connection points.

Because this bend would be scripted though, it would be much easier to modify stiffness, making it completely rigid or complealty noodly as needed, without having to auto strut, which has a performance cost of its own. Since each of the components would have this script, they could be individually updated at runtime based on how big the ship is, to scale how noodly the ship is depending on how long it is. So stouter craft could be completely rigid, but noodles would flex as you might expect them too. This could even read from a setting in the options so that player’s could globally increase or decrease wobble based on their preferences.

The bend could be scripted to never exceed a given angle, or break if it does exceed that angle, and that could be set on a per part level depending on how strong the part should be. Fuel tanks for example might never break but could flex to a given degree, whereas long antennas could flex then break off under too much force.

The individual parts could also have their own rigidbodies but it’s set to kinematic (a mode that lets objects individually detect collisions but don’t get simulated and thus don’t eat as much performance). This would let the part detect when it’s colliding with something else and take damage on a per part level, and also pass that collision data back to the root rigidbody so it’s affected by the collision too. (Though there is a setting in unity that I believe is disabled by default that needs to be flipped on to allow child game objects to receive collision)

Such a system would be a major MAJOR overhaul, but I think long term it would solve a vast number of the issues KSP 2 has been plagued with, in addition to the future problems they are already talking about running into when dealing with much larger craft.
 

[DailyFrankPeter]

Not sure this isn't over most people's heads on this forum  - if not your idea itself, then the understanding of what's already in the core game, or planned in the future, optimisation-wise. 

Maybe you can email the new tech lead. 

Also... you and I both know what happens when you say the words 'major overhaul'.

Edited January 21, 2024 by DailyFrankPeter

[kdaviper]

I know that in the Dev chat about wobbly rockets they said they are looking into long-term solutions as well. 

[Lowi_Sace]

Could be a good solution. Maybe could be coupled with a stress and strain system.

 

8 minutes ago, kdaviper said:

I know that in the Dev chat about wobbly rockets they said they are looking into long-term solutions as well. 

Yeah, they said they were testing different long time and short time solutions (like rigidbody). Considering the complexity of the game and the fact that the system needs to work for a lot of vehicle combinations, I think we will be stuck for a while with the current system.

[steveman0]

I am half-suspecting they might be considering or even working on something like this. Given how they've talked about some of their goals for larger ships and colonies, I suspected they have something in mind for a kind of physics LoDing that would involve something like this kind of abstraction of the parts to simulated component sets. From a scalability point of view, it's the most sensible solution.

[DailyFrankPeter]

On 1/22/2024 at 4:22 AM, steveman0 said:

abstraction of the parts to simulated component sets. From a scalability point of view, it's the most sensible solution.

If you mean grouping into sets, which are simulated as a whole, then that's the first thing I would also do.

There's some real-world intuition behind it, too:
- for example a long truss may be assumed to be one piece (it's not built from cubes IRL*) and only connections between it and whatever is at either end simulated;
- similarly for some other 'homogenous' groups
- small items, like RCS, attached to large parts like tanks do not have to be simulated, because it is the fuel-tank-to-rest-of-rocket joint that gets the most bending force;
- or if there is some impact powerful enough to rupture the fuel tank, it also doesn't matter how strong the small attached part was

So there's definitely some opportunity to skip simulation. There could be a list of pairs of object types for which joint simulation does not matter.


---------------------
*well, it is from triangles, but we can assume engineers have done a good enough job to make it stiff enough to look like 1 piece

Edited January 23, 2024 by DailyFrankPeter

[pg17]

4 hours ago, DailyFrankPeter said:

for example a long truss may be assumed to be one piece (it's not built from cubes IRL*) and only connections between it and whatever is at either end simulated;

That is exactly the kind of cases that calls for more procedural parts. It would need to be balanced with a max length set around the point where it is considered too long to not have a noticeable or expected bent (at that point you have to really assemble two truss together and compute the joint).

That being said, I second the idea of having some sort of sub assemblies with approximated simulation in specific steps. Especially payloads like satellites or rovers secured in a closed cargo bay during takeoff. I think they could be approximated as a single block with proper mass & CoM without losing too much. But it's hard to say without knowing exactly what happens and what kind of computations are done under the hood. For really complex systems like physic simulation, I tend to trust (hope?) that the dev team already thought of such simple optimizations. So, it is either that they had a good reason not to implement them, or it is already in development / planned.

[Jeq]

currently i dont find any other problems with physics than when doing extra large rockets, their boosters doesn't keep attached, detaching before players gets see launch pad. And ROVERS!

Edited January 24, 2024 by Jeq