Craft dynamics proposal: deformation

[sshilovsky]

General discussion thread
So @audigex has suggested this idea on discord (slightly detailed by me while i'm typing):

KSP models craft dynamics entirely per-part, with joint forces between parts. This model while being flexible turned out to lead to craft wobbling visibly, up to being torn apart by Kraken without particular reason.

The suggestion is to calculate dynamics for the craft as a whole then, with gravitation, thrust and other forces applied to it as to a single body. One of the features needed though is the craft to be able to crash under some circumstances:

• Sudden acceleration due to landing or diving into liquid on speed

• Being torn apart in the atmosphere due to air drag

• Other reasons, not dynamics-related, but we really only address dynamics here

We can calculate overall craft durability properties and when the forces applied are big enough, start virtually deformating the craft. Say, we can accumulate some deformation(damage) property, while deformation is still resilient, and when some value is reached, we can initiate the process of destroying the craft part-by-part. UPD: it is supposed that when severe conditions are over, resilient deformation is cancelled, i.e. damage is nullified.

How can we model this deformation from physics point of view? How does it relate to craft size? Can we ignore craft shape in this sense, or do we have to track deformation per-part when it becomes applicable (i think we have to)? Do you come up with some other deformation model?

We also need to find which part gets destroyed at the given moment. E.g. when lithobraking, should the bottom part break first, or some other part in the middle of the craft which has the lowest resilience? Does this depend on the distance from the point of collision to the craft? Does this depend on direction of the force applied? How can we model this all? UPD: as stated above, we probably don't want to model all the forces between parts; but can we somehow know in advance which part of the given craft gets destroyed first?

While we're on our way to decide on dev environment, we could investigate into this model and check if it makes sense from the physics point of view. We can create a 2D or 3D app to test particular deformation model and see how it would look like.

[audigex]

This is, to me, something where it's very much a concept, rather than something I truly understand. But basically my thought is that we should aim, in a "best endeavor" sense (ie it's an idea, not an ideology) to act on the craft, rather than the individual parts, wherever possible.

The aim is to reduce kraken-like behavior, and also improve performance by not having to analyse and recalculate everything for every part constantly. We can instead run calculations about centre of lift/mass etc regularly for the craft, and then perform acceleration/force calculations against these results, on the assumption that things aren't changing every tick. We can reduce CPU cycles, and remove silly kraken-like behavior (although we may want to later add in some of our own... in a more controlled sense)

Some things are unavoidably part-based: collisions, bounding boxes etc - but others can be reduced significantly by combining parts and calculating things like the centre of lift for groups of parts: akin to some of the part-welding mods in KSP, but more dynamically.

The idea is not to start over-simplifying craft into a basic arcade ship, but instead to reduce the number of parts we are calculating against and acting on. We may use all parts, for example, to calculate the rolling moment, but that rolling moment is applied to the craft, rather than to individual parts.

This particularly applies to forces such as gravity: if an orbital body is acting on the craft from 1000's of KM away, there's little need to apply gravity to the individual parts: instead we can work only with the mass and location of the whole craft, and accelerate the whole craft. Similarly RCS and reaction wheels can act on the whole craft, as long as we've already calculated that the forces generated are within tolerance of the structural strength. No more kraken wobbling.

Something of a hybrid approach, I guess.

This also means that some aspects (structural integrity) can be pre-calculated, and then we only have to act upon them when limits are exceeded: if we already know the weakest points of the craft, we don't have to recalculate the physics for each part every tick: we can instead focus on the areas in question. We can also provide more useful information to the player.

Thanks for bringing up this topic. I've been musing about solar system and planet modeling, but this is equally as important; figuring out the physics and modeling of craft crashing into planets, atmospheres, and among themselves.

I think @audigex expressed the initial thoughts I had exactly, and more eloquently. Also, just by way of thought experiments, I don't see how you get around a per part based model when a full on collision is taking place. So I think we're all aligned in our thinking.

I will comment about an edge case @sshilovsk brought up. Will a lesser resilient part break first when a craft is being stressed, even if it is in the middle of the craft? The example of lithobraking was brought up. I like to think about dropping a rover on mars with protective bouncy balloons. My hunch is that you just say outside parts feel stress forces only. That way, the calculations are simplified. I think you still pull off some very convincing collisions/explosions like that.

[AlphaMike741]

If we add "fidelity levels" we can even handle several distant active vessels or a lot of stationary crafts in close proximity as well . Which means Huge off-world colonies and SpaceX Style missions .

[leocadle]

Possibly one problem you might come across is the collision mesh. You would have to generate a collision mesh on the fly that approximates the shape of the craft, while not really knowing what that shape is. I know FAR uses voxelization to determine the shape of the craft for aerodynamic calculations, and you would need to do something similar.

[CrazyPyroEagle]

Joint damage could be simulated by calculating how much structural stress is being applied to a joint. The stress would come from the relative force between the joint parts (aerodynamic drag, thrust, etc.), as well as the torque being applied to the spacecraft. From there, it's a matter of figuring out how to calculate how much the difference in force should affect the joint.

Suppose that the joint vector is a unit vector whose direction is from the parent's to the child's centre of mass. We could use a dot product between the relative force and the joint vector to calculate how much the force stretches or compresses the joint. Each joint would have a known range (within which 0 is included). If the dot product is outside of the range, the joint breaks.

In other words, we'd calculate how much the joint is being stretched or compressed. The range would be defined as the stretching and compressing limit of the joint, beyond which the joint breaks.

This model still lacks the concept of torque and part stress, but it can be improved to include them.