Jump to content

Developer Insights #20 - Here there be Drag(ons)


Intercept Games

Recommended Posts

  • KSP Team

Hello! My name is Chris Adderley, a designer on the KSP2 team. If you’ve been around the community for a while, you may recognize my alias of Nertea from a few mods for KSP1 I have made. 

At Nate's request, I wrote up a description of how we tracked down a frustratingly resilient community-reported drag bug from KSP Forum user FlazeTheDragon for one of our Friday updates. It became slightly long, so we decided to make it a dedicated dev blog entry. It’s long because well, this was a complex bug to track down! 

To describe the bug, how it was found, and how it was sorted, I have to give a little primer on the KSP2 drag model and how it works with respect to parts and aerodynamic occlusion - so buckle up.  

Our drag model is very similar to KSP1's, where a part's aerodynamic properties depend on what we call the drag cube. This is a representation of what a part looks like in terms of aerodynamics from 6 orthogonal directions - front, back, top, bottom, left and right. Hence, a cube! We can project the direction of airflow onto this cube to get an approximation of what the air would 'see' and, therefore, what drag to apply. Drag cubes are calculated by rendering the parts' visuals using special shaders - they give us information about the part's area (white), bumpiness (green), and depth (red), for each of these directions. 

image.png

Drag cube renderings for the Size M conical command pod. 

We can aggregate these views to create three sets of six values – the drag cube itself. This is a very computationally efficient way to store a lot of information about the part. It’s a versatile dataset – besides aerodynamics, we can use this to get things like the dimensions of the pod, the displacement of the pod, etc.  

 

image.png 

Drag cube data for the Size M conical command pod 

So, a single drag cube is good for a part in isolation, but for a part that's attached to other parts, we need to determine how much of the part is actually exposed to the air (and eventually the airflow). That's the truly relevant part for calculating drag. Parts that are fully occluded by another part should effectively be invisible to airflow from that direction. You can think of this if you consider a fuel tank behind a cockpit traveling towards the pointy end of the vessel. If that assembly of parts is flying through the air, there should be no drag from the surfaces that connect the two parts.  

image.png

Schematic example of how we'd expect a vessel made of 3 parts to behave with respect to the occlusion of each of its faces 

To calculate this occlusion, we use the area component of both parts' drag cubes, which can give us the area of parts from various directions. Take two parts from the above image, Part 1 (the fuel tank) and Part 2 (the command pod), that are connected. We look at the connection direction and modify each part's drag cube areas. We subtract the area of Part 1 in the +Y direction from the area of Part 2 in the -Y. We do the same in the opposite direction subtract the area of Part 2 in the -Y direction from the area of Part 1 in the +Y direction. This gives us a very simple way of approximating occlusion. If both parts are Size S, for example, the area through the connection becomes zero. If one part is Size S and one part is Size M, the Size S part will be completely shielded by the size M part, but the reverse is not true.

  

 

image.png

Schematic example of subtracting drag cube Y+ and Y- faces for same-size parts, in two airflow directions 

image.png

Schematic example of subtracting drag cube Y+ and Y- faces for different-size parts, in two airflow directions 

I think that’s what you need to know about the basics of drag and occlusion. On to the bug!

We had community reports that were replicated by internal QA that some parts, like stacked decouplers, were affecting the aerodynamic performance of planes and creating too much drag. Planes that seemed like they should go fast went… slow. Exciting stuff - it's time for a bug hunt.  

If adding a part to a plane creates too much drag, maybe that part itself has too much drag. We have tools to automatically create drag cubes, and sometimes we tune them manually. That's the first point of investigation for the team. Looking specifically at per-part drag readouts, we didn't find that the parts described in the bugs had any kind of anomalous drag values in isolation. Things looked in-line with what we’d expect. In addition, we couldn't reproduce these issues with rockets. This issue only really showed up when looking at planes. Planes are frustrating for me as a developer as I'm a garbage pilot and reproducing airspeed/velocity conditions reported in bugs takes me quite a while! That KSP2 pause button sure is useful… 

So, eliminating general drag as a problem was a good first step. The next step would be identifying whether something was wrong with the occlusion system - but only for very specific parts. Hmm. Some of the specific parts identified were visually hollow tubes. Hollow tubes are a challenge for the drag occlusion system. Reading through my quick description of occlusion above, you might be able to see why, but let’s get into that.  

image.png

How a hollow part behaves by default in the KSP2 drag model to show how it doesn’t appropriately occlude the part below it 

The drag cubes for hollow parts are, well, hollow by default! When we go to subtract the cross-sectional areas in a connection, the hollow part has a tiny cross-sectional area, and so won't appropriately shield the next part in the stack. This is fine if the hollow part is first, but if it is in a stack with something else atop it, we want it to occlude properly.  

drag rocket 5.png

“Filling in” hollow parts to allow them to shield parts behind them 

We solve this in KSP2 by manually adjusting the drag cube areas of hollow parts: they appear opaque in cross section and so subtract appropriately. It's a dirty fix, but it works.  

So, decouplers are hollow. Some of the other parts reported with this bug are hollow. IDEA. Perhaps it's our process for manually adjusting this for those specific parts that is causing the problem. This caused a multi-day Chris wild goose chase of frustration and tweaking tiny numbers to no real solution. A clever reader might also realize something from the initial report that makes this avenue of investigation kinda silly in hindsight - if this was the problem, we should have seen this with rockets too, not just planes.  

Eventually while examining the results of the wild goose chase, we looked specifically at the cross-sectional areas used for calculating occlusion and noticed an "interesting" discrepancy when considering certain parts. Let's look at this closely: 

  image.png

In this image you get to experience some internally famous ‘Chris paintovers’, terrible MS paint scrawls trying desperately to get a point across. 

In the above image, I debugged the cross-sectional area for all the part connections on a demo ‘plane’. I noticed that the cross-sectional areas for the green and red highlighted parts were a little off. When looking at the green part, the game thinks that it has a cross sectional area of 1.19m2. This is… close to what it should be. But these parts have a radius of 0.625m2. That number should be closer to 1.23m2. Suspicious. The real problem is evident by looking at the blue part.  The game thinks it has a cross sectional area of 2.38m2. That is far too much area - again, it should be 1.23m2. This provided a reasonable area of investigation. I tried the same approach but with one of the problematic parts from the bug report - the size S decoupler. 

image.png

More live occlusion values 

Well, this is just plain wrong. The game thinks this connection between the decoupler and tank (in red) has a cross sectional area of 0.191 m2. Jackpot! If this area is wrong, then the fuel tank 'behind' the decoupler will not be correctly shielded at all from airflow - the game thinks there's only 0.191m2 occluding the tank's cross-sectional area of 1.23m2. If this 'plane' flies forward, the game will act like there's a 1.03m2 blunt front-fuel tank surface into the airstream and create significantly more drag.  

image.png

Drag Cube areas for the Size S decoupler 

Ok, great. So where's the problem? Well, let's look at the drag cube for the Size S decoupler. Any of those elements look familiar? The first two and last two numbers are the area from the top, bottom, right and left of the part. The middle two entries (front/back) should be the ones we're using for the decoupler - but we're actually using the bottom two. Nailed it down - that's the core of the bug.  

image.png

What we’d expect for post-occlusion drag (left) versus what we were getting (right) 

It turns out that when we calculate cross-sectional area in craft orientations that aren't purely vertical (like planes) we calculate drag occlusion incorrectly - we use the wrong face of the attached part's drag cube. This has pretty strong implications that depend on the length and size of the parts you'd use in a plane's stack.  

If a long part was in front of a short part, everything would appear fine. We'd be using the ‘side view’ of the long part with a large area, and that would be pretty good at occluding stuff (though actually TOO good). However, if you had a short part in front, additional drag would be introduced - not only because you'd not be occluding properly, but because that un-occluded area would be very un-aerodynamic! 

image.png

A silly example of what we’d see (left) versus what the occlusion model would see (right). In this case you get too much drag, because there’s not enough occlusion  

image.png

A second example of what we’d see (left) versus what the occlusion model would see (right). In this case you actually don’t get as much drag, because that Mk2 tank is occluding the Mk3 tank too much 

That's enough information for an engineer to develop a fix. In this case, the fix for the issue only needed 2 lines of code, which was great. Identifying the issue and narrowing down the exact cause was the harder part of this bug.  

Now, this isn't to say that drag issues are all solved in KSP2. But hopefully this provides a nice little tidy look at the somewhat messy process of going from a bug spotted by an eagle-eyed community member all the way to something we can fix.  

Link to comment
Share on other sites

Interesting and understandable!  

Asking a question, IIRC, FAR in KSP1 does similar but for the whole craft at a time, so it is the forward facing whole face of the craft in direction of travel.  Is there a reason this approach wasn't used for KSP2?

Link to comment
Share on other sites

1 hour ago, Intercept Games said:

In this case, the fix for the issue only needed 2 lines of code, which was great. Identifying the issue and narrowing down the exact cause was the harder part of this bug.

This is like 75% of the bugs I work on; tons of research, two lines of code.

Thanks for the detailed post!

Link to comment
Share on other sites

1 hour ago, The Aziz said:

Last time I heard that devs hate QA because they give them more work to do

The devs and QA have a fantastic relationship here at IG.  (I've been around a long time.... that's not always the case)

Link to comment
Share on other sites

3 hours ago, The Aziz said:

Last time I heard that devs hate QA because they give them more work to do

I love getting quality bug reports, however grumpy they may make me at the time!

3 hours ago, FlazeTheDragon said:

That was a pretty interesting read.

Glad to see its finally getting solved :p

Will this also fix cargobays not shielding their contents from drag, or is that a separate issue?

The funny thing is... that often when we solve a bug, we discover more bugs that were obscured by the issue itself, and this is one of those times. I can say for example that we discovered two smaller knock-on bugs from the work I described here that have also been fixed. We'd hoped the cargo bay drag would be sorted by this as well, but it turns out that it isn't completely solved yet - we are tracking that parts that are stack attached to the internal nodes of cargo bays are sometimes not correctly occluded by the bay itself. The test cases I used when evaluating whether this functionality worked used surface attachment (it seemed like the harder case) - not stack attachment , which we've now identified as a problem to look into for the next update cycle.

2 hours ago, regex said:

This is like 75% of the bugs I work on; tons of research, two lines of code.

Thanks for the detailed post!

No problem, I had an interesting time writing it up. I realized we didn't have a good description to the community of how our aero data is represented, so it was fun to be able to makes some little schematic diagrams of how things work!

3 hours ago, theJesuit said:

Interesting and understandable!  

Asking a question, IIRC, FAR in KSP1 does similar but for the whole craft at a time, so it is the forward facing whole face of the craft in direction of travel.  Is there a reason this approach wasn't used for KSP2?

I think we're open to trades in specific directions for aerodynamics going forwards, but it's not quite as simple as that! FAR does a bunch more than area facing calculations and we determined that it wasn't the right solution for KSP2.

Link to comment
Share on other sites

14 minutes ago, Nertea said:

I love getting quality bug reports, however grumpy they may make me at the time!

I'm starting working as QA, so in case you happen to have some of the hunting outsourced, and it turns out I am assigned to the project, I promise I'll do my best (or if not, I simply say that to whomever I may work for) :wink:

Edited by The Aziz
Link to comment
Share on other sites

4 hours ago, theJesuit said:

Interesting and understandable!  

Asking a question, IIRC, FAR in KSP1 does similar but for the whole craft at a time, so it is the forward facing whole face of the craft in direction of travel.  Is there a reason this approach wasn't used for KSP2?

No, this is an exact copy of how the KSP1 system works.  Redoing the code for KSP2 introduced the bug.

Its just a shame that KSP2 when with a solution that's going to have every problem that KSP1's system had with this sort of jank occlusion system.

Link to comment
Share on other sites

1 hour ago, Nertea said:

I think we're open to trades in specific directions for aerodynamics going forwards, but it's not quite as simple as that! FAR does a bunch more than area facing calculations and we determined that it wasn't the right solution for KSP2.

That's a pity.

FAR was a brilliant improvement to realism in KSP1.

Yes - it was not always easy to design something that works, but what you built behaved as you would expect.

Link to comment
Share on other sites

38 minutes ago, PyroSA said:

That's a pity.

FAR was a brilliant improvement to realism in KSP1.

Yes - it was not always easy to design something that works, but what you built behaved as you would expect.

FAR or KSP1 aren't the only options.  You could have calculated drag from a depth & normal-only render of the craft on the fly rather than a pre-baked render of each part that you sum.  Because unless the parts have each other attached by their attach nodes and never moved/rotated - or worse, don't even have attach nodes - KSP1's solution starts breaking badly.

That would have required more work than just copying KSP1's solution of course - but my god, what WAS 6 years spent on?

Link to comment
Share on other sites

7 hours ago, Intercept Games said:

Hello! My name is Chris Adderley, a designer on the KSP2 team. If you’ve been around the community for a while, you may recognize my alias of Nertea from a few mods for KSP1 I have made. 

Hello! My name is Harrison Ford. You may recognize my name from some movies I was in.

(Sorry I'll read the rest in quiet now)

Link to comment
Share on other sites

Super informative dev post! I do wonder, I know yall have talked about in the past making sure the people with the right set of tools work on the right set of things, Im guessing Chris is a special case due to already having good familiarity with ksp's code, thus allowing him to work on a wider array of things then your average artist?

Link to comment
Share on other sites

Very interesting. Would be nice if we can get the drag numbers visible in game so we can optimise our builds to be super aerodynamic. I recall there was some F12 option in game which showed the total drag at any given moment. 

Link to comment
Share on other sites

Out of curiosity is the occlusion logic an on/off sorta thing or does the model allow for partial occlusion. For example if the nose cone was placed on a rocket normally, and then translated up to create a gap between the two parts. Would the occlusion model partially occlude the top of the rocket (because the cone would then create a gap for air to pass through), act similar to as if the cone wasn't translated, or not occlude at all?

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...