On-the-fly aerodynamics vs. pre-generated models

[pincushionman]

I've been thinking about aerodynamics.

Now, I'm not an aerodynamicist. I'm an aerospace engineer, yes, but my focus is in structures. When we got to the Navier-Stokes equations my brain turned inside-out. So I'm familiar with it, but it's not my area of expertise. So keep that in mind, and if I'm blatantly wrong about any of this, feel free to correct me. That's why I'm posting this, after all.

Anyway, the way I understand it, KSP does physics calculations on a per-part basis; this includes aerodynamics. Each part contributes a drag (and/or lift), and then the forces are added to the system that is the craft.

In normal flight simulators, a set of aerodynamics parameters are pre-generated based on conditions such as altitude, speed, and angle of attack; these are used to calculate forces and moments which are applied to the aircraft object as a whole. This means you only have to do it once per craft, but it does mean you need those parameters generated beforehand.

Now...would it be possible to pre-generate such parameters for a craft in KSP? I know the per-part lift and physics calculations offer a great deal of flexibility in dealing with craft of arbitrary configurations...but let's be honest, for 99.9% of any flight, the configuration of your craft is well-defined. And for "normal" flights (those that don't have a crash or an explosion, the changes to the configuration are well-defined, too (staging breaks the craft into well-defined sub-parts). When a craft is built, could a dedicated "calculate-aerodynamics" function be run on it prior to launch to generate the proper parameters tables and determine how to spread the resulting forces about the craft (for each stage)? It would reduce the load on the physics engine by taking away the need to do the per-part calculation every frame. It would also allow for more advanced occlusion determination because it wouldn't be time-sensitive, and could take the time to unionize the part primitives into a proper mesh or whatever.

Is what I'm pondering making any sense, or do I have a complete misunderstanding of the aerodynamics calculations needed and the particular environment of KSP in the Unity engine?

[rkman]

In normal flight simulators, a set of aerodynamics parameters are pre-generated based on conditions such as altitude, speed, and angle of attack; these are used to calculate forces and moments which are applied to the aircraft object as a whole. This means you only have to do it once per craft, but it does mean you need those parameters generated beforehand.

Not sure if i understand it correctly, but given that altitude, speed, and angle of attack etc constantly change during a rocket's ascent, would that not be a whole lot of calculations to do beforehand?

[vexx32]

You are correct. In addition, since crafts can (and frequently do) break apart in KSP, that sort of model would have lots of trouble dealing with a craft when it starts to crash. While it is the most efficient way to have those kinds of calculations work properly, it wouldn't be optimal for KSP's way of doing things -- rapid assembly and disassembly of craft.

It would also have to recalculate those things on the fly if you tried to dock something and then reenter the atmosphere with it, and in myriad other situations. Having those things precalculated seems fraught with issues for a game like KSP.

[Tuareg]

You are correct. In addition, since crafts can (and frequently do) break apart in KSP, that sort of model would have lots of trouble dealing with a craft when it starts to crash. While it is the most efficient way to have those kinds of calculations work properly, it wouldn't be optimal for KSP's way of doing things -- rapid assembly and disassembly of craft.

It would also have to recalculate those things on the fly if you tried to dock something and then reenter the atmosphere with it, and in myriad other situations. Having those things precalculated seems fraught with issues for a game like KSP.

except that the way is always there to switch back to per part calculations when the craft reaches breakingpoint...

[rkman]

Isn't the breaking point determined by per-part interaction, thus requiring per part calculations to find whether or not the craft reaches breaking point?

[Tuareg]

Isn't the breaking point determined by per-part interaction, thus requiring per part calculations to find whether or not the craft reaches breaking point?

And you cant save the weakest joint as the breaking point of THE CRAFT, and if there is a force bigger than that you check if it was THAT JOINT or not?

[Jouni]

And you cant save the weakest joint as the breaking point of THE CRAFT, and if there is a force bigger than that you check if it was THAT JOINT or not?

That probably happens in every frame when the engines are on.

[GoSlash27]

It would seem to me that you could save a whole lot of flops by calculating it out once, then checking for changes. So long as part count and config remain the same, the aero model in use is retained. When a change is flagged, it would recalculate.

This would not only work better for stable designs, but would also work better for explodey designs.

Best,

-Slashy

[Tuareg]

That probably happens in every frame when the engines are on.

nope. forces are vectors not numbers...

[Xaiier]

Aerodynamics calculations do not take up a significant portion of the processing load. There is no need to consider outlandish solutions to solve a problem which doesn't exist.

[Jouni]

nope. forces are vectors not numbers...

Many rockets have small parts radially attached to them. If you direct the entire thrust to that part, the force is perpendicular to the joint and probably strong enough to break the joint. I'm not if that was what you meant, but at least it's a valid interpretation.

In general, precomputing is useful if you can predict future situations in advance. If you have a rigid single-staged rocket or a linearly staged rocket, that's probably true. If you have a KSP rocket or action groups that detach parts (e.g. fairings or payloads), the number possible future situations grows much larger.

It also depends on the hardware you assume people having. If it's a gaming PC, you're out of luck. If it's a decent computer with 8+ fast cores and 32 GB of memory, you can probably use a few cores for precomputing possible futures, and a few gigabytes for caching the results.

[Tuareg]

It also depends on the hardware you assume people having. If it's a gaming PC, you're out of luck. If it's a decent computer with 8+ fast cores and 32 GB of memory, you can probably use a few cores for precomputing possible futures, and a few gigabytes for caching the results.

sure. i love these, i dont know what am i talking about but i pull some numbers out of my... posts. worth it... this thing is all about save resources not to use more...

[Jouni]

sure. i love these, i dont know what am i talking about but i pull some numbers out of my... posts. worth it... this thing is all about save resources not to use more...

Saving resources is only worthwhile, if you can use them for something else. If you don't use the unused memory and CPU cores for something else while playing the game, you're wasting them.

There are basically three ways to use precomputed physics in KSP:

1. Precompute only what is needed. This saves a lot of memory, while causing significant delays during staging.
   
2. Precompute everything in advance. This uses a lot of memory, while causing huge delays before launch.
   
3. Precompute things in the background. This uses a lot of memory (but less than approach 2) and a lot of CPU power, but there are usually no delays during the game.
   

Approach 3 is generally preferable, because long delays are kind of annoying.

[NathanKell]

Modeling the craft as a single body leads to much better aerodynamics, but you need a way of getting (and then simplifying) the mesh of the whole craft as a convex hull--and then you need to be able to do it so fast there isn't a "lurch" when you decouple a stage.

[pincushionman]

Modeling the craft as a single body leads to much better aerodynamics, but you need a way of getting (and then simplifying) the mesh of the whole craft as a convex hull--and then you need to be able to do it so fast there isn't a "lurch" when you decouple a stage.

I would think the obvious place to do that would be the build scene, when there aren't any other physics to contend with and it isn't time-sensitive. You'd generate appropriate sets for all the stages at that time (since again, staging part splits are well-defined). The question then is how much extra memory that would take up compared to the rest of the craft data you have to load.

...And it also leaves us with RUD situations. I don't think it would be a good idea to attempt to predict those too heavily. But if it were possible to separate such calculations enough from the rest of the physics they might be thrown over to their own thread, you could maybe fall back on the per-primitive calculation method long enough to calculate the new matrices in the background. It's not like major part breakage doesn't cause major control issues all by itself. You're usually screwed anyway.

But that said, I don't have any idea how quickly such matrices can be generated using any method, nor do I have any idea how much flexibility in thread handling Unity offers.