A minor improvement to the PhysicsSignificance flag

[Grumman]

At the moment we have a number of parts which are treated as massless and dragless. This is obviously unrealistic, and can be exploited.

My suggestion is to sum the combined mass and drag of every part with PhysicsSignificance = 1, and treat it as a point mass and point drag at the ship's own center of mass. This would keep the benefits of simplifying the physics calculations and keeping the axis of thrust in line with the center of mass, but would cause a large number of currently massless parts on a small probe to actually increase its inertia and drag as one would expect.

[Warzouz]

I was thinking about that. This is a very good idea. Many lightweight parts could be added to the center of mass. It would have to be recalculated each stage, decoupling or undocking.

The drag aspect could have issue with the new aerodynamics, but at least the weight part could be easily handled.

[Keldor]

It would be even better to just have physicsless parts add their mass to whatever they're attached to.

[Fel]

At the moment we have a number of parts which are treated as massless and dragless. This is obviously unrealistic, and can be exploited.

My suggestion is to sum the combined mass and drag of every part with PhysicsSignificance = 1, and treat it as a point mass and point drag at the ship's own center of mass. This would keep the benefits of simplifying the physics calculations and keeping the axis of thrust in line with the center of mass, but would cause a large number of currently massless parts on a small probe to actually increase its inertia and drag as one would expect.

Let me first say that I am NOT a math major; I am an experienced "generic programmer", but I am not one who has the experience for what I am about to say.

Now, how KSP currently works is an applied force to one part of the ship propagates to other parts, usually via connection nodes. For the greatest accuracy, you would first have to calculate each and every force change for each part at point and then add that force change back in... then act upon the physics. What likely happens is physics is serially or semi-serial (even 16 cores won't calculate every calculation at once) and acted upon after that calculation, the force propagation isn't entirely accurate and requires a recursive approach which feeds back force data to other parts.

There is another method. You can use a matrix to model the entire ship. This gives easy SSE capable code and allows one to write an algorithm to reduce the matrix and make it even faster. Does a part weigh only 0.01T and the ship weighs 100T? That is an entire line of calculations that would need to be done for either method, but can be removed as "physically insignificant".

Basically, we can turn these calculations into something more sparse which also has methods of greatly improving calculations on a computer.

Of course, there are issues with simply doing it straight forth; (i.e. a single matrix with a set of "dampening" + angle). That would assume a fixed structure that is non-changing. For the most part, we WANT to use a single calculated matrix the whole way through, but we can also improve the model by adding on state variables. We can optimize this by considering what is "physically insignificant" so that we aren't calculating the effective change due to the energy held by a decoupler.

What I'm getting at is while changing the COM might be fairly simple, just to get small parts to act right... this is really dependent on SCALE. A 1000T single-stage rocket isn't going to care about the 5T can you put on top. At the same time that can becomes much more significant at 100T or even 20T. I could be over complicating things, we could use mass ratios and adjust the COM... but I also think that, physically speaking, there is a lot a hard core mathematician could do to optimize while maintaining general assumptions that don't result in too much inaccuracy.

[Azimech]

@Fel

A large part of the fun of playing KSP is that a vessel is treated as a "collection of parts flying in close formation". Otherwise it would just be a (bad) Orbiter clone.

A 1000t rocket won't care about the 5t on top, but the 5t on top cares about itself and the forces that act upon it.

[Fel]

@Fel

A large part of the fun of playing KSP is that a vessel is treated as a "collection of parts flying in close formation". Otherwise it would just be a (bad) Orbiter clone.

A 1000t rocket won't care about the 5t on top, but the 5t on top cares about itself and the forces that act upon it.

What I'm describing is "complex if you've never done it before" math... with "even more complex if you haven't done it before" enhancements.

Put simply, although the 5t mass cares about the forces acting upon it, it is fixed to the 1000t.

In a stateless system (my initial explanation) you get the bad orbiter clone... the assumption being held is that the joints are unbreakable and the parts do not move independent of the whole.

In a state-wise system, my second explanation, you get KSP.

The difference is that now you're using some very complex math to make a model and using optimizations to make your matrix more sparse. So the actions of the 5t upon the 1000t might be removed (or, more accurately, the actions of the 5t load upon the engine, or other parts far enough away as to have a very small effect that can be ignored)... but the actions of the 1000t mass pushing the 5t mass ARE calculated.

Well, they'll be calculated unless the mass is ductaped on with space tape and the effects of the state-variables are negligible. (Basically, initial assumption, the part doesn't move and the joints are unbreakable).

This matrix would have to be calculated each time a change occurs (i.e. losing a part, or manually changing flows), but for every frame that no change occurs it could improve how fast the physics calculations occur.

Of course, yes... in the end you start sacrificing accuracy here and there for speed. Oddities can easily pop up when you're not directly calculating something and instead relying on a model; and implementation would be hell and any speed gains would be highly dependent on how well implemented it was.

Just insanity for thought.