Overhauls for 1.0

[Claw]

Fellow Kerbonauts,

There has been a lot of discussion about all the aerodynamic and thermodynamic changes within KSP 1.0. It makes me pretty excited to see all the discussions about what works, what doesn't, and people figuring things out.

However, there's been a trend on the forum the last few days that seems to be leaning toward animosity. Aerodynamics in particular has always been a polarizing topic between the "realism" crowd and the "fun gameplay" crowd. For me personally, it has never been a question of which should win out: Realism or Gameplay. There is simply no possible way to achieve the perfect blend of realism and gameplay that satisfies every single player.

I would sincerely like to point out that the beauty of this forum is that we all come together to understand difficult and complex concepts that have been boiled down to a relatively simplistic (and ideally understandable) representation in KSP. Accomplishing this is no small feat, and can be quite the challenge to balance while maintaining some level of realism and gameplay. To me, this community has always been incredible because of it's willingness to help each other.

So I thought perhaps, instead of having yet another thread that goes back and forth about how the game does or doesn't meet your expectations, I would try to explain a bit about how complex the new aerodynamic and thermodynamic system is, and just how big of an undertaking the system has been up to this point. Perhaps that will lend some insight as to why finding a good balance is quite difficult. This isn't meant to be a "defense of the system" sort of post, but more of an attempt to explain how the system works, to the people who love (and hate-to-love) this game.

 

---

---

Basic Drag:

• The basic drag system for most parts is based off of a cube system. Every time KSP starts up, it looks into the PartDatabase.cfg file and checks for all the cubes. If a cube doesn't exist for a part, then KSP generates a drag cube for that part and stores it in the database.
  - This has the advantage that you can (generally) look at the shape of the part to figure out what will be less draggy and what will be more draggy.
  - However, this also causes issues with hollow parts (such as cargo bays) which have incorrectly built drag cubes.
  - Parts can also have drag cube multipliers, to adjust the size of the drag cube if the model shape is insufficient to really define the drag.
• Physics.cfg contains several curves in it. One set of curves (tip, surf, tail, mult) controls the level of drag that the cubes produce, by cube face. KSP uses these curves to build a profile curve that is used to calculate the weight of drag that each face contributes to that part. The cube face that points into the wind uses tip * multi, sides use surf * multi, and the back face uses tail * multi (in simplified terms).
• The multiplier value is (in essence) a standard drag profile from subsonic through high hypersonic (in KSP's case, Mach 0.0 through Mach 25.0). This includes the supersonic drag rise in the transonic region, which for KSP is Mach 0.8 to 1.2 (270 - 410 m/s).
• Part occlusion is accomplished only through node connections. Parts that are connected to other parts via nodes have the size of that cube's face reduced by the size of the parent/child part. So surface mounted parts are not occluded from drag. (This is why stuff built with lots of things hanging off suffers a lot of drag.)
  - Because of how drag cubes are built, open ended model parts can cause problems. Not all of these parts were adjusted to account for this, which is why there is some imbalance.

 

Basic Thermo:

• Builds off the drag cube system to calculate how much of the part is exposed to the air. This basically sets up how much friction the part is going to experience.
• Thermo also includes simulation of shock cone occlusion, which deflects heat based on the part that's out front. This is why the location of surface mounted parts matter. Put them too far forward, and they hit all that heat. Put them too far back, and the forward blunt body doesn't provide shock cone occlusion anymore.
  - Balance for this is also tricky, so as to provide occlusion for parts when it makes sense, but not block all heating for the entire craft by mounting an antenna out front.

 

Basic Lift/Drag for Wings:

• Wings (more specifically, lifting surfaces and control surfaces) are handled separately from all the other parts in terms of drag.
• Wing lift is based on two curves, a Maximum Coefficient of Lift based on Mach, and a Coefficient of Lift based on Angle of Attack.
  - Wing lift is based on the V-Squared drag model, but is also scaled by the Cl-Mach curve to account for different levels of lift based on flight regime. Building a system this way has good and bad qualities. First, it simplifies things a bit in the KSP lego world of parts. However, it's not as complex as accounting for things like wing sweep and aspect ratio.
  - Balancing this curve also causes weird problems like shuttles that can glide at unnaturally low speeds (because they have a lot of wing area).
  - Wing lift from AoA right now is very forgiving in KSP. There is a stall Angle of Attack, but it is quite high. This is also part of why things can fly unnaturally slow and don't fall out of the sky even at extremely high AoA.
• Wing drag is based on two curves, a Maximum Coefficient of Drag based on Mach, and a Coefficient of Drag based on Angle of Attack.
  - The Cd-Mach curve for wings is higher than that for fuselage pieces. There's a variety of reasons for this, but the end result to the game player is that if you build a plane with a lot of wing area, you will have a hard time getting through the supersonic barrier. However, once you're past it, it's generally easier to keep accelerating...

 

EDIT: By popular demand, here is a more in-depth discussion of the wing lift/drag modeling.

 

---

---

So, on top of all that, many parts have special cases. As noted above, parts that have open models (such as a cargo bay) can cause issues with part occlusion. Models with multiple cube types (such as parachutes) need to be built and adjusted properly. With all these special cases, I'm sure some of them were missed getting updated. On top of that, with any change to the global modifiers, it throws all of the other parts out of balance. It's a difficult act to balance. So yes, feedback is more than welcome. But if you want your feedback heard, avoid clouding it with too much angst and frustration.

Sure, we can have a back and forth on the forum about why the model is built this way and whether or not everyone agrees with it. But really my point in all this is that this is our new model (like it or not) and perhaps understanding a bit about how it works will aid people in their design process.

As a final note, all of these parts were built to be completely controllable and configurable by the user. No, I'm not saying "If you don't like it, go install a mod." I'm say that if you find something out of balance, try playing with the numbers and posting your findings! It's the community, working together, that really makes this place awesome to me. Hopefully this all helps a bit to understand what those sliders and buttons do.

Cheers,

~Claw

[NathanKell]

Post 2: Quick fixes to yield intended behavior.

• In physics.cfg change fullConvectionAreaMin = 0.2 to fullConvectionAreaMin = -0.2 (this is because of a sign flip in the code; it's clearly intended to be the minimum lerp value for full area for convection; instead (1-this) is the max. Flipping the sign flips the behavior back to intended.)
  

[allmhuran]

Thanks Claw, really good info. Of course, you've prompted me to want more

Parts that are connected to other parts via nodes have the size of that cube's face reduced by the size of the parent/child part

- Is it only the "tip" face that is reduced, are the side and tail faces also reduced? Are there any special rules for bicouplers/tricouplers/quadcouplers?

- What is "shock cone occlusion", and how does it relate to thermo? Google has no results matching that phrase other than this page itself.

- I recall some pre-1.0 commentary that suggested that clipped-in wings and control surfaces (eg, hiding a bunch of elevons inside your fuselage) would no longer provide lift or control, but since occlusion only applies to things which are node connected, and since no wing surfaces or control surfaces are ever node connected, and further since it sounds like wings and control surfaces might not fall under that occlusion model anyway, it sounds like clipped wings/controls might still function. Is that correct?

- I also recall some early discussion (an old squadcast, I believe) where ideas were being thrown around regarding how to do aero/drag. One idea that came up was to use the same technique as is used for figuring out how to draw the flame/atmo effects: ie, a camera which is put in front of the craft along the the velocity vector finds the edges, and that's where flames/shocks are drawn. It was mentioned that this technique might be incorporated into drag calculations, since it's a good way of looking at the shape and size of the cross section into the airstream. That seemed like a good idea to me... sort of a simplified version of FAR's upcoming voxelization of craft. Was this technique abandoned or is it used in some way?

Edited May 4, 2015 by allmhuran

[Psycho_zs]

When body goes supersonic, it creates a cone shaped shockwave with its foremost part. Behind the shock cone lies a low pressure area without supersonic flow, so parts at some distance behind the cone are protected.

[allmhuran]

When body goes supersonic,

Sure, I know what a "shock cone" is. Indeed, most aircraft create at least two shock cones. But I don't know what shock cone occlusion is. If it's just what you describe (ie, being inside or outside the shock cone), then I understand this part:

Put them too far forward, and they hit all that heat.

But not this part:

Put them too far back, and the forward blunt body doesn't provide blunt body occlusion anymore

[impyre]

Occlusion is just a fancy word for the process of "shielding" or covering something. An umbrella could be said to occlude you from the rain, in that sense it could be called a rain occlusion device... though I doubt google would be able to find that term, that doesn't make it less apt or correct. Occlude: stop, close up, block, or obstruct. So in the sense of the original post, one can infer that "shock cone occlusion" refers to a process by which the shock cone occludes or shields parts beneath it from the worst of the shock heating. This would allow radially attached parts (at least those which don't protrude too far) to be relatively safe. Some conductive and convective heating can still be expected of course, but if you try to fly the craft in backwards you'll see just how much difference the shock cone occlusion makes for things like batteries, goo canisters, and radially attached chutes.

Edited May 4, 2015 by impyre

[zekes]

TBH i like the new 1.0.2 atmosphere.

[impyre]

In response to the OP's remark about antennas... I find that kinda funny because it has been used to reduce drag, though I seriously doubt *reducing* drag will help you much during reentry. http://en.wikipedia.org/wiki/Drag-resistant_aerospike Of course... lasers are *way* more fun than metal spikes.

[allmhuran]

Occlusion is just a fancy word for the process of "shielding"

Cheers, but again, I know what occlusion is as such. My question is about the difference between parts that are "too far forward" vs parts that are "too far back" and how that relates to the idea of "shock cone occlusion" or "blunt body occlusion", being the terms used in the OP.

[Claw]

Thanks Claw, really good info. Of course, you've prompted me to want more

I will try to address what I know. Hopefully it's accurate/useful.

- Is it only the "tip" face that is reduced, are the side and tail faces also reduced? Are there any special rules for bicouplers/tricouplers/quadcouplers?

I believe it's the side that the node is on. So take for instance an FL-T800. If you attach a nose cone to the top node, then the blunt end of the FL-T800 is occluded from aero forces. But the sides and bottom end are still exposed.

How this relates to Tip, Surf, and Tail is a matter of the part's orientation in regard to the flight path. If the nose cone is out front, then it's the "tip." As such, the nose cone's drag is scaled by the Tip value, while the sides of the FL-T800 are scaled by "surf" values. If that FL-T800 were to turn sideways, then the side of the tank uses the "Tip" multiplier while the end with the nose cone would use the "Surf" multiplier.

- What is "shock cone occlusion", and how does it relate to thermo? Google has no results matching that phrase other than this page itself.

It's a loose term that I made up on the spot. It's really more like a shock wave, but also not. If you take a look in the spoiler, you'll see two test examples of shock waves. The game uses cones behind the front edge of things that look similar to a shock wave to figure out which parts are exposed to the full force of the airflow (and therefore how much heating). I would presume the cones are shaped by speed and bluntness of the objects, which will affect how parts behind this pseudo-shock are heated. It doesn't look like it's exactly like the pictures, but maybe they give you some sort of idea what I mean.

- I recall some pre-1.0 commentary that suggested that clipped-in wings and control surfaces (eg, hiding a bunch of elevons inside your fuselage) would no longer provide lift or control, but since occlusion only applies to things which are node connected, and since no wing surfaces or control surfaces are ever node connected, and further since it sounds like wings and control surfaces might not fall under that occlusion model anyway, it sounds like clipped wings/controls might still function. Is that correct?

Wings and control surfaces buried inside a fuselage will still generate lift. You can even put flat plates on the front edge of a wing and it'll fly fine. The comment that you are referring to might actually be in regard to the cargo bays. Just like how engines don't work inside cargo bays, wings and control surfaces hidden inside cargo bays do not generate lift while the bay doors are closed. (You can give all this a try in game by turning on the aero overlay.)

- I also recall some early discussion (an old squadcast, I believe) where ideas were being thrown around regarding how to do aero/drag. One idea that came up was to use the same technique as is used for figuring out how to draw the flame/atmo effects: ie, a camera which is put in front of the craft along the the velocity vector finds the edges, and that's where flames/shocks are drawn. It was mentioned that this technique might be incorporated into drag calculations, since it's a good way of looking at the shape and size of the cross section into the airstream. That seemed like a good idea to me... sort of a simplified version of FAR's upcoming voxelization of craft. Was this technique abandoned or is it used in some way?

I don't know the answer to this one, but based on what I can see from cubes and cones, my guess is no.

So in the sense of the original post, one can infer that "shock cone occlusion" refers to a process by which the shock cone occludes or shields parts beneath it from the worst of the shock heating. This would allow radially attached parts (at least those which don't protrude too far) to be relatively safe. Some conductive and convective heating can still be expected of course, but if you try to fly the craft in backwards you'll see just how much difference the shock cone occlusion makes for things like batteries, goo canisters, and radially attached chutes.

Yes. It seems you gleaned a lot from my coined phrase. This sums it up pretty nicely.

In response to the OP's remark about antennas... I find that kinda funny because it has been used to reduce drag, though I seriously doubt *reducing* drag will help you much during reentry. http://en.wikipedia.org/wiki/Drag-resistant_aerospike Of course... lasers are *way* more fun than metal spikes.

I didn't say that an antenna wouldn't reduce drag. I was trying to state that the way the cones work is to occlude parts behind it, but the cone does not extend indefinitely (thereby occluding everything behind it). This comment, by the way, is in relation to thermo.

but not block all heating for the entire craft by mounting an antenna out front

Cheers,

~Claw

[allmhuran]

Thanks for the clarification claw. So with respect to the comment that parts that are "too far back" can be subject to shock heating, they must either also be a long way off-axis compared to the nose in order to be outside the shock cone, or the "thermal shock" must at some point bend back in onto the craft. Is this what is going on? Eg:

Edit: Ah, I think I get it. More like this:

Edited May 4, 2015 by allmhuran

[Khazar]

Part occlusion is accomplished only through node connections. Parts that are connected to other parts via nodes have the size of that cube's face reduced by the size of the parent/child part. So surface mounted parts are not occluded from drag. (This is why stuff built with lots of things hanging off suffers a lot of drag.)

(..)

Thermo also includes simulation of shock cone occlusion, which deflects heat based on the part that's out front. This is why the location of surface mounted parts matter. Put them too far forward, and they hit all that heat. Put them too far back, and the forward blunt body doesn't provide blunt body occlusion anymore.

This shock cone occlusion is used only for calculating heat or drag as well ?

Putting things in line one right after another but not connecting them via nodes will generate much more drag ?

Would there be significant difference between layout A and B presented in picture below ?

[Claw]

Is this what is going on?

Your purple line there is the best representation of what's going on. Although I think the front end is still a cone of sorts, and not quite a bubble.

This shock cone occlusion is used only for calculating heat or drag as well ?

Heat only. Drag is subject to the drag cubes and is occluded by node connections.

If the black lines in your picture B represents node connections, then yes, your build B will be less draggy than build A.

[allmhuran]

This is all great info, thanks a lot!

[Khazar]

Heat only. Drag is subject to the drag cubes and is occluded by node connections.

If the black lines in your picture B represents node connections, then yes, your build B will be less draggy than build A.

Black lanes represent decouplers. I used layout A because I prefer empty tanks to be ejected sideways instead of backward. I'll have to rebuild one of my rockets to layout B. I'll then launch both versions straight up so I would see how much difference would it make.

Thanks for the info.

[1greywind]

Does anyone tested how multi-node adapters + gizmo-rotation behave? (be-couplers, etc) What if we connect something to be-coupler, then use rotation-gizmo to turn it by 90 degrees, then connect and rotate something to it, etc - does simulation takes into account something like that:

[TampaPowers]

So why does this overheat and explode before anything else does?

The ladder is right behind a shield and inside another part, yet it overheats and fails within seconds of re-entry.

[madadam]

Good stuff Claw, much appreciated! Out of pure curiosity: does anyone know how similar/dissimilar this model is to how FAR used to work in 0.90?

[Claw]

I'll then launch both versions straight up so I would see how much difference would it make.

I would be interested to hear how it comes out. Testing and posting that sort of thing is what I love aboutr this place!

Does anyone tested how multi-node adapters + gizmo-rotation behave?

I don't know yet how that would behave. I have my suspicions, but I don't really know since I haven't tested something like that myself. See if you can devise some sort of test and post your results!

So why does this overheat and explode before anything else does?

The ladder is right behind a shield and inside another part, yet it overheats and fails within seconds of re-entry.

I don't know, but my guess is that it has something to do with the shape of the occlusion cone behind the shield. Maybe it's not calculating the depth quite right. I'd have to dig around to see what's going on there since it "should" work.

Good stuff Claw, much appreciated! Out of pure curiosity: does anyone know how similar/dissimilar this model is to how FAR used to work in 0.90?

I didn't play much with FAR in 0.90, but I do know that it does more work behind the scenes with wing occlusion and wing shape. For example, if you hide a wing part behind a fuselage or a flat plate in FAR, that wing will not generate lift.

The 1.0 model only occludes wings that are in cargo bays (and not behind something like a flat plate). This has it's good and bad side. You can design/build some unrealistic planes that way, which bothers some people but gets others excited.

This is one of the cruxes of the gameplay vs. realism debate which is probably best left in other threads. However, it is one of the differences between 1.0 and FAR.

Cheers,

-Claw

[Starhawk]

Thank you Claw for all of this wonderful information! Three cheers for knowledge!

I really appreciate you taking the time to communicate all this info to the forums.

Happy landings!

[impyre]

@1greywind: I tested your theory with a simple craft using two structural fuselage pieces. One was attached to the node and then rotated, while the other was radially attached and then oriented as best I could to even them up. In-flight aero forces showed balance between both parts, so they were treated the same in terms of drag.

Though the image suggests slight imbalance, this is due mostly to angle... as it was a bit wobbly. At points where it was perfectly aligned with air-flow, it appeared to be perfectly balanced.

Edited May 4, 2015 by impyre

[panzer1b]

I didn't play much with FAR in 0.90, but I do know that it does more work behind the scenes with wing occlusion and wing shape. For example, if you hide a wing part behind a fuselage or a flat plate in FAR, that wing will not generate lift.

The 1.0 model only occludes wings that are in cargo bays (and not behind something like a flat plate). This has it's good and bad side. You can design/build some unrealistic planes that way, which bothers some people but gets others excited.

This is one of the cruxes of the gameplay vs. realism debate which is probably best left in other threads. However, it is one of the differences between 1.0 and FAR.

Cheers,

-Claw

Im very happy its this way, as there are just too many appearance craft me and others make that would refuse to work. Stuff liek bal;ancing by sticking a small control surface inside the nose, yes it is technically unrelialistic, but those that seek realism arent forced to place a control surface inside the fuselage. i think we get the bets of both worlds this way, noones forcing anyone to use part clipping, but those that wish to are still allowed to and arent screwed over by this.

[TampaPowers]

I wouldn't call this realistic at all. For a small planet like Kerbin there seems to be an awful lot of atmosphere around it, let alone that that atmosphere is far denser than the gravity of Kerbin could hold.

http://i.imgur.com/7zOTPE8.jpg Once it hits 200m/s it just falls over backwards no matter how many wings I put on it. I agree that it shouldn't be possible to just muscle everything into orbit, but even capsules have this issue.

Edited May 5, 2015 by TampaPowers

[KerbMav]

Part occlusion is accomplished only through node connections. Parts that are connected to other parts via nodes have the size of that cube's face reduced by the size of the parent/child part. So surface mounted parts are not occluded from drag. (This is why stuff built with lots of things hanging off suffers a lot of drag.)

Thermo also includes simulation of shock cone occlusion, which deflects heat based on the part that's out front. This is why the location of surface mounted parts matter. Put them too far forward, and they hit all that heat. Put them too far back, and the forward blunt body doesn't provide shock cone occlusion anymore.

Drag and thermo use different approaches here?

Edit: Sorry, yes, OK, it just baffled me enough to stop me from reading the rest of the thread first.

Carry on!

Edited May 5, 2015 by KerbMav

[Wanderfound]

I wouldn't call this realistic at all. For a small planet like Kerbin there seems to be an awful lot of atmosphere around it, let alone that that atmosphere is far denser than the gravity of Kerbin could hold.

http://i.imgur.com/7zOTPE8.jpg Once it hits 200m/s it just falls over backwards no matter how many wings I put on it. I agree that it shouldn't be possible to just muscle everything into orbit, but even capsules have this issue.

What do your fuel tanks look like at the time it goes? I'd be very surprised if you aren't getting some massive torque driven by increasingly misaligned CoM/CoT as the fuel drains.