DRAG_CUBE help

[Fwiffo]

I'm creating scaled-up versions of the ROUND-8 Toroidal Fuel Tank, and need a hand with drag cubes.

The stock part has a custom DRAG_CUBE defined as follows:

//     AREA        DRAG COEFF   DEPTH
cube = Default,
       0.2859113,  0.6272321,   0.6734665,     // X+ FACE
       0.2859113,  0.6268581,   0.9227022,     // X- FACE
       1.21,       0.96,        0.2872447,     // Y+ FACE
       1.21,       0.96,        0.245615,      // Y- FACE
       0.2958315,  0.6112254,   0.6440083,     // Z+ FACE
       0.2958315,  0.6160544,   1.104762,      // Z- FACE
       0,          0.02261333, -2.695719E-09,  // BOUNDS CENTER
       1.152236,   0.3307782,   1.135139       // BOUNDS EXTENTS
//     X           Y            Z

In one case, I'm scaling the part by a factor of 2.2 along the X/Z axes, and 4.15 along Y axis. I'll also be moving the Y-coordinate of both attachment nodes up to 0.43 so the tank wraps nicely around the exhaust manifold of a Poodle engine when mounted above it (yes, there will unfortunately be a bit of clipping, but hopefully we don't need to get into that here).

    MODEL
    {
        model = Squad/Parts/FuelTank/fuelTankToroidal/model
        position = 0, 0, 0
        scale = 2.2, 4.15, 2.2
    }

To visualize it, red is the stock part, and blue is my scaled up version (note some of the values may be approximate):

I'm trying to figure out how I should adjust the drag cubes to sensibly represent the increased drag of the bigger part.

I read the following links:

• Drag cubes introduced
• Explanation and "OMG" Experiments
• Image showing XYZ face orientation
• Drag cube scaler/calculator and its announcement

But still have some basic questions on how they work:

1. In general, how "tightly" should the values correlate to my part geometry?  e.g. Should I be doing calculations based on the dimensions of my part?  Or is the system just an imaginary way of visualizing multipliers which should be tweaked using best judgement?  (Since drag cubes also affect buoyancy, I'm assuming they need to be fairly tightly coupled to part geometry, and if you start going willy-nillie to tailor the drag you'll end up with unwanted side effects in the water... unless you decouple the drag/buoyancy cubes via buoyancyUseCubeNamed)
    
2. I infer AREA should roughly correspond to the surface area my part presents to the given face.  Should it be calculated from a projection of my part onto that face (or maybe from an outline of the cross-section made at DEPTH)?
   
   e.g. The stock toroid projected onto the Y+ face (i.e. viewed from above) looks like this (numbers approximate):
   
   
   So the area is roughly 0.74m² (or 1.04m² if you ignore the hole in the middle).  That's a bit smaller than the 1.21m² area in the stock DRAG_CUBE above (I guess for whatever reason Squad used a slightly bigger outer diameter of 1.24m).  But what I'm really wondering is why did they ignore the hole in the middle?  Does that mean I won't get the benefit of reduced drag from the air rushing through the middle?  (It's a valid question - I could build a craft where that hole isn't occluded)
    
3. How does DEPTH work?  Is it to tell the game something akin to where "tip" drag ends and "surface" drag begins?
   
   @NathanKell said it should be "depth of widest point from the frontmost point at that angle".  I assume that means if you have, for example, a part that looks like a pencil pointing upward, then the DEPTH of the Y+ face should be equal to the length of the pencil's tapered tip, like so:
    
   
   The widest point of the stock toroid tank is at its equator.  So I'd expect DEPTH for its Y+/Y- faces to be roughly half the height of the part - but they're both nearly the FULL height.  Similarly, X-/Z- are only slightly less than the full outer diameter (while I'd expect them to be much smaller, about equal to the outer radius), and I'm totally confounded as to why they're so different from their X+ and Z+ counterparts.  The mesh looks reasonably symmetrical.  Does it have something to do with the little gauge dial on one side?  If so, why's that bugger have such a big effect, and why doesn't the effect come into play when the wind's coming from the opposite direction?
    
4. Any advice for determining the drag coefficient?  Is it intended to be adjusted to represent the "pointiness" of my part in the given direction (and perhaps the "slipperiness" of the material composing its surface)?  Do I have a fair bit of leeway to adjust it (without causing unintended side-effects e.g. to buoyancy)?
    
5. What are the extents of the drag cubes (last tuple) used for?  e.g. Does it come into play when the game compensates for occlusion of stacked parts?
    
6. Any general guidelines would be helpful.
   
   e.g. At one point @NathanKell said that for "a stackmounted hollow part" like a cargo bay, the Y+ and Y- area values should be adjusted to match the non-hollow version of that part.  That's a very easy-to-use piece of advice that seems to make sense intuitively :-).
   
   Another one was "If the part is not hollow in terms of mesh, but should be (in terms of it being an intake with a flat black section that's supposed to represent a hole), you play with the drag coefficient (second number in the triplet) in the intake's incoming axis."  Although I'm wondering, could you not simply "fake" a hole in the drag cube (regardless of whether it's in the mesh) by subtracting the opening's area from the face it points toward (i.e. poke a hole like I want to do with the toroid above, but only for the face the intake faces)?
    
7. Have the part-level tags dragModelType, maximum_drag, minimum_drag and angularDrag been deprecated?

Edited August 15, 2016 by Fwiffo
Clean up after more research, and correct last image

[Fwiffo]

Here's the new DRAG_CUBE I came up with, let me know if it makes any sense:

//     AREA        DRAG COEFF  DEPTH
cube = Default,
       2.6103702,  0.6272321,  1.4816263,   // X+ FACE
       2.6103702,  0.6268581,  2.0299448,   // X- FACE
       5.8564,     0.96,       1.1920655,   // Y+ FACE
       5.8564,     0.96,       1.0193022,   // Y- FACE
       2.7009416,  0.6112254,  1.4168183,   // Z+ FACE
       2.7009416,  0.6160544,  2.4304764,   // Z- FACE
       0,          0.0938452,  0,           // BOUNDS CENTER
       2.5349192,  1.3727295,  2.4973058    // BOUNDS EXTENTS
//     X           Y           Z

To get there, I multiplied the area of each drag cube face by the scaling factors of the orthogonal axes, e.g: <New Y+ area> = <x scaling factor> * <z scaling factor> * <original Y+ area>
And I multiplied the depth of each face by the scaling factor of the normal to that face, e.g: <New Y+ depth> = <y scaling factor> * <original Y+ depth>
Then I adjusted the center / bounds accordingly.
I didn't touch the drag coefficients, for now.

Here's the full part file if anyone else wants to try it out.

Still would love some help on the questions in the original post to get there from first principles.

Edited August 15, 2016 by Fwiffo
Added link to entire part CFG file

[Stone Blue]

I'm not even sure this would apply, as I can barely do simple math anymore, but might this help to figure out "scaling" curves?
 

 

[NathanKell]

Remove the custom drag cube entry, let the game generate one for you. Then when everything else is done, add a copy of that as the custom entry and edit the Y+ and Y- areas to be the same as a circle of that diameter, rather than a torus (i.e. pretend the hollow bit doesn't exist).

[Fwiffo]

@NathanKell Ah, well, that certainly seems simpler :-).  Why do we pretend the hole doesn't exist?

I know you guys are super busy, but if anyone with know-how and time is reading this, I'd still love more explanation on some of the questions raised above (unless I'm just completely off base...).

Thanks!

[NathanKell]

Because it needs to occlude what's above and below it in the stack. Otherwise the drag system will think their ends aren't fully occluded.

 

The numbers are as you say, area/Cd/depth in six triplets, then center, then extents. On scaling, it goes like this:

X: y scale * z scale for area, keep, X scaling for depth

Y: x * z scale, keep, Y scaling

Z x * y scale, keep, Z scaling

 

Centers and extents get linearly scaled in each axis.

 

Regarding the questions, drag cubes are rendered using 256x256 textures, so the numbers won't be all that perfect. To keep things in line with other parts, that's why I suggest letting KSP generate them for you and then tweak, rather than creating them from whole cloth. Depth is as you surmise, it just sounds like there's some kind of render issue. It's used for thermo occlusion (to know what parts are hiding other parts, you need to know how wide the part is at its widest point, and how far back that widest point is from its tip).

 

Drag coefficient is just the average dot between the face normal and the inverse of the camera axis. So a hemisphere would have 0.25 here, because the average across its face is 0.25. A plane has 1.0 because its normals are perfectly aligned with the camera axis. A cone or wedge would have cos(halfangle). Etc.

[Fwiffo]

Thanks @NathanKell, appreciate the extra detail.  I had to re-read it a couple times but it's starting to sink in.  One thing I'm not sure what you meant by was "it just sounds like there's some kind of render issue".  I was working off the numbers in the file, not looking at any sort of in-game drag renderings (had actually forgotten you could even do that!).  So I'm still no closer to understanding where the depth numbers I highlighted as "huh?" in the Toroid tank come from.

Great examples for drag coefficient, that really helped it to make sense.

 

Edited August 17, 2016 by Fwiffo

[NathanKell]

As I mentioned, the numbers in the file are created by rendering the part onto a 256x256 canvas, once each per the six sides. (Area is computed by number_of_opaque_pixels / (256x256), Cd is computed by sum(normal at each pixel) / (256x256), etc).

[Fwiffo]

Ahh!  Got it.