Overhauls for 1.0

Mesons · May 9, 2015

This thread is a fantastic wealth of information. Thank you all for posting, asking, and answering! A lot of questions I had about the inner workings of the new aero model have been answered.

Claw · May 10, 2015

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.

Hmm. I think you're missing out a bit on this part. So, try to disconnect the concept of the "top of the drag cube" from what is considered "Tip Drag." They are not the same. The top of the drag cube is just another face, and is not inherently "Up" or the "Tip."

Whichever cube face is pointed directly into the wind receives the multiplier specified by "Tip." It can be the X, Y, Z...positive side or negative side... Also, cube faces that are 90 degrees to the wind (parallel) still contribute to drag, but the amount specified in "Surf." When these faces are off of exact angles (0, 90, 180) the amount of drag they contribute is subject to that drag curve profile I explained above.

Hopefully that helps.

Cheers,

~Claw

NathanKell · May 10, 2015

Put mathematically,

drag = 0

for each cube face:

.dot = dot(cube normal, velocity)

.drag += getdragvalue(dot, mach) * face.area * face.dragcoefficient

where getdragvalue will return an interpolated value between tip to surf if dot >=0, or between surf and tail if dot < 0, multiplied by the mach multiplier drag cube.

(i.e. if the dot is 0.5, then that face is midway between tip and surf for drag curve purposes)

OhioBob · May 12, 2015

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Ã¢â‚¬Â¦

Thank you very much for your fine explanations.

If my understanding is correct, we have a system that looks like this (though I may have the direction of the X and Z axes incorrect):

The top surface is the Y+ surface, the bottom is the YÃ¢â‚¬â€œ surface, the surface to the right is the X+ surface, and so on.

For the Mk1 Command Pod we have,


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
                }

}

Therefore, tabulating the data into a more easy to read format, we have:

[TABLE=class: outer_border, width: 500]

[TR]

[TD=align: center]Surface[/TD]

[TD=align: center]Area[/TD]

[TD=align: center]Cd[/TD]

[TD=align: center]Depth[/TD]

[/TR]

[TR]

[TD=align: center]X+[/TD]

[TD=align: center]1.015811[/TD]

[TD=align: center]0.6656196[/TD]

[TD=align: center]0.7373285[/TD]

[/TR]

[TR]

[TD=align: center]XÃ¢â‚¬â€œ[/TD]

[TD=align: center]1.015811[/TD]

[TD=align: center]0.6769236[/TD]

[TD=align: center]0.7315681[/TD]

[/TR]

[TR]

[TD=align: center]Y+[/TD]

[TD=align: center]1.250829[/TD]

[TD=align: center]0.4787524[/TD]

[TD=align: center]1.097382[/TD]

[/TR]

[TR]

[TD=align: center]YÃ¢â‚¬â€œ[/TD]

[TD=align: center]1.250829[/TD]

[TD=align: center]0.9474788[/TD]

[TD=align: center]0.3448916[/TD]

[/TR]

[TR]

[TD=align: center]Z+[/TD]

[TD=align: center]1.013055[/TD]

[TD=align: center]0.6620117[/TD]

[TD=align: center]0.7325699[/TD]

[/TR]

[TR]

[TD=align: center]ZÃ¢â‚¬â€œ[/TD]

[TD=align: center]1.013055[/TD]

[TD=align: center]0.6601633[/TD]

[TD=align: center]0.7441065[/TD]

[/TR]

[/TABLE]

Is everything correct so far?

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.

IÃ¢â‚¬â„¢d like to now perform a sample computation to make sure I understand the math. If we assume that the cube is perfectly oriented (i.e. zero sideslip angle) then the Y+ surface contributes all the drag. The Y+ surface is this partÃ¢â‚¬â„¢s "tip". The area of this surface is 1.250829 m² and its drag coefficient is 0.4787524.

Drag force is,

F_d = Ã‚Â½ ÃÂV²AC_d

but we must multiply this by DRAG_TIP and DRAG_MULTIPLIER.

DRAG_TIP and DRAG_MULTIPLIER are functions of Mach number. LetÃ¢â‚¬â„¢s say we are traveling 600 m/s, which weÃ¢â‚¬â„¢ll call Mach 2. According to Physics.cfg, the value of DRAG_TIP is equal to 1 at all Mach numbers, while the value of DRAG_MULTIPLIER is equal to 1.2 at Mach 2. Assuming the air density is 0.13 kg/m³, we have

F_d = Ã‚Â½ * 0.13 * 600² * 1.250829 * 0.4787524 * 1 * 1.2 = 16,815 N

which is the drag produced by this one part.

Now if the part is tilted, then multiple surfaces are exposed to the air stream, with each surface contributing to the drag force. The amount that a particular surface contributes is a function of the dot product of that surfaceÃ¢â‚¬â„¢s axis and the air stream vector.

LetÃ¢â‚¬â„¢s say with have a sideslip angle of 5^o and the orientation is such that the X+ surface is now exposed to the air stream. The amount that the Y+ surface contributes is COS(5^o) = 0.996195, and the amount the X+ surface contributes is COS(85^o) = 0.087156. To compute the drag contributed by the X+ surface, we use the area and C_d for that particular surface and we use DRAG_SURFACE instead of DRAG_TIP.

Did I do that right, or IÃ¢â‚¬â„¢m a still messing something up? I'm not too sure about that last part.

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Ã¢â‚¬Â¦

It sounds like you have a good system that should work very well once the last few remaining bugs are fixed.

Edited May 12, 2015 by OhioBob

M4ck · May 12, 2015

I understood it as the total drag produced by a part either is the sum of all 6 faces minus occlusion by node attached parts, times various modifiers(mach, global drag etc), where each separate face always gets its drag as:

(drag_tip*f1(angle to wind)+drag_surf*f2(angle to wind)+drag_tail*f3(angle to wind))

, or a similar equation where occlusions are checked on a per-face level; where f1, f2 and f3 are some trig-like functions to get the face's tip/surf/tail "component" in calculating overall face drag.

So:

* a face perpendicular to wind would give 100% tip drag,

* a face slightly angled would give, say, sin(a)*tip+cos(a)surf,

* a face parallel to wind would give 100% surf drag,

* a face "dragging behind" the vessel would give like cos(a)surf(+ or -)sin(a)tail.

* and a face "antiperpendicular" to wind would give 100% tail drag.

Am I far from what is really happening in-game?

OhioBob · May 12, 2015

I understood it as the total drag produced by a part either is the sum of all 6 faces minus occlusion by node attached parts, times various modifiers(mach, global drag etc), where each separate face always gets its drag as:
(drag_tip*f1(angle to wind)+drag_surf*f2(angle to wind)+drag_tail*f3(angle to wind))
, or a similar equation where occlusions are checked on a per-face level; where f1, f2 and f3 are some trig-like functions to get the face's tip/surf/tail "component" in calculating overall face drag.
So:
* a face perpendicular to wind would give 100% tip drag,
* a face slightly angled would give, say, sin(a)*tip+cos(a)surf,
* a face parallel to wind would give 100% surf drag,
* a face "dragging behind" the vessel would give like cos(a)surf(+ or -)sin(a)tail.
* and a face "antiperpendicular" to wind would give 100% tail drag.
Am I far from what is really happening in-game?

That makes more sense then what I did. In fact, after re-reading Claw's answers, I'm pretty sure that I misinterpreted part of it. Hopefully we'll get a clarification, but I think we'll find that your method is closer to the facts.

Claw · May 12, 2015

Both posts are getting there, but still, you need to separate the concept of cube faces from being directly connected to what is "tip, surf, and tail."

Think of it more this way. The game looks at a particular part and finds its speed. It then uses that speed to build a drag curve profile. That profile (which I posted a pic of earlier) basically starts at a value of "tail * multi" for dot = -1, slowly decreases to a value of "surf * multi" at dot = 0, then increases back to "tip * multi" at dot = 1.

Next, the game looks at the drag cube, one face at a time and a determines the dot between the face and the wind. If that face happens to be exactly pointed into the wind (dot = 1), it will have a drag profile multiplier of "tip * multi." If that same face had a dot = 0, the it would be a drag profile multiplier of "surf * multi." If it has a dot = 0.5, then the drag profile multiplier would be somewhere in between.

That multiplier becomes part of the total drag equation which takes the face size and shape (from the drag cube tripplet groups) into account.

Once that face's dot is determined, the game moves to the next face, and so on.

It never just looks at a face and says "tip drag scaled by sin(dot) is close enough." It's actually choosing a drag profile multiplier somewhere inbetween the three "tip, surf, and tail."

The drag profile is sort of a "how much would each surface contribute to drag at a given Mach?" At slower speeds, skin friction (referred to as "surf" by KSP) is relatively higher than when hypersonic. How much does "tail" contribute (which is really the area "behind" or facing backward)? It's a bit of a simplification, but that's how it is set up.

Does that help?

Cheers,

-Claw

Edited May 13, 2015 by Claw

M4ck · May 12, 2015

Yes, it does Thanks for keeping up with all the questions.

OhioBob · May 12, 2015

Does that help?

Yes it does. I think I understand now. Sorry to have bothered you with so many questions, but I really like knowing how things are computed. I appreciate your time and patience in explaining.

Gfurst · May 14, 2015

Has anybody suggestion for tools to plot and better visualize the game's curves?

That being ( x, y, tan in, tan out) points.

Claw · May 15, 2015

Has anybody suggestion for tools to plot and better visualize the game's curves?
That being ( x, y, tan in, tan out) points.

MuMech (I think..?) will let you plot things in-game, although it can be a bit clunky to use.

The free Unity development version along with another plugin (which I think was written by r4m0n) can allow you to see and edit the plots in a bit easier fashion. With that combination, you can cut & paste the curves into the Unity editor and adjust them with GUI tools or by typing in values.

http://unity3d.com/get-unity/download

The real thread that you need, which contains links to the Unity plugin ---> http://forum.kerbalspaceprogram.com/threads/93332-INFO-KSP-floatCurves-and-you-the-magic-of-tangents

Cheers,

~Claw

Gfurst · May 15, 2015

MuMech (I think..?) will let you plot things in-game, although it can be a bit clunky to use.
The free Unity development version along with another plugin (which I think was written by r4m0n) can allow you to see and edit the plots in a bit easier fashion. With that combination, you can cut & paste the curves into the Unity editor and adjust them with GUI tools or by typing in values.
http://unity3d.com/get-unity/download
The real thread that you need, which contains links to the Unity plugin ---> http://forum.kerbalspaceprogram.com/threads/93332-INFO-KSP-floatCurves-and-you-the-magic-of-tangents
Cheers,
~Claw

Thanks

Unfortunately I'm on linux, and thus can't get the unity devel tools.

NathanKell · June 23, 2015

As of 1.0.3 the drag per face of a cube is no longer just the curve evaulation times area times weightedDrag, it's now curve evaluation times area times (weightedDrag if weightedDrag >1, else CdCurve.Evaluate(weightedDrag))

In effect this means that flat cube faces are as you'd expect (no change for drag coefficients above .9 or so), and tapered faces are more like drag coeff^2 (so a coeff of .5 in the DRAG_CUBE becomes a .25 in practice).

OhioBob · June 26, 2015

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).

The above issue appears not to have been fixed in 1.03/1.04. Do you know if Squad is planning to fix these problems, and when?

BlackTeacup · July 7, 2015

Firsty, thanks so much Claw and co for the amazing info.

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.

Does the incorrect drag for hollow parts apply to user made fairings and service bays as well? I'm using service bays for science equipment and batteries, but I'm not sure if its even needed, or just adds weight. In sandbox mode one can just add whatever advanced parts, but I'm in lower level career mode for my first game, and I've had quite some trouble getting long range planes to be viable for surveys/science.

This really helpful thread describes drag as of Oct 2013 (not sure what version) saying that fairings don't help, but that's the old aero model.

If they still calculate drag incorrectly, or as if opened, is there any reason currently to use these parts (eg. thermal protection for re-entry), or does adding them simply add weight?

NathanKell · July 7, 2015

I think you're confusing whether a part shields what's inside of it, with whether it has a correct drag model for itself and whether it properly occludes when on the stack. The mk3 bays did not have an override until 1.0.3 so that was an issue, and any mod parts that don't have overrides will be wonky, but that doesn't have anything to do with whether or not they shield other parts that are inside them.

If fairings use the stock module, or Procedural Fairings's module, then they will work. Otherwise--say, they're old-style NP2 or KW fairings, i.e. multipart without a shielding module) then they will just double your drag.

Service bays that use ModuleCargoBay will shield what's inside them. Cargo/service bays that don't have ModuleCargoBay will not. Certainly the stock bays do shield.

BlackTeacup · July 7, 2015

Thanks, that half answers my question. I think I mis-communicated - I meant both: does it shield it's cargo (sounds like it does), and does it have its own correct drag model. Also, I meant stock parts only, no mods (by user made fairings i meant procedural stock ones. ).

So yea, do these stock cargo bays, service bays and fairings have correct drag for themselves at the moment?

Claw · July 8, 2015

I meant both: does it shield it's cargo (sounds like it does), and does it have its own correct drag model. ...
So yea, do these stock cargo bays, service bays and fairings have correct drag for themselves at the moment?

Yes, service bays and cargo bays now properly shield parts inside of them from the airstream (when the doors are closed).

Also, the cargo bays now have proper drag models, so they properly occlude parts that they are connected to.

...And welcome to the forums!

Cheers,

~Claw

BlackTeacup · July 9, 2015

Thanks guys!

Gfurst · September 3, 2015

Hey @Claw... Me, once again, to make a bunch of unreasonable questions :kiss:

Thanks to NathanKell, pointed me out for in-game utility that can preview unity floatcurves, thanks for sarbian for doing that.

Now I'm going to mess all hell up modding stuff...

Here we go:

1: What is that DRAG_CD curve, in the physics config?

2: About the lifting surfaces curves. For ones that are based on angle, we can just assume they're mirrored when negative right (inverse).

3: For the liftMach and dragMach curves, they are the actual final mach multiplier right?

I've mean, I'm assuming the result lift for a surface would be Lf = Lm * Am * Pl * Atm

Lf = final Lift; Lm = mach mult; Am = angle modifier; Pl = part lift; Atm = atmosphere density

I'm asking this because there are two main factors affecting lift as I know: square velocity, as lift will increase with the square of the airflow speed; and the lift coefficient, that changes mainly during transonic and supersonic.

And the default values for this are confusing:

		liftMach
		{
			key = 0 1 0 0
			key = 0.3 0.5 -1.671345 -0.8273422
			key = 1 0.125 -0.0005291355 -0.02625772
			key = 5 0.0625 0 0
			key = 25 0.05 0 0
		}

Which seems like lift is maximum at zero velocity, which obviously makes no sense. So I think I must be missing something.

4: This is really just show boasting, what do you think of these curves?

		%lift
		{
			key = 0 0 2 2
			key = 0.5 1 0 0
			key = 0.7 0.1 -1 -1
			key = 1 0 0 0
		}
		%drag
		{
			key = 0 0 0 0
			key = 0.5 1 4 4
			key = 1 2 0 0
		}

Should be pretty straight forward.... Air surfaces have maximum lift and drag at 30Ã‚Â°(0.5), with lift dropping fast and drag increasing after that.

30Ã‚Â° I think is pretty generous angle. Overall I think this should simulate proper stalls better. What'ya think?

NathanKell · September 3, 2015

1. It converts a taper coefficient into a drag coefficient (where the taper coefficient is the average of all surface normals dotted with the velocity vector, so a flat surface would have 1 and an infinitely fine surface would have 0).

2. Yes.

3. Lift is area * Q * lift(sin(alpha)) * liftMach(mach) * global lift multiplier. Note that the lift curve has as its x value the sin of the angle of attack.

What you're missing regarding the curves, as I _think_ Claw explained earlier in the thread but I'll repeat, is that KSP's wing lift and drag curves are quite funky because KSP doesn't model sweep or aspect ratio or anything other than area and alpha for wings, so the curves have to stand in. In order for gliders to feel right when gliding, and jets to feel right at Mach 2, and spaceplanes to feel right hypersonic, all wings have to be all things to all craft; when craft are slow, the wing area is assumed to be high-aspect and unswept; when you go fast, KSP then assumes your wing area is highly swept and low-aspect. Etc. Yes, this means that high-AR, unswept wings won't prevent you from going fast, and low-AR, swept wings will still give you very slow stall speeds, but that's a price that KSP devs felt worth it for the simplicity, and indeed is even a good thing in some circumstances since it makes plane design and spaceplane takeoff/landing rather easier.

4. MM syntax issue. That will just insert those keys in addition to the existing keys. You presumably want !lift {} followed by lift { those keys } to clear the node and recreate it (and the same for drag).

Gfurst · September 3, 2015

Thanks NathanKell, again!

1. It converts a taper coefficient into a drag coefficient (where the taper coefficient is the average of all surface normals dotted with the velocity vector, so a flat surface would have 1 and an infinitely fine surface would have 0).
2. Yes.
3. Lift is area * Q * lift(sin(alpha)) * liftMach(mach) * global lift multiplier. Note that the lift curve has as its x value the sin of the angle of attack.
What you're missing regarding the curves, as I _think_ Claw explained earlier in the thread but I'll repeat, is that KSP's wing lift and drag curves are quite funky because KSP doesn't model sweep or aspect ratio or anything other than area and alpha for wings, so the curves have to stand in. In order for gliders to feel right when gliding, and jets to feel right at Mach 2, and spaceplanes to feel right hypersonic, all wings have to be all things to all craft; when craft are slow, the wing area is assumed to be high-aspect and unswept; when you go fast, KSP then assumes your wing area is highly swept and low-aspect. Etc. Yes, this means that high-AR, unswept wings won't prevent you from going fast, and low-AR, swept wings will still give you very slow stall speeds, but that's a price that KSP devs felt worth it for the simplicity, and indeed is even a good thing in some circumstances since it makes plane design and spaceplane takeoff/landing rather easier.
4. MM syntax issue. That will just insert those keys in addition to the existing keys. You presumably want !lift {} followed by lift { those keys } to clear the node and recreate it (and the same for drag).

1. Wait what? Is this something new or did I miss it? So basically its another multiplier for overall drag? Very :confused:

Is this what you mentioned here?

As of 1.0.3 the drag per face of a cube is no longer just the curve evaulation times area times weightedDrag, it's now curve evaluation times area times

3- I got this, I just found it rather strange that with would be valued 1 at 0 mach, whats keeping the vessel from floating around?

4- Oh yeah, I thought the '%' operator replaced the values, but that is a node. Thanks I'll correct it.

NathanKell · September 4, 2015

You're welcome.

1. Yep.

3. It's because Q will be 0 when velocity is 0 so you don't have to worry about it; liftMach describes an additional multiplier based on mach, which trends towards 1.0 as mach approaches 0, you don't have to account for 0 velocity more than once.

Gfurst · September 4, 2015

It's because Q will be 0 when velocity is 0 so you don't have to worry about it; liftMach describes an additional multiplier based on mach, which trends towards 1.0 as mach approaches 0, you don't have to account for 0 velocity more than once.

Wait what? I was under the impression that Q was the atmosphere density factor. What is it then?

Claw · September 4, 2015

Q is dynamic pressure.

Overhauls for 1.0

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation