Performance enhancing mod idea:

[t_v]

I know this comes across as an ignorant move as I am asking someone else to consider developing a mod while I am unwilling to do it myself, but I was thinking about a mod that could reduce CPU load for large stations in vacuums. If you disabled the collision detection for individual parts but created a collision box for the station as a whole, treating it as a single rigid body until something touches it, it could cut down on a lot of computation. One inaccuracy that occurs here is that the inertia of the parts are computed as one spherical mass so some of the fancy effects that occur from having weird shapes spinning around would disappear but for most large applications, instead of checking each part for forces it would only check one big "part" for forces without necessarily combining the modules. What do you think?

[zer0Kerbal]

welding mod is the answer, unfortunately is isn't working in 1.12.x; @Lisias might be able to shed some light on it.

[Lisias]

Welding is an alternative, yes, but not exactly the answer the OP is looking for. (not to mention that the thing is not working fine on modern KSPs - besides you still can weld parts on older ones and then migrate the welded parts).

What he means is tricky, but can eliminate the need for the welding tool for some use cases, i.e., when you don't mind the physics when no collisions are possible, but want them back when they are possible - once you weld parts, you lose the ability to explode only one part, you lose the whole shebang.

What follows is pure brain-storming, without too much care about feasibility. This may not even be the right way to go, but this is why we do brainstormings - ruling out bad ideas before trying them is also a help.

On KSP, there's a thingy called "Physics Significance". Part without Physics Significance don't generate drag, for example - perhaps it could be possible to dynamically set all parts of a vessel (but the root) to have no Physics Significance, while giving the root part a spherical "soft collider" those radius cover all the vessel. Once the "Soft collider" is hit, instead of blowing things up, it would trigger a code that would restore the vessel original state and remove the "Soft Collider".

I'm not exactly sure how then Physics Significance works - we need to do some research on the matter, and we need to check if we can change it on a living part - but I think this can be promising...

[Hohmannson]

1 minute ago, Lisias said:

this can be promising

Not too much, it was tested and no significant improvements.

 

 

15 hours ago, t_v said:

it would only check one big "part" for forces without necessarily combining the modules

Seen a mod like that, but it does it for landed vessels only and it's in proof-of-concept stage and it patches core game's libs so won't post it. Look for a mod that puts physics on hold in Google. Coding practice will still be needed to make it work in orbiting and suborbital situations. It offers visible improvements when you activate it on large ground bases, it's very promising.

[Gotmachine]

On 9/25/2021 at 10:26 PM, t_v said:

If you disabled the collision detection for individual parts but created a collision box for the station as a whole, treating it as a single rigid body until something touches it, it could cut down on a lot of computation.

First, rigidbodies and collisions are two separate, mostly unrelated things. Collision detection is done through collider meshes, that might or might not be part of a rigidbody. The amount of colliders has almost no performance impact in itself, as long as no collisions happen. Arguably, it incurs a small cost when a raycasting call is being made (solar panels and radiators for example). What is CPU heavy is the rigidbodies constraint solving, or said otherwise, part joints.

On 9/25/2021 at 10:26 PM, t_v said:

for most large applications, instead of checking each part for forces it would only check one big "part" for forces without necessarily combining the modules. What do you think?

While the idea make some sense, the implementation would be a nightmare. The "default" physics state is just too deeply relied upon by too many pieces of stock code, and even if we were able to patch everything, that would still cause tons of issues with mods.

On 9/26/2021 at 2:12 PM, Hohmannson said:

Not too much, it was tested and no significant improvements.

In retrospect, I think PrunePhysics just isn't working (it isn't actually setting parts as physic-less parts), that's why we didn't ever see the slightest performance improvement.
Since then, I've done quite a few tests on that front, and yes, actually setting that state can result in non-negligible overall performance improvement, up to 30 % with high part count vessels (500+ parts) when physics are the main thing running, but more realistically in the 10-25 % range in general.

On 9/26/2021 at 2:01 PM, Lisias said:

I'm not exactly sure how then Physics Significance works - we need to do some research on the matter, and we need to check if we can change it on a living part - but I think this can be promising...

Physics significance works by parenting the part gameobject to its "KSP hierarchy" parent gameobject and removing its rigidbody and joints, which cause Unity to directly update the child position/rotation, instead of calling the PhysX solver.
Theoretically, if you set it on all parts beside the root part, you end up with no joints at all, and a single rigidbody (the root part) whose mass is the sum of all the vessel parts mass.
In practice, this doesn't work because :

• This mean that the vessel CoM becomes the root part CoM.
• The mass summing isn't entirely reliable (not investigated much, but it likely ignore IPartMassModifier modules)
• Almost everything that attempt to provide forces/torques like atmospheric lift, engine thrust or attitude control (reaction wheels, RCS, control surfaces) will be heavily borked.
• This breaks tons of things that rely on individual rigidbodies to exist on the part : wheels, legs, docking ports, robotics to cite a few obvious ones
• This completely breaks the stock landed checks and landed easing code.

In short, there are just too many corner cases to attempt to apply that globally without causing tons of bugs and game-breaking side effects.

On 9/26/2021 at 2:12 PM, Hohmannson said:

Seen a mod like that, but it does it for landed vessels only and it's in proof-of-concept stage and it patches core game's libs so won't post it. Look for a mod that puts physics on hold in Google. Coding practice will still be needed to make it work in orbiting and suborbital situations. It offers visible improvements when you activate it on large ground bases, it's very promising.

Yep, that's mine : https://github.com/gotmachine/PhysicsHold
It takes a different approach, relying on the fact that KSP already provide a "physics disabled" mode in the form of the "packed" vessel state that is used during (non-physics) timewarp. The mod just force-activate that mode when you don't timewarp.
On the technical side, this is a very different. The "packed" state change the state of all rigidbodies to "kinematic", essentially disabling all PhysX force/torque/joint interactions on them. In that mode, KSP also put the vessel "on rails", updating every part position/rotation manually instead of letting the joint physics do the job of keeping them in their place.

Performance wise, it's a bit less efficient than the "physics significance" trick (directly parenting the gameobjects), but very comparable. Since it's a default KSP state, KSP (and most mods) handle it correctly in most situations, the main "hacks" in my plugin are because I'm enabling EVAing/boarding,  docking/undocking and partially enabling physics for robotic parts when the vessel is on physics hold, which are scenarios that weren't provisioned for in the KSP code (but making them work is relatively easy). The huge advantage of this solution is that it doesn't change fundamentally the state of the parts : rigidbodies still exist, their mass and physical stats are still computed.

This being said, the plugin only applies to landed bases, because things can get a bit more complicated in other situations :

• Kinematic rigidbodies can only collide with non-kinematic rigidbodies. This is a well known effect seen in stock when timewarping, with vessels passing right through each others. However, kinematic rigidbodies will collide with non-kinematic ones. This mean that for a landed base, setting the packed state isn't an issue, since two bases relative positions are fixed (so they won't ever collide), and things that can move (rovers for example) will collide with them just fine. However, this is definitely an issue in space, where two packed vessels can collide with each other. This is the main reason why I only did this for landed bases. Still, this is an issue that could be worked around, either by naively re-enabling physics when a collision is about to happen, or by a more complex implementation that handle collisions manually.
• Packed vessels are "on rails" and are essentially unmovable, be it for attitude control, thrust, or reacting to collisions. These are all things that could be re-implemented, but that would require a significant effort.
• There is a problematic issue with setting the packed state on the active vessel if other non-landed vessels are in physics range, causing those vessels velocity to be reset to zero. The workaround is likely to be a bit difficult.
• This can't work for rovers, due to them relying on wheels physics.
• This can't work for atmospheric flight.

Edited September 30, 2021 by Gotmachine

[t_v]

I see. Thanks for the huge insight to the physics engine. The main use case for this theoretical mod would be to build orbital stations that could run well, large enough that there would be no real reason for attitude control or thrust. Initially I was thinking of making something that fused the structural parts together and made their joints rigid so that you could build large platforms that act as one plate of metal or a truss that goes the entire length of a ship that doesn't need to compute deformation because it acts like one gigantic part. But the wider use case of generally removing physics from parts is also a good one. 

5 hours ago, Gotmachine said:

Packed vessels are "on rails" and are essentially unmovable, be it for attitude control, thrust, or reacting to collisions. These are all things that could be re-implemented, but that would require a significant effort.

That is probably true and I don't know nearly as much as you about this, but if vessels are packed like this, what trickery does the "persistent thrust through timewarp" feature use? Could it be ported over to allow for thrust, provided that you activated engines before packing the vessel?

5 hours ago, Gotmachine said:

Kinematic rigidbodies can only collide with non-kinematic rigidbodies

so as far as I understand this, the packed vessels are kinematic rigid bodies and the unpacked ones are non-kinematic, and they will collide fine. But if you take two packed vessels, they will not collide? I'm not sure if this is the correct interpretation of that, but if you had a small unpacked spaceship, it could collide with the rigid body that is the packed station. At that point, it would function the same as a landed base, right? The problem comes if you are colliding two packed vessels because they clip through each other. That is a problem I personally am ok with because at the point that I need to pack a vessel, there is no reason it should dock to another packed vessel because it has everything it needs already. 

 

5 hours ago, Gotmachine said:

There is a problematic issue with setting the packed state on the active vessel if other non-landed vessels are in physics range, causing those vessels velocity to be reset to zero. The workaround is likely to be a bit difficult.

yeah, this seems like a pretty major issue. I don't know why it would do that, considering that time warping while within range of another vessel does not cause it to instantly drop from orbital speeds to stationary, but I'm learning to mod and I might be able to come up with something. 

 

also, your mod looks really cool. I see that it is updated to 1.12! I'll try it out as soon as I have a surface base to be proud of. Good luck!

[Gotmachine]

15 minutes ago, t_v said:

what trickery does the "persistent thrust through timewarp" feature use?

If you mean the persistent thrust mod (there is no such feature in stock), that's what I mean by "significant effort". That mod is quite a large piece of code, and is far from working correctly in all situations. But to be clear, I wasn't saying it's not doable, just that it would require a lot of work and debugging, and that this is advanced stuff that require a good understanding of KSP internals.

20 minutes ago, t_v said:

That is a problem I personally am ok with because at the point that I need to pack a vessel, there is no reason it should dock to another packed vessel because it has everything it needs already. 

Yep, this is indeed a minor limitation that can be worked around relatively easily.

45 minutes ago, t_v said:

I don't know why it would do that, considering that time warping while within range of another vessel does not cause it to instantly drop from orbital speeds to stationary

Well, when timewarping, all vessels are packed. Here we introduce a situation where some vessels are packed and other aren't. I suspect it has to do with the floating origin system and the frame velocity becoming null when the active vessel is being transitioned from the in physics to packed state. This can be probably be worked around, but identifying and understanding the exact issue will likely be a bit tedious.