Overhauls for 1.0

[OhioBob]

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.

Given its size and mass, if Kerbin were a real planet, it couldn't retain an atmosphere at all.

[Claw]

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.

Well, I didn't mean to imply commentary about how realistic Kerbin's atmosphere is. KSP is still a game, and the design is such that gravity and atmosphere density at sea level is the same as at sea level on Earth. I'm not trying to imply if this is good or bad. I'm just saying that is how it is.

For your rocket, I can tell just from the picture what the issue is. My first thought is that I would put the larger fin on the bottom rather than the top. Drag at 200m/s isn't that much higher. I think most people don't have issues till closer to 300 m/s, when transonic drag starts to come up. As posted above, take a look at the CoM and CoL as the tanks drain. Having lift up too high can also be destabilizing.

Cheers,

-Claw

[TampaPowers]

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.

This is with infinite fuel and full tanks, it makes no difference what I do. It seems the only reliable way to get to orbit is putting the engines at the top and the weight at the bottom.

It seems that angle of attack scales wrongly, I managed to go back into orbit from 100/31km to 100/72km just by pulling up while in atmosphere. Kerbins atmosphere feels like soup now.

[mikeb30165]

"fullConvectionAreaMin = 0.2": is this a bug that needs fixing or just a hack / workaround?

[BmB]

What are the "key" values? The numbers seem random, some pointers as to what each one does would be nice.

[TampaPowers]

So here is a few more things I did to test.

1. Large control fin at the bottom finite fuel. Result: At 15km 150m/s at 10° aoa it flips over and tumbles.

2. Large control fin at the bottom infinite fuel. Result: At 15km 150m/s at 17° aoa it flips and falls backwards.

3. Large control fin at the top finite fuel. Result: At 15km 150m/s at 6° aoa it flips over and tumbles.

4. Large control fin at the top infinite fuel. Result: At 15km 150m/s at 12° aoa it flips and then points down.

5. Unloaded takeoff from runway. 4° aoa required for level flight at 90m/s

6. Load three orange tanks. 18° aoa required for level flight at 90m/s

All that lets me conclude that with how little wing area this thing has, as long as I get a bit of wing under them they lift almost everything.

While I do believe I am missing something, I can't help but feel like Kerbins atmosphere no longer linearly bleeds off thickness with altitude, but rather stays almost constant till 35km and then bleeds off rather quickly.

Maybe I just can't construct shuttles, here I'll share my craft files. http://two66.com/Shuttle%2004.craft http://two66.com/Shuttle%2004%20Launcher.craft

Edited May 5, 2015 by TampaPowers

[MechaLynx]

Thanks for this Claw, it really helps understand some unclear behavior I've been getting (although, I must say the new aero force overlay is such a lifesaver and mythbuster!).

I have one question in my head: How do struts affect anything, if they do anything at all?

I know that due to the simplified model in which crafts are stored, there is a limit on how many node connections each part can have (most parts have only 2 node connectors IIRC, with very few exceeding that). But how do struts interact with the drag and aero calculations? Or do they simply affect the orientation of cubes and alignment during calculations, while being treated as if there was otherwise no connection at all (which is what I assume happens)?

[1greywind]

Well, I did some testing of occlusion on parts translated in editor:

Javascript is disabled. View full album

It doesn't work well. I you connect parts into stack, you can then translate them as you want and game does'nt takes they new position in acocunt then it calculates drag.

[Claw]

What are the "key" values? The numbers seem random, some pointers as to what each one does would be nice.

"keys" are a way to specify a curve inside Unity. Each key is a list of four numbers. X_Coordinate, Y_Coordinate, In_Tangent, Out_Tangent. As an example, look at the "Tip" drag (the simplest model).

DRAG_TIP
{
	key = 0 1 0 0
	key = 25 1 0 0
}

This says that at Mach = 0, the amount of drag on the tip is 1. The tangent coming into that point is 0, and going out of that point is 0 (flat and horizontal). The second point is at Mach = 25, with the same values. So when the game looks up how much of the tip drag to include at a given Mach, it looks at this set of keys. Say you are going Mach = 5. The game looks at the keys that define an equation, and at Mach 5, you get 100% of the tip drag value. The amount of drag a part gives at it's "tip" is defined by the drag cubes (a separate process).

Tangents are important because without them, Unity makes some assumptions about the curve. This can lead to bad and unintended results.

That's one step of the process that I gave a brief overview of in the initial post.

I have one question in my head: How do struts affect anything, if they do anything at all?

Actually, I haven't confirmed how they work. After a cursory look, it appears that they might use the old weight based drag model, but are also physicsless. Which means their drag is added to the parent part.

It doesn't work well. I you connect parts into stack, you can then translate them as you want and game does'nt takes they new position in acocunt then it calculates drag.

Yes, this is one of the limitations to using a node based occlusion system.

Cheers,

~Claw

[MechaLynx]

Actually, I haven't confirmed how they work. After a cursory look, it appears that they might use the old weight based drag model, but are also physicsless. Which means their drag is added to the parent part.

Interesting. This means you can adjust the drag of parts by adding struts, or distribute the additional drag by choosing which direction you connect struts in.

[Tw1]

Yes, this is one of the limitations to using a node based occlusion system.

Cheers,

~Claw

Interesting that they use an occlusion based model for thermal, but not for drag.

Is there a reason for this? Simplifying calculations, perhaps?

It does seem like using something like how you describe the shockwave system working would avoid some of the problems that the cube/node based system has.

[Claw]

It does seem like using something like how you describe the shockwave system working would avoid some of the problems that the cube/node based system has.

Hopefully I wasn't too misleading. The thermo system uses both cubes and the shock occlusion. As to why the drag doesn't use shock occlusion...I don't know. I would guess that radial parts burning up are more obvious than radial parts adding excess drag.

Cheers,

-Claw

[NathanKell]

The convection occlusion system is very, very simple: it projects all parts to the plane where the velocity vector is the normal, then assumes all parts are circles. For obvious reasons this would not work very well for drag.

Also, air is not light: just because one part is in front of another doesn't mean the other gets no airflow.

[Tw1]

The convection occlusion system is very, very simple: it projects all parts to the plane where the velocity vector is the normal, then assumes all parts are circles. For obvious reasons this would not work very well for drag.

It is pretty cool all the things that need to go on under the hood to make games like this function.

So, something like this would not be able to just check if a part is exposed to airflow?

Also, is there something that checks if the edges of wings are occluded?

Wondering if that could have something to do with the wing drag problems people have been talking about.

[Claw]

So, something like this would not be able to just check if a part is exposed to airflow?

Also, is there something that checks if the edges of wings are occluded?

Real air bends and flows around an object that moves through the air. So it would probably be easy to program a system that punches a hole in the air to block all parts behind it, that would like also result in strange behavior. This is what NK was referring to in that "air is not light." Just because air hits some leading point on a ship doesn't mean everything behind it is shielded.

It looks like KSP is doing several tricks to mimic bending air, including doing some shock occlusion to adjust for heating on radial parts that can't rely on the cube system.

Wing parts are surface mounted. Surface mount parts do not occlude any faces in terms of drag. However, wings are also treated differently in therms of drag. They have their own drag curves, so their edges are handled more by a drag curve based on their lift rating rather than part shape.

Cheers,

-Claw

[Gfurst]

@Claw, first of all thanks for clearing it up for us.

I was getting frustrated as to why my small rockets weren't piercing through the atmosphere as they should, did research and turned out it was due a wrongly cube generated in a nosecone part.

Which leads to my first question: How can I set up these drag cube modules? I didn't see any documentation about that, sorry if its obvious.

Secondly, I would like ask for some better physics settings, unfortunately the 1.0.2 patch made i look much more like it was the previous aero, aerodynamics doesn't account for much and thrust above all is needed.

What I'm trying to ask is: how to make things more realistic, even if a bit more challenging? And also some more realistic (and challenging) stall curves.

Cheers!

[Claw]

How can I set up these drag cube modules? I didn't see any documentation about that, sorry if its obvious.

What I'm trying to ask is: how to make things more realistic, even if a bit more challenging? And also some more realistic (and challenging) stall curves.

Cheers!

Well, drag cubes are automatically generated at startup. For a static, enclosed part like a nosecone, KSP shouldn't have problems. But my question back to you would be when/how are you trying to generate drag cubes, and what is wrong?

I ask because there are multiple ways to generate drag cubes. KSP will do it, you can supply drag cube multipliers, you can specify them in the part.cfg file, and they can be procedurally generated during run time. In order to point you at the right one, I would need to know what's wrong and what the part looks like.

As for more realistic aero, I think there are still some bugs in the system that are causing the difference in feel with rockets and planes that need fixing to really give a proper feel more universally. I can give my personal thoughts, but I don't wish to derail this thread from it's knowledge based topic. That being said, some users have reported more reasonable feel by using values half way between the 1.0.0 and 1.0.2 values.

If you are asking specifically about stall, that is controlled inside the lifting surface curves. It's the first one, which I think is called "lift" (I can't check at the moment). If you plot out this curve, it peaks at 30 degrees AoA (0.5). This is why I say stall AoA in KSP is very forgiving right now. A more realistic number is going to be more in the 10 AoA-ish area, which might be a bit too low for KSP. If you want to fiddle with stall, this is your curve.

Cheers,

-Claw

Edited May 8, 2015 by Claw

[OhioBob]

Claw,

I think I understand your general description of how drag is calculated, but I'd like to understand the practical details.

First, a drag cube is computed from the data in PartDatabase.cfg. Below are some examples. Can you explain what these numbers mean and how the faces are computed? It appears that each cube has 24 numbers, so are these numbers XYZ coordinates for the eight corners of the cube? Are these numbers in units of meters, such that when the area of each face is calculated it is in units of m²?

}
PART
{
                url = Squad/Parts/Command/mk1pod/mk1Pod/mk1pod
                DRAG_CUBE
                {
                                cube = Default, 1.015811,0.6656196,0.7373285, 1.015811,0.6769236,0.7315681, 1.250829,0.4787524,1.097382, 1.250829,0.9474788,0.3448916, 1.013055,0.6620117,0.7325699, 1.013055,0.6601633,0.7441065, 0,0.104412,-0.001005709, 1.268897,1.132536,1.270908
                }

}
PART
{
                url = Squad/Parts/FuelTank/fuelTankT800/fuelTankT800/fuelTank_long
                DRAG_CUBE
                {
                                cube = Default, 4.421483,0.7855119,0.6937256, 4.421483,0.7857171,0.6937256, 1.213026,0.9634836,0.1404351, 1.213026,0.9634838,0.1716429, 4.421483,0.784988,0.6937259, 4.421483,0.7850318,0.6937259, -1.376047E-16,-0.01320377,-3.882692E-08, 1.25,3.778993,1.250001
                }

}
PART
{
                url = Squad/Parts/Engine/liquidEngineLV-T45/liquidEngineLV-T45/liquidEngine2
                DRAG_CUBE
                {
                                cube = Fairing, 2.120381,0.7789587,0.7138752, 2.120381,0.7795625,0.7138752, 1.225164,0.9361377,0.2293777, 1.225164,0.8617272,1.553849, 2.120381,0.7755077,0.7138755, 2.120381,0.775539,0.7138755, 0,0.05659348,1.192093E-07, 1.256305,1.686817,1.256306
                                cube = Clean, 0.9306615,0.7107355,1.02353, 0.9306615,0.7169976,0.7278433, 1.213026,0.9359285,0.193909, 1.213026,0.8411375,1.608727, 1.138486,0.7378568,0.7221571, 1.138486,0.7381418,0.7278435, 0,0.08432049,5.960464E-08, 1.25,1.631363,1.25
                }

The curves in Physics.cfg appears to compute the drag coefficients. I assume we compute the face area from the cube data above, multiple that area by the curve for the appropriate face type (tip, surface or tail), and then multiple that by the drag multiplier. That is,

AC_d = Face Area * DRAG_(TIP,SURFACE,TAIL) * DRAG_MULTIPLIER

Am I correct so far? Does the above then get multiplied by the maximum_drag and/or minimum_drag value from the Part.cfg files? If not, how is maximum_drag and minimum_drag used? When is one used versus the other?

Once the above is computed, I assume the drag produced by each part is found by the drag equation,

F_d = ÃÂV²AC_d/2

with the total drag force simply being the sum of the parts.

Regarding occlusion, you said "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." Does this mean that the tip area of a trailing part is reduced by the tail area of the leading part? Or is it more complicated than that? I assume a leading part's tail area is likewise reduced. What if the leading part has a bigger frontal area than the trailing part? Does that have any effect on, say, the surface drag of the trailing part?

Physics.cfg also includes the following multipliers. Can you explain how these factor into the computation?

dragMultiplier = 8.0
dragCubeMultiplier = 0.1
angularDragMultiplier = 2

Thank you very much for taking the time to explain this stuff. Your explanations so far have be very enlightening.

[Gfurst]

Well, drag cubes are automatically generated at startup. For a static, enclosed part like a nosecone, KSP shouldn't have problems. But my question back to you would be when/how are you trying to generate drag cubes, and what is wrong?

I ask because there are multiple ways to generate drag cubes. KSP will do it, you can supply drag cube multipliers, you can specify them in the part.cfg file, and they can be procedurally generated during run time. In order to point you at the right one, I would need to know what's wrong and what the part looks like.

Specifically there are a couple of parts that are bugging me out, one example is the Sounding rockets nosecose, its actually a parachute:

In the image it is actually with the dev version of nuFAR, with stock I wasn't achieving not nearly enough speed, upon debugging I've found that the part behind the nose was getting huge amounts of drag, and coming to sudden brake when the thrust ran out.

Second example is the stock plane tail, either model (as they're essentially the same), produce big amount of drag, the same or more than the frontal cockpit, which is really odd, as the tail supposedly improve airflow and not disrupt it.

As for more realistic aero, I think there are still some bugs in the system that are causing the difference in feel with rockets and planes that need fixing to really give a proper feel more universally. I can give my personal thoughts, but I don't wish to derail this thread from it's knowledge based topic. That being said, some users have reported more reasonable feel by using values half way between the 1.0.0 and 1.0.2 values.

If you are asking specifically about stall, that is controlled inside the lifting surface curves. It's the first one, which I think is called "lift" (I can't check at the moment). If you plot out this curve, it peaks at 30 degrees AoA (0.5). This is why I say stall AoA in KSP is very forgiving right now. A more realistic number is going to be more in the 10 AoA-ish area, which might be a bit too low for KSP. If you want to fiddle with stall, this is your curve.

I appreciate effort and understand to not derail the topic. So please come to my own thread and help me out the physics stuff, including the lifting surface curves.

Its a small thread for patches I'm making to balance and fix issues for stock and modded stuff.

And finally, a 30° AoA isn't all that unrealistic, most planes would stall around the area of 15~25°, but it largely depends on wing designs, of course delta wings have a much smaller AoA range.

[OhioBob]

...upon debugging I've found that the part behind the nose was getting huge amounts of drag

I've been doing some similar debugging and I'm finding the same thing. Some parts are producing far more drag than they should. For instance, I'm discovering that heat shields produce a large amount of drag during launch even though they are occluded and covered by a fairing. In another case I found that the large reaction wheel module produced a incredibly large amount a drag in proportion to its size.

[Gfurst]

I've been doing some similar debugging and I'm finding the same thing. Some parts are producing far more drag than they should. For instance, I'm discovering that heat shields produce a large amount of drag during launch even though they are occluded and covered by a fairing. In another case I found that the large reaction wheel module produced a incredibly large amount a drag in proportion to its size.

Precisely, as Claw said, these are odd/open models. I'm guessing each part's drag cube is calculated separately with input data for part occlusion and stuff, for example, not as a whole.

[Gfurst]

Claw I think I'm getting what you've said. Checking the in-game drag profile I've come to understand the curves.

For example, the drag curve for tail keeps at 1.0 till it reach trans-sonic, I find it a bit odd, but I guess makes sense for sudden stop tails, but not for the airplane ones.

AS for the AoA stall thing:

name = Default
		lift
		{
			key = 0 0 0 1.965926
			key = 0.258819 0.5114774 1.990092 1.905806
			key = 0.5 0.9026583 0.7074468 -0.7074468
			key = 0.7071068 0.5926583 -2.087948 -1.990095
			key = 1 0 -2.014386 -2.014386
		}

I'm assuming this is what you meant, it peaks on 0.5 give the biggets lift value, what the X axis stands for? Degrees 0 - 60?

[Claw]

Well, there are a lot of questions here but with the forum auto merge it's going to be one long post. So I'll try to break it up.

---

Can you explain what these numbers mean and how the faces are computed?

Lets just look at one of these, and I'm going to pick the Mk1 capsule because the sides are symmetric but the top and bottom aren't.

PART
{
                url = Squad/Parts/Command/mk1pod/mk1Pod/mk1pod
                DRAG_CUBE
                {
                                cube = Default, 1.015811,0.6656196,0.7373285, 1.015811,0.6769236,0.7315681, 1.250829,0.4787524,1.097382, 1.250829,0.9474788,0.3448916, 1.013055,0.6620117,0.7325699, 1.013055,0.6601633,0.7441065, 0,0.104412,-0.001005709, 1.268897,1.132536,1.270908
                }

}

So that's the whole thing, but lets pull it apart. "Default" is the name of the drag cube. Most will be "Default" but if you look at a parachute, landing gear, or cargo bays, you'll see that they have multiple cubes for their various states.

The first 6 sets of numbers are actually for each face. Each set of three numbers is the [area, drag coefficient, depth of the part] for that face. The sets are ordered X +/-, Y +/-, Z +/-. So look at the first two sets:

[1.015811,0.6656196,0.7373285] and [1.015811,0.6769236,0.7315681]. This is the sides of the pod (well, only two sides actually). You'll note that the numbers are all nearly identical, as they should be. Now the second two sets:

[1.250829,0.4787524,1.097382] and [1.250829,0.9474788,0.3448916]. You can see that the first number [areas] are the same but that the drag coefficients are different. The bottom is more flat, and has a drag coefficient value of 0.9474788. Depths are also different.

The last two sets are a center coordinates and a size coordinate. I think these are used for drag application and in the thermal system, but I am not 100% certain on that.

The curves in Physics.cfg appears to compute the drag coefficients. I assume we compute the face area from the cube data above, multiple that area by the curve for the appropriate face type (tip, surface or tail), and then multiple that by the drag multiplier. That is,

AC_d = Face Area * DRAG_(TIP,SURFACE,TAIL) * DRAG_MULTIPLIER

Almost. You are on the right track conceptually. The game basically figures how how fast the cube is going, then looks up the DRAG_(TIP, SURF, TAIL) numbers. This might be hard to explain in words, but from these numbers, it computes a part independent drag profile (not based on the parts size/shape). It plots a curve of a dot product from the tail to the tip. Then it evaluates the airflow against that particular part and it's orientation, because each drag cube is probably not oriented perfectly into, sideways, or tail on to the wind stream. So it'll look at each face and figure out the dot product between that face and the wind stream. Then it'll use that dot product to look up in the drag profile how much of that drag to use.

For a cube that's oriented perfectly? The forward face contributes 100% of it's drag. If it's not oriented perfectly, that forward face will contribute some amount of drag lower than 100% based on how far it's turned, until it reaches 90 degrees and contributes only "SURF" drag levels.

These curves basically determine how much of the skin of the part is contributing to drag. Then the resulting numbers are multiplied by the drag_multiplier, which does most of the work of simulating the subsonic, transonic, supersonic, and hypersonic drag.

Does the above then get multiplied by the maximum_drag and/or minimum_drag value from the Part.cfg files? If not, how is maximum_drag and minimum_drag used? When is one used versus the other?

min and max drag are relics of the old drag system. They are meaningless in the new aero system.

Regarding occlusion, you said "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." Does this mean that the tip area of a trailing part is reduced by the tail area of the leading part? I assume a leading part's tail area is likewise reduced. What if the leading part has a bigger frontal area than the trailing part? Does that have any effect on, say, the surface drag of the trailing part?

This is the basics of it. Yes, trailing parts occlude the tail of parts in front of them. Having a bigger part up front does not shield surface drag of parts behind.

Physics.cfg also includes the following multipliers. Can you explain how these factor into the computation?

dragMultiplier = 8.0
dragCubeMultiplier = 0.1
angularDragMultiplier = 2

They are global multipliers, and (simply put) are just multiplied against the resultant drag. So yes, when dragMultiplier went from 6.0 to 8.0, it was a 33% increase. Angular drag is exactly that, drag for parts that are rotating.

---

Since I've taken the time to explain all of that (and assuming the reader has read it all) I can now explain one of the fundamental bugs in the drag system that is causing the most problem. This is probably the central point that needs addressing, but it's complex and difficult to explain without knowledge of how all this stuff is interlinked.

So, in 1.0.0 the drag for something like a rocket was actually a bit low for gamebalance purposes and for realism (when comparing things to an Earth environment). However, it "felt" better for aeroplanes to most people... So why is that?

Well, as it turns out, if you look at those drag cube numbers... Remember that second number, that I said represents a drag coefficient. Well, if it's being used as such, then the drag coefficients for pointy objects is WAAAAY to high. You can see that fact when you look at something like a nose cone, whose drag coefficient is [0.6305804] when it should be something a bit lower. So a nosecone (or cockpit, or whatever pointy thing) is getting 60% of the drag when compared to the front of something blunt, like a fuel tank.

Why does that matter? Because a huge portion of drag comes from the forward face. Airplanes have a lot of forward face (as do rockets) but are also generally more pointy. However, their pointy-ness isn't accounted for all that well at the moment. This is part of what is driving the "my airplane is forced to look like a hotdog!"

So flat, blunt part drag (including skin friction) was actually pretty low in 1.0.0 when comparing KSP things to Earth at sea level. Fuel tanks were reaching supersonic terminal velocities and dV to orbit was pretty low, generally speaking. But it felt right for airplanes, and was masking the issues of this underlying bug.

Drag in 1.0.2 is actually pretty close to Earth at sea level for blunt objects, but it now feels soupy because of the excessive drag coefficients for pointy parts.

This is one of the real bugs that needs squashing, but it's completely hidden from people. All that is seen are the changes to the global values which people are getting hung up on. The changes were done to balance rockets better, and maybe that's a little clearer now. This change, coupled with several other bugs (like improper drag cubes for cargo bays) are causing issues with airplanes.

---

In the image it is actually with the dev version of nuFAR, with stock I wasn't achieving not nearly enough speed, upon debugging I've found that the part behind the nose was getting huge amounts of drag, and coming to sudden brake when the thrust ran out.

Second example is the stock plane tail, either model (as they're essentially the same), produce big amount of drag, the same or more than the frontal cockpit, which is really odd, as the tail supposedly improve airflow and not disrupt it.

Perhaps some of my explanation above might clear that up. I agree, a tail part should reduce tail drag as compared to a flat fuselage or fuel tank type piece.

I've been doing some similar debugging and I'm finding the same thing. Some parts are producing far more drag than they should. For instance, I'm discovering that heat shields produce a large amount of drag during launch even though they are occluded and covered by a fairing. In another case I found that the large reaction wheel module produced a incredibly large amount a drag in proportion to its size.

I'm not sure about the heat shields and such. I'd have to go check. The large reaction wheel is an open faced part, and probably has a drag cube manually assigned to it. It might be out of balance. Open faced parts need to be handled manually by inserting drag cubes into their part.cfg files. So you can imagine how much of a pain this is any why some of them might have gotten missed in the updating process (or updated with incorrect values).

name = Default
		lift
		{
			key = 0 0 0 1.965926
			key = 0.258819 0.5114774 1.990092 1.905806
			key = 0.5 0.9026583 0.7074468 -0.7074468
			key = 0.7071068 0.5926583 -2.087948 -1.990095
			key = 1 0 -2.014386 -2.014386
		}

I'm assuming this is what you meant, it peaks on 0.5 give the biggets lift value, what the X axis stands for? Degrees 0 - 60?

In this curve, the first number is the dot product of the angle, so it ranges from 0 (0 degrees AoA) up to 1 (90 degrees AoA). The dot product of an angle isn't linear, so it turns out that a dot product of 0.5 is actually an AoA of 30 degrees. And at 0.5, you get 0.902 as the Cl Maximum multiplier (maximum lift). At 45 degrees AoA (0.707), you get ~0.6 as the multiplier (over 60% of the maximum lift). At 90 degrees AoA (1) you get 0 as the multiplier (no lift). So you can see that the stall curve is pretty gentle. This also contributes to the "fake" feel for high AoA airplanes but prevents rockets from going out of control for those who find themselves at sudden high angles of attack during launch (assuming there are fins involved).

I think I used up my keyboard quota already today....

Cheers,

~Claw

Edited May 9, 2015 by Claw

[Gfurst]

Cheers Claw, you did an amazing job explaining these things, it sure makes things a lot clearer .

Lets just look at one of these, and I'm going to pick the Mk1 capsule because the sides are symmetric but the top and bottom aren't.

PART
{
                url = Squad/Parts/Command/mk1pod/mk1Pod/mk1pod
                DRAG_CUBE
                {
                                cube = Default, 1.015811,0.6656196,0.7373285, 1.015811,0.6769236,0.7315681, 1.250829,0.4787524,1.097382, 1.250829,0.9474788,0.3448916, 1.013055,0.6620117,0.7325699, 1.013055,0.6601633,0.7441065, 0,0.104412,-0.001005709, 1.268897,1.132536,1.270908
                }

}

That's a very good explanation, I was thinking it was more like a tri-dimensional cube, but actually faces for each side of the part.

I have to say though, this system is very unintuitive for manually adjusting and tweaking. But at least I'm assuming the PartDatabase file in the root folder, meansthe drag cube generate automatically, and if we spot something wrong we can take it as basis.

The sets are ordered X +/-, Y +/-, Z +/-.

What is the actual order/orientation might be helpful, eg, is X or Y up/down? I'm guessing it might be whatever Unity uses as models, so may be easier for people actually know how handle these.

For a cube that's oriented perfectly? The forward face contributes 100% of it's drag. If it's not oriented perfectly, that forward face will contribute some amount of drag lower than 100% based on how far it's turned, until it reaches 90 degrees and contributes only "SURF" drag levels.

These curves basically determine how much of the skin of the part is contributing to drag. Then the resulting numbers are multiplied by the drag_multiplier, which does most of the work of simulating the subsonic, transonic, supersonic, and hypersonic drag.

That's a bit odd, when the craft turns 90° from the wind, doesn't the side face account as being frontal, given the multiplier of 0.2 seems a bit off.

But what I'm understanding about this, if the craft is perfectly aligned to the wind, the frontal face is occluded and the side faces contribute 0 to drag, makes sense.

But I can see how this could be very, very² difficult to balance out.

Actually, isn't this the source of balancing problems? having a higher lateral drag, means that we need to keep longer and less wider, As long as we're flying relatively straight everything should be alright., but if we tumble to rocket too much might notice some heavy drag.

This is one of the real bugs that needs squashing, but it's completely hidden from people. All that is seen are the changes to the global values which people are getting hung up on. The changes were done to balance rockets better, and maybe that's a little clearer now. This change, coupled with several other bugs (like improper drag cubes for cargo bays) are causing issues with airplanes.

But its still good to see you're aware of the issue and will be addressing it eventually.

In this curve, the first number is the dot product of the angle, so it ranges from 0 (0 degrees AoA) up to 1 (90 degrees AoA). The dot product of an angle isn't linear, so it turns out that a dot product of 0.5 is actually an AoA of 30 degrees. And at 0.5, you get 0.902 as the Cl Maximum multiplier (maximum lift). At 45 degrees AoA (0.707), you get ~0.6 as the multiplier (over 60% of the maximum lift). At 90 degrees AoA (1) you get 0 as the multiplier (no lift). So you can see that the stall curve is pretty gentle. This also contributes to the "fake" feel for high AoA airplanes but prevents rockets from going out of control for those who find themselves at sudden high angles of attack during launch (assuming there are fins involved).

Ahhh ok. By dot product I'm understanding 'Sine 45° = 0.5', sorry but english is my native, so math terms are hard for me.

But this surely explains how things work, If can only figure out how to plan and plot these out more intuitively I can get some proper values.

I think I used up my keyboard quota already today....

Cheers,

~Claw

What, so quickly like that? But thanks Claw, this explanation is sure of great help.

Only thing I think is left to explain is how body lift works.

[NathanKell]

In the VAB, a part's axes are Y+ = up, X is left/right, and Z is in/out (dorsal/ventral). In the SPH, the main axis (Y) is forward/back rather than up/down.

Yes, partDB entries are autogenerated. And it's pretty simple to fix up a hollow part, you just replace the first two numbers in each of the Y+ and Y- tuples with numbers from a non-hollow part of the same diameter.

Body lift takes the drag area without the mach multiplier and then multiplies again by dot and then evaluates the body lift curves from Physics.cfg (using sin(AoA) to that facing, and mach).