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

[RocketRockington]

1 hour ago, Heretic391 said:

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. 

KSP used to have some pretty extensive debug info on aero, both in the PAW and visual info you could render .  Shame that seems to only be a developer tool in Unity now in KSP2.

51 minutes ago, Pyritin said:

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?

Since this is a copy of KSP1's system, it's the 'act like it wasn't translated' option.

[Dakitess]

Thanks for the detailed informations, it was a nice read !

Sadly, i'm quite concerned that, indeed, we fall back to KSP1 dead ends while it's the opportunity to do better... This system has shown a lot of limits we just honestly know won't be overcomed, and it's annoying.

Not everything need to be redone from scratch, but it looks like barely nothing does. And everything that had been brought from KSP1 is globally less effective, buggy, not finished, so... Yeah hard top see any benefice so far.

I can't understand why we are facing the same issues, the same dev debugging that we had in KSP1, but in even worse, and while having... KSP1 as a basis. It very looks like we are seing a KSP game being born without any predecessor before it. But it's not. KSP1 exist and yet "we" face the same dev issue as the original indie team that actually create something at its time. We face the same known deadends and still go for it, toward the wall.

Sure it might end with something working OK-Ish, like KSP1. But... Why ? Why sticking to this solution and not trying something "next-gen", something that would set appart KSP2, more realistic/reliable, along with many others uprades rather than doing again KSP1 in a slightly (sic...) better graphics and a New UI ?...

Damn.

Edited June 16, 2023 by Dakitess

[RocketRockington]

12 minutes ago, Dakitess said:

Sure it might end with something working OK-Ish, like KSP1. But... Why ? Why sticking to this solution and not trying something "next-gen", something that would set appart KSP2, more realistic/reliable, along with many others uprades rather than doing again KSP1 in a slightly (sic...) better graphics and a New UI ?...

My guess is its because that's the general direction Uber/Star Theory/Intercept took.  While they told us they were improving physics and fundamentals - killing the kraken! Better physics in every way! -  mostly KSP2 is about applying a lot of shiny paint, adding tutorials to try to get new customers, and then the features they decided to add that we're going to wait (at least) a couple more years for. 

I've seen basically 0 improvements to anything I'd call a 'fundamental' - same or worst physics.  Same or worse aero.  Same or worse orbital mechanics(though we're promised some hacked up 3-body for exactly one planetary pair?  That seems weird but maybe).  No heating - likely 'same or worse' when it gets here.  Same or worse power system.  Same or worse resource system.  List could just go on and on.  

Edited June 16, 2023 by RocketRockington

[eekee]

9 hours ago, RocketRockington said:

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.

It's certainly possible to model translation and rotation correctly, and I'm sure this world contains tens of millions of people with the mathematical skills to explain to the devs how to do it. Mathematics makes things easier when you understand what you need to. The fact that KSP 1 has gone so many years without fixing its horrible occlusion bugs is a sign of persistently poor choices, and I'm dismayed to see KSP 2 chasing down the same rabbit hole of poor choices. The answer here is math. Math would fix KSP1 model, math is necessary for correct implementation of a depth & normal-only render, and math is necessary for any other solution. Learning the math necessary for these jobs may be hard, but once learned it makes the jobs so much easier.

The only sword that can slay the Kraken is Mathematics! (Read that in ShadowZone's voice. ) Perhaps not true for some tentacles of the Kraken, but I thought we needed a little humor.

Edited June 16, 2023 by eekee
Needed some humor

[lingfors]

18 hours ago, The Aziz said:

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

As a dev, this is absolutely false. A good QA departement, that provided good bug reports that quickly let's us fokus on fixing the bug, is invaluable.

A crappy QA departement, that provided too little information, or sometimes flat out wrong information, is really frustrating though.

[Mutex]

14 hours ago, RocketRockington said:

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.

How much impact would that have on performance? Because while that would work much more reliably, the advantage of KSP's approach is that it's fast, you can calculate how much of each part is unoccluded from each direction once at the start.

EDIT: Thinking about it, perhaps an improved version of the way it currently works, which would still be fast, is to generate a cube-map of the entire ship at the start. Obviously re-generate it every time the ship changes (docking, parts breaking off). This would still be a pretty limited simulation, and it wouldn't take account of the ship deforming/bending severely, but it would at least probably be more robust than doing this part-by-part. (EDIT2: Actually this wouldn't work if/when we get robotics, or anything else that makes the shape of the craft dynamic.)

Edited June 16, 2023 by Mutex

[S_Coriolis]

I'm no programmer, but I was wondering if this area-area occlusion could be used to calculate the rigidity of nodes between parts or simply using the node tier is ok ? I'm thinking that radially attached parts may be more structurally sound, or maybe do the same as for the procedural wings and add more nodes for big parts like attaching a XL tank. 

Also thanks for the explanation and the great parts you made 

[Mushylog]

Very insightful, very interesting too! I love the witty descriptions of the images "Chris paintovers, terrible MS paint scrawls trying desperately to get a point across"

Thanks for this Dev Diary!

[Kavaeric]

Very interesting, I appreciate the way we can get insight onto the stages of game dev we don't usually get to see (even if some don't/won't appreciate it...)

20 hours ago, Nertea said:

FAR does a bunch more than area facing calculations and we determined that it wasn't the right solution for KSP2.

Now I'm curious about how this decision was determined—from my understanding FAR builds an aerodynamic mesh by calculating for the entire craft as a whole. Was it a performance consideration or a gameplay we-want-it-realish-but-not-simulator design consideration?

Curious too as well if there may be a way to still advance the drag cube model from taking inspiration from FAR. From what I understand FAR does a whole-craft aerodynamic model; maybe a system that generates drag maps for the entire vessel as a whole on launch would help reduce aerodynamic/occlusion calculation overhead? It would mean that it'd have to be re-calculated if you e.g., decouple or lose a part, though; unsure if the trade off is worth it aside from maybe planes which are almost always in atmosphere and don't really stage like rockets do.

Also as pointed out previously, but I have to as well: guy's work has resulted in an entire genre of modding for KSP1 (NFT + ReStock + KA + SSPX + Cryo + OPM + life support mod/Kerbalism) which basically got him hired on the spot and has the nerve to say

On 6/15/2023 at 12:55 PM, Intercept Games said:

a few mods

(You can brag a little, man!)

Edited June 16, 2023 by Kavaeric

[RocketRockington]

9 minutes ago, Kavaeric said:

Now I'm curious about how this decision was determined—from my understanding FAR builds an aerodynamic mesh by calculating for the entire craft as a whole. Was it a performance consideration or a gameplay we-want-it-realish-but-not-simulator design consideration?

Considering they kept wobble rockets on purpose too, I think its mostly that whoever made these decisions in the early days (and I suspect I know who) thought that some of the goofy/cartoony physics from KSP's early days was one of the things that made it successful, rather than an artifact of KSP still figuring itself out (given that KSP later added autostruts to much rejoicing). 

It *really* seems like idiosyncratic design vs looking at general community sentiment and the general desires of the average KSP player.

[Nertea]

16 hours ago, Strawberry said:

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?

Hah, I can't really say that I'm an artist (my non-KSP life is systems architecture and software) - my role as a designer is a lot more general and I tend to limit my art contributions to part concepts. I tend to focus more on systems and how they fit together, I just happen to like making models of parts at times.

14 hours ago, Pyritin said:

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?

It is partial and handles rotation but not translation (an artifact of how the system is set up). This one's a hard one, because players use the translation and rotation tools to do cool builds and make exciting things that are often decidedly unaerodynamic. There's a narrow line between simulation and gameplay which we toe a lot, and I would love to write more about - IMO one of the most interesting things about this game. Reality is often punishing, and the right amount of punishment is a tough thing to determine!

13 hours ago, RocketRockington said:

KSP used to have some pretty extensive debug info on aero, both in the PAW and visual info you could render .  Shame that seems to only be a developer tool in Unity now in KSP2.

I think using debug tools for flight isn't the best solution out there and it folds nicely into the overall discussion the team has about creating and improving useful planning tools for all systems in the game.

1 hour ago, Mushylog said:

Chris paintovers, terrible MS paint scrawls trying desperately to get a point across

I don't think you're really getting the full experience unless I'm ruining a really nice piece of concept art on a zoom call  . 

8 hours ago, Dakitess said:

Sadly, i'm quite concerned that, indeed, we fall back to KSP1 dead ends while it's the opportunity to do better...

I wouldn't characterize the drag cube-based system as a dead end. Sure, there's room for improvement, as with any system, and there are some addons in KSP2, but it is broadly a computationally clever solution to a very complex problem.

Always happy to discuss where you think it falls over and fold that into our internal discussions. 

2 hours ago, Mutex said:

EDIT: Thinking about it, perhaps an improved version of the way it currently works, which would still be fast, is to generate a cube-map of the entire ship at the start. Obviously re-generate it every time the ship changes (docking, parts breaking off). This would still be a pretty limited simulation, and it wouldn't take account of the ship deforming/bending severely, but it would at least probably be more robust than doing this part-by-part. (EDIT2: Actually this wouldn't work if/when we get robotics, or anything else that makes the shape of the craft dynamic.)

At least half of the complexity of this game is due to the... complexity. Anytime we have a new feature or even one we want to port from KSP1, the challenge is in handling the solution for a complex vessel. The individual part-based approach has some advantages here (and disadvantages - all about those trades). 

[jclovis3]

I think now I am seeing another issue with this method of occlusion that may impact cargo bays and dynamic Fairings, which is that occlusion of a forward part is only tied to the one part behind it and that second part does not pass on the occlusion to the next part but simply provides only itself as the occlusion to the 3rd part. You "fixed" this by manually filling in the center of hollow tubes and perhaps in-line decouplers but this does not address the problem with the many dynamic ways people may build craft and the cargo bays and fairings issue. I think using the same technique to calculate the cube for a part should be used on the whole craft after construction and again after any part separation or connection (docking or EVA construction), but this of course would not allow noticed changes in the ship shape (bending under atmospheric stress) from to apply changes in these occlusions either. I can see why you would rather have per part occlusion in this sense, but there needs to be a way for that occlusion to cast down throughout the ship, not just to the next part.

I propose a "union" of occlusions such that the occlusion from the first part be logically unioned with the next part to generate the effective occlusion of that part onto the 3rd part, and so on. This will also ensure that a big part up in the front will shield every smaller part that trails behind it. What's more, you can allow for a conical reduction in this union over distance as measured by speed (or maybe not conical but parabolic) to account for air stream collapsing in toward the smaller parts but that a pocket of air would still exist in the lee of the larger part.

Lastly, the occlusion of dynamically constructed fairings would use the union approach with each segment start and ending just as if they were unique parts and ensure that even a parabolic reduction in the size of the occlusion is reinforced by the size of the next segment.

[cocoscacao]

How does drag affect clipped parts? Is it possible to compute that...?

[Pat20999]

1 hour ago, Nertea said:

Hah, I can't really say that I'm an artist (my non-KSP life is systems architecture and software) - my role as a designer is a lot more general and I tend to limit my art contributions to part concepts. I tend to focus more on systems and how they fit together, I just happen to like making models of parts at times.

It is partial and handles rotation but not translation (an artifact of how the system is set up). This one's a hard one, because players use the translation and rotation tools to do cool builds and make exciting things that are often decidedly unaerodynamic. There's a narrow line between simulation and gameplay which we toe a lot, and I would love to write more about - IMO one of the most interesting things about this game. Reality is often punishing, and the right amount of punishment is a tough thing to determine!

I think using debug tools for flight isn't the best solution out there and it folds nicely into the overall discussion the team has about creating and improving useful planning tools for all systems in the game.

I don't think you're really getting the full experience unless I'm ruining a really nice piece of concept art on a zoom call  . 

I wouldn't characterize the drag cube-based system as a dead end. Sure, there's room for improvement, as with any system, and there are some addons in KSP2, but it is broadly a computationally clever solution to a very complex problem.

Always happy to discuss where you think it falls over and fold that into our internal discussions. 

At least half of the complexity of this game is due to the... complexity. Anytime we have a new feature or even one we want to port from KSP1, the challenge is in handling the solution for a complex vessel. The individual part-based approach has some advantages here (and disadvantages - all about those trades). 

Chris, is the new “torch drive” the salt water drive.

[Strawberry]

3 hours ago, Nertea said:

Hah, I can't really say that I'm an artist (my non-KSP life is systems architecture and software)

I mean, those parts do look pretty and that's like what a third of all art is about

Edited June 16, 2023 by Strawberry

[asmi]

On 6/15/2023 at 5:20 PM, 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.

Actually a hacky crap that was described in the article will give you no end of headaches due to endless supply of edge cases. The proper way to do it is to render vessel from the airflow's POV with orthographic projection and linear depth, use shader which captures depth into texture, and then run a simple compute shader over it to calculate a drag based on how much of a texture has depth written out (this is the simplest possible model). More advanced model would calculate slopes (dz/dx and dz/dy) and drag values would be based on those slopes (this way more "aerodynamic" shapes would indeed be more aerodynamic and have less drag). This approach also provides a permanent fix for cargo bay occlusion problems as a free bonus with no further hacks required (because what's inside the bay will not render into depth texture at all, or will be overwritten by closer surfaces depending on how you set up your render pipeline and how good you are at culling stuff). And - most importantly - since this approach actually models how airflow works (ignoring mach effects and some other things like skin drag, flow separation, shock waves, etc.), it does not depend on part setup or vessel composition - it only cares about the shape which is presented to the airflow. Which is how it should be.

If you worry about possible performance issues, you can only run these calculations every X frames as opposed to every frame, and interpolate drag in between. This might even be a configurable option in the settings.

Edited June 17, 2023 by asmi

[febrion]

Love the insights here - I honestly^N thought the drag model was much simpler myself...  I just assumed^U that when I build a craft, the design was then sent somewhere and a model of the craft was 3-D printed.  Somebody then threw the model around a few times, taking note of how it performed, and sent this data back to my computer to be used in-game.

Seriously^C, though, I've seen bugs like this before^B, so definitely feel your pain.  I'm a little confused about the occlusion model though⁴², or at least the way I understand it from this summary.  It sounds like each part is only affected by the next one up in the stack, but it does feel like parts more than one step up should also have an impact (at least somewhat).  If you have a massive part on top - say 20m just to have numbers, followed by a 5m wide part, then a 10m wide one³, the second part is fully occluded, but the third is not.  Depending on how long each part is, and how fast the craft is traveling, the third part should have at least some occlusion from the first.  This would also apply to radial parts.  I'm assuming in this model a radially attached part would not be occluded at all, but if^E for example a set of boosters was radially attached at the top of the craft, and a second set radially attached (in-line with the first set) at the bottom of the craft, I would expect at least some occlusion^O from the upper set of boosters.

Anyway, I'll be here waiting patiently for the next update - and maybe I'll be less busy myself then and able to come up with a more coherent (and timely) response.  Or maybe I won't.  You'll just have to wait and see.......

 

I dare you to read all the footnotes^R

Spoiler

^FAnd by "honestly" I meant "did not at all, but wouldn't it be funny if"  I thought it was funny, anyway

^MYeah, classic blunder - though since I've already admitted (see previous footnote) that i wasn't being serious, that also means that I didn't assume anything. 

³Yes, I CAN be serious, I just choose not to most of the time

⁴Some of the most annoying bugs I've ever run into only took about 5 seconds to fix.  Finding the actual error in the code, the place to put the fix, is the part that took days or even weeks.

¹³Of course, this is more of a design question than an implementation one - but I'll ask it here anyway

³⁵While that sounds like a really dumb rocket design, I wouldn't put it past me....

^CI've done dumber things, so it probably will happen at some point

^KIf I keep typing "occlusion", I'm going to stop looking like a real word... I need to wrap this up anyway

⁷I dare you to skip all the footnotes

 

[KawaiiLucy]

I wonder, why not build drag cubes for the whole vessel and each stage independently, which would be built from the drag cubes from each part, so instead of having lots of drag cubes at once, have bigger drag cubes which represent stages as single entities?

Of course the drag cubes would have to be recalculated each time you unexpectedly loose a part in flight.

[000PainKiller000]

Question1: 

How do liquid hydrogen tanks behave? I'm asking because it's not clear to me. Visually, when nothing is connected to them, they seems like a big streamlined orb, with a little metal skeleton. Mostly is shouldn't be a draggy part. However, i can see that in the front and back (and also on it's side) there are connection nodes. According to ksp1 logic, if those are not covered, they should have big draggy surfaces right? 

But when i do cover them up  (maybe with an aerodynamic nose cone), especially looking on it's back side, they seem super blunt. Is this really actually helping? Or i have to use some kind of fairing or cargo bay to have it covered? 

https://ibb.co/3h5Vr34

Question2: 

Can we get back the F12  aerodynamic debug toolbar thingy? It would make it much easier to see the changes in the next patch. It would be even better if it was represented with vector arrowes like in ksp1, so we can direcly see how much drag / lift is being generated. 

edit: how do i upload images lol? this url thing is not what i was looking for. 

Edited June 17, 2023 by 000PainKiller000

[twich22]

On 6/15/2023 at 12:55 PM, Intercept Games said:

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.  

 

Hopefully the implications of this bug extend beyond just aerodynamics. I have run into numerous bugs that have to do with part orientation and parts thinking they are oriented one way when they are not supposed to be. I suspect all these bugs are stemming from the same root cause. 

[Lyneira]

On 6/16/2023 at 8:19 PM, cocoscacao said:

How does drag affect clipped parts? Is it possible to compute that...?

Clipping a part does not affect drag. The drag cube system uses only node attachments and the part orientations to decide whether and how much a part occludes another.

[Lyneira]

On 6/16/2023 at 7:47 PM, Kavaeric said:

Now I'm curious about how this decision was determined—from my understanding FAR builds an aerodynamic mesh by calculating for the entire craft as a whole. Was it a performance consideration or a gameplay we-want-it-realish-but-not-simulator design consideration?

I've played a little with FAR in KSP1 and it's quite the interesting rabbit hole to learning more about aerodynamics with it! There are a lot of things simulated by it, like area ruling, that can wildly affect the stability of your plane in ways that are not easy to foresee. In order to make a good plane that flies well, I had to lean heavily on older real world plane designs that were made to be naturally stable without the fly-by-wire assistance that modern planes have now (SAS can only do so much). Or else, I'd be spending hours with the area ruling simulator and drag number tables to try and tweak out strange instability issues for a design that's a little more unconventional.

I think that at least these above two traits played into the decision not to go for a FAR-like model:

• Much harder to understand what adding and changing parts on a plane does to its stability and having to spend hours tweaking a plane to get the drag number tables and the curves in the simulator graphs to a good state. This information would have to be represented in a much better way to make a FAR-like system feasible in core KSP, and tutorials made that can somehow make these concepts accessible to new players.
• In both KSP1 and KSP2, we have offset and rotation tools that make it trivially easy to clip parts into each other. The "build-a-whole-craft-mesh" approach of FAR means that it is trivially easy to cheat on drag by clipping fuel tanks and other parts into each other, with FAR treating it as an impossibly dense aerodynamic hull. And there would be major incentive to do so, because you could make planes that have very little forward drag for their mass. With drag cubes, there is no advantage to clipping parts into each other and so plane designs don't have much reason to use part clipping other than for aesthetics purposes. (1)

Footnote:

Spoiler

1. In KSP1, there were some ways to trick the drag cube system to cheat on drag a bit too but they involved fairings and cargo bays and I believe these could have been patched out if Squad had wanted to. I hope they will keep the "magic wings" that use cargobay-shielded heatshields out of KSP2 at least.

 

Edited June 18, 2023 by Lyneira

[Lyneira]

On 6/16/2023 at 8:07 PM, Nertea said:

I think using debug tools for flight isn't the best solution out there and it folds nicely into the overall discussion the team has about creating and improving useful planning tools for all systems in the game.

While I agree with this, given all the other things the team has on their plate, it doesn't look like an improved UI for presenting more aerodynamics information in either the VAB or flight is forthcoming any time soon. Players currently have insufficient information about how much drag and lift their planes are creating, and this was made worse by the removal of the F12 Aero gui window in the most recent patch. More than just aiding advanced players, restoring the Aero GUI shortcut and a debug option to show some aerodynamic debug information in the part manager would also enable players to help zero in on aerodynamics issues caused by specific parts, combinations of parts, fairings and cargo bays as well as any overall aerodynamics bugs remaining after the issue you highlighted in your dev diary is fixed.

Edited June 18, 2023 by Lyneira

[JoeSchmuckatelli]

On 6/16/2023 at 10:02 PM, asmi said:

you worry about possible performance issues, you can only run these calculations every X frames as opposed to every frame, and interpolate drag in between. This might even be a configurable option in the settings.

I like the description in your post - a question:  I was surprised to see a recommendation of running the calculations in terms of frames.  Would this be possible to do as part of the 'exiting the VAB' process, and then only recalculate whenever there is a change to the craft (such as triggering decoupler / opening a payload / extending a part?)?  If it were done prior to launch, could it remain persistent through the entire flight (planes) or is there something that needs fairly frequent calculation? 

Edited June 18, 2023 by JoeSchmuckatelli

[asmi]

17 hours ago, JoeSchmuckatelli said:

I like the description in your post - a question:  I was surprised to see a recommendation of running the calculations in terms of frames.  Would this be possible to do as part of the 'exiting the VAB' process, and then only recalculate whenever there is a change to the craft (such as triggering decoupler / opening a payload / extending a part?)?  If it were done prior to launch, could it remain persistent through the entire flight (planes) or is there something that needs fairly frequent calculation? 

No it's not possible, because the shape presented to the airstream is going to depend on a direction of that airstream relative to the vessel, and so it's not feasible to pre-calculate all possible directions in advance, especially since every time the craft changes, it will have to be re-calculated. Also real-time calculations will take into account things like flexing, which can also lead to a change in a shape presented into the airstream.