Drag Model Discussion

[majic79]

I had a look but couldn't find anything, so I started thinking about the modular nature of KSP and how drag can work (and why the current situation causes problems).

So currently, an object has drag x which just stacks up, regardless of orientation, and then goes through a drag calculation (which doesn't take into account cross sectional area) and gives a universal figure of drag

I propose the following modifications: each face has it's own drag coefficient of drag and a pre-calculated surface area.

Calculating drag then becomes a function of summing all non-occluded faces (Faces that are not hidden by other faces, if they partially overlap, then there's got to be a calculation to determine the amount of "shadow" that the occluding face provides) that lie within 90 degrees of the direction of travel (faces 90-degrees to the direction of travel can maybe carry a parasitic drag factor?) multiplied by the sine of the angle of normal to the direction of travel. This function is fairly similar to incidental light calculations for flat shading, so the CPU load to calculate should be fairly insignificant for moderate sized rockets, perhaps insignificant on larger vehicles? Further optimisation becomes available in using tabled sine values for the multiplication and the automatic elimination of occluded faces can be done on leaving the VAB (the only time they will ever change is if a module is disconnected at the occluding face)

As a first approximation, this then permits nose cones to provide a positive effects on drag reduction, whilst also providing module force effects in atmosphere that are a little more true to life, without also going in depth to deal with actual aerodynamics. This could also be used as the aerodynamic system, as the drag force is also what provides uplift (via angle of attack).

Supersonic flow is the same formula, however heat effects come into play and make things a little more tricky - it'd be nice to see it included, but not essential?

[coolitic]

tldr some of it. The problem with what you suggested is that the physics for this are more complex resulting in reduced performance (afaik). Also makes game a bit more complicated.

[Comrade Jenkens]

something like a more simple version of far would be nice.

[ferram4]

Calculating drag then becomes a function of summing all non-occluded faces (Faces that are not hidden by other faces, if they partially overlap, then there's got to be a calculation to determine the amount of "shadow" that the occluding face provides) that lie within 90 degrees of the direction of travel (faces 90-degrees to the direction of travel can maybe carry a parasitic drag factor?) multiplied by the sine of the angle of normal to the direction of travel. This function is fairly similar to incidental light calculations for flat shading, so the CPU load to calculate should be fairly insignificant for moderate sized rockets, perhaps insignificant on larger vehicles? Further optimisation becomes available in using tabled sine values for the multiplication and the automatic elimination of occluded faces can be done on leaving the VAB (the only time they will ever change is if a module is disconnected at the occluding face)

This is not how aerodynamics works. Your system (since it's treating airflow like light and handling occlusion) will end up with very strange effects that are only ever realistic at Mach numbers well above ~5 (read: Kerbin reentry speeds only), but for anything lower they'll be completely incorrect (read: actually trying take off or land a plane). For example on this Cessna 172, at moderate to high angles of attack the vertical tail will be completely occluded from the airflow; this will result in no forces on the tail, which means that the plane will immediately go into a flat spin. Similarly, at negative angles of attack the main wing will occlude the horizontal tail, making the vehicle unstable in pitch. Now, Cessna 172's don't tend to go into flat spins after rotating to take off or become unstable if they have a negative angle of attack, so you're going to end up with completely unrealistic aerodynamics that will confuse players a lot.

You'll get the same effects with pretty much any plane that doesn't have the vertical tail mounted below the fuselage and that doesn't have its horizontal tail mounted below the main wing. Players will be completely unable to look to real life for aerodynamic solutions, which is really, really bad, since aerodynamics isn't a simple thing to learn to deal with.

As a first approximation, this then permits nose cones to provide a positive effects on drag reduction, whilst also providing module force effects in atmosphere that are a little more true to life, without also going in depth to deal with actual aerodynamics. This could also be used as the aerodynamic system, as the drag force is also what provides uplift (via angle of attack).

Except if all the drag is applied to the nose cones then you end up with the majority of drag in front of the CoM, which results in the rocket becoming unstable.

In a lot of ways, this is actually less accurate than the current messed up drag model, since it'll be almost impossible to build something stable.

TL;DR: This system has very nasty unintended consequences that will make airplane and rocket design much more difficult, more unrealistic, and will be more expensive to run. This is the aerodynamic equivalent of the "Why don't we simulate Lagrange points using small, low gravity SOIs?" with the same errors: it has no basis in reality and is confusing for players. This is a really bad idea.

[theend3r]

-snip-

Sounds well thought out. Working with drag similary as with shadows is a neat idea.

...Your system will end up with very strange effects...

True if there was only one source of "light". What if each part generated another behind it after occluding itself? That sounds too complicated though.

Edited February 10, 2014 by theend3r

[ferram4]

True if there was only one source of "light". What if each part generated another behind it after occluding itself? That sounds too complicated though.

So basically, handling all of this without any occlusion then? At that point there's no point in doing light at all and it would be faster to just do vector math on the part's orientation.

But I doubt that's what majic79 was talking about since he specifically mentioned occlusion and how that would allow nose cones to positively affect drag. That could only happen (under his system) if parts could occlude each other. So now we're back to strange effects.

[Comrade Jenkens]

ferram: Would you say the method you use in FAR is suited for stock KSP or is it aimed towards more advanced players?

[theend3r]

So basically, handling all of this without any occlusion then? At that point there's no point in doing light at all and it would be faster to just do vector math on the part's orientation.

But I doubt that's what majic79 was talking about since he specifically mentioned occlusion and how that would allow nose cones to positively affect drag. That could only happen (under his system) if parts could occlude each other. So now we're back to strange effects.

No. If there was an empty space behind a part (thus hardly nosecones) there would be an air torrent behind it = resetting the drag for that part. But as I said it doesn't really sound feasible.

[ferram4]

@Comrade Jenkins: FAR would be fine for stock KSP, there are only three main reasons that people have serious issues adjusting to it:

1. People are used to stock aerodynamics, and the changeover causes problems since it requires a different attitude towards piloting. Of course, this isn't difficulty in the model itself, it's just the apparent difficulty due to change.
   
2. Engines are too heavy. This puts the CoM of KSP rockets a lot lower than it should be; I personally would drop the engine masses either to 1/2 or 1/3 of what they are and then increase the dry masses of fuel tanks to compensate. That or increase the dry mass of decouplers or something like that. Either option ends up shifting the CoM further up the rocket, making rockets more stable.
   
3. SAS doesn't play well with lots of control authority; this is currently hidden with the ineffectiveness of the current control surfaces and the small thrust vectoring ranges that most engines have. The solution to this is obviously to re-tune SAS.
   

Only more advanced players will really be able to handle the more interesting aspects of the model (body lift, space plane stuff, building really heavy complicated landers), but I think that the difficulty that most players have with it is simply due to habits and design principles that work for the stock model but then are detrimental with FAR. They forget that they had to fail a lot before they got good at stock KSP, but think that they're masters at the game and are unwilling to recognize that they're back to being newbies again. I suspect that players who just jumped into KSP + FAR without taking any time dealing with stock aero won't have that bad a time once they get past the initial "I have no idea what I'm doing" phase of playing KSP.

No. If there was an empty space behind a part (thus hardly nosecones) there would be an air torrent behind it = resetting the drag for that part. But as I said it doesn't really sound feasible.

So... how do we determine what should count as empty space? This sounds like a really good way to get even worse interactions due to slight errors in the distances between parts. There is a small amount of distance between fuel tanks when they're connected.

And besides that, in real life it would depend on the shape of the object and the Mach number. There might not be any air right behind the part. There might be a lot of turbulent air right behind it. In either case, simply resetting drag is just going to be completely wrong anyway, and it wouldn't make much sense to take all the calculations necessary to figure all that out.

Edited February 10, 2014 by ferram4

[Kasuha]

I believe what OP meant by occlusion was only occlusion by a part directly attached to that face. Not occlusion by some distant part. So if you have a fuel tank, its top generates some drag. But if you slap a nosecone of corresponding diameter on it, the drag of the tank top, as well as drag of the nosecone's bottom would not be applied because they occlude each other.

I'd also add that drag should probably not change with part's weight as it does now, but it might change with angle of attack on each individual part/face.

I have no idea how exactly FAR works and I am not even remotely trying to suggest this would lead to aerodynamics model as good or even better than FAR but it might still be better aerodynamics model than the current stock one.

[theend3r]

Just read your sig, didn't know you tried it already. That's pretty impressive.

[ferram4]

Ah, the old Raycast Drag Experiment? I need to get that up-to-date so it properly works in 0.23. I decided the best way to shoot the idea down was to implement it and let everyone realize how bad it is. Sort of works for rockets that flare at the bottom, completely fails for anything else. And that's with some kludge fixes in there to make it work.

Also, it ate processor power like crazy and that was only calculating for the active vessel.

[majic79]

This is not how aerodynamics works. Your system (since it's treating airflow like light and handling occlusion) will end up with very strange effects that are only ever realistic at Mach numbers well above ~5 (read: Kerbin reentry speeds only), but for anything lower they'll be completely incorrect

Actually, by occlusion, I meant faces in direct contact - occlusion of non-contact faces (shadowing) would only work for speeds exceeding the speed of sound at distances less than the wavelength of the shock wave (a function of the speed of propagation of the shockwave and the speed of the body through the fluid) - so please read the suggestion as for that of faces in direct contact with each other, and not for faces that are only in shadow (for it to work properly at supersonic speeds, then you must take into account distances between faces and then calculate the speed of the shockwave to see if there's an interaction or not)

Perhaps "occlusion" was the wrong word, but the intention was only to omit faces of an object that are in direct contact with another object, not faces that are "shadowed" and the method I propose is not CPU intensive - it's very similar to a common lighting problem (flat shading and gouraud shading were one of the first colouring techniques I learnt in 3D graphics before 3D enabled hardware became common) which is readily handled by OpenGL and could potentially offload the calc to a GPU during physics/aerodynamic areas of the trajectory

-snip-

I realise that this doesn't take into account re-adjustment of airflow as it passes around objects, but it does give a better first order approximation of drag effects and lift, without interfering with the remainder of the simulation

[AngelLestat]

Ferram, I always wanna make you a question.

I guess one of the main problems to have a real aerodynamic system, is the size of kerbin and its gravity.

I believe that the squad desicion to make kerbin and other scales small was a hit. Becouse the game would be irritating if we need to wait 15 or 20 min for each launch, more if we are in the test design phase.

But this has a real big issue. There is a lot of physsics conceptions that looks weird just becouse lack of real values.

Atmosphere is thin, so there is not good way to balance this, if you had a good aerodinamyc shape it will be too easy to cross it, and if you dont it would be really harded or with weird collateral effects.

Orbit speed is really slow, so this also modify all reentry heat problems, engine and rockets would seems to behave contrary to our common sense prediction.

Are these the main problems to adapt a good aerodynamic system in ksp?

PD: Just to be clear, I use your mod ferram anyway, I preffer that to deal with arcade style of motion.

[majic79]

I believe what OP meant by occlusion was only occlusion by a part directly attached to that face. Not occlusion by some distant part. So if you have a fuel tank, its top generates some drag. But if you slap a nosecone of corresponding diameter on it, the drag of the tank top, as well as drag of the nosecone's bottom would not be applied because they occlude each other.

I'd also add that drag should probably not change with part's weight as it does now, but it might change with angle of attack on each individual part/face.

I have no idea how exactly FAR works and I am not even remotely trying to suggest this would lead to aerodynamics model as good or even better than FAR but it might still be better aerodynamics model than the current stock one.

This is pretty much what I'm going for - the normal to the surface and angle in relation to the direction of travel will dictate the amount of drag the face will be subject to (and magnitude of deflection can be determined for the same angle giving a vector thrust reaction to apply to the module - total module deflection is then the sum of all affected faces and node breakdown occurs above a critical force/vector) - for subsonic flight this model should be fairly simplistic and effective - it also doesn't take into account transonic turbulence, so should make things easier (not having to design/counter this effect should make it easier on the player) and doesn't overload the system trying to handle too work out the cross sectional area of the whole, or an appropriate aerodynamic drag factor in relation to the whole, whilst still retaining the ability of the system to simulate aerodynamic reaction, catastrophic failure etc

[majic79]

Well, I'll add I'm still fairly new to Kerbal, but I'm not new to flight sims (or flight for that matter - I have some time logged in a Cessna 152) and I wasn't aware you'd done experiments in drag Ferram - but it's interesting to see, and I can understand why you interpretted "occlusion" in the manner you did (yes, it was the wrong choice of words for me)

I do work in a fluid flow environment so I've some knowledge of the technology (which is a whole lot more complex than my suggestion, but that suggestion is aimed at providing a slightly better model with minimal impact on performance)

Plus keep the discussion going as I'm only trying to get thoughts going and see if there's something to be gained from it

[ferram4]

Actually, by occlusion, I meant faces in direct contact

Then you should have defined what you meant. You spoke about treating things using light and then used occlusion rather than speaking about faces exposed to the airflow; considering that the standard idea people have with respect to this is that "air == light" (why? I don't have any clue, it doesn't make sense), you basically shot your idea in the foot.

occlusion of non-contact faces (shadowing) would only work for speeds exceeding the speed of sound at distances less than the wavelength of the shock wave (a function of the speed of propagation of the shockwave and the speed of the body through the fluid)

Umm... I don't think shocks have a defined wavelength. I'm not actually sure what you're getting at here, since none of my aerodynamics classes (even the ones focused on supersonic flow) ever went into shocks having wavelengths. Shocks are more akin to step functions, not sine waves like traditional sound.

Perhaps "occlusion" was the wrong word, but the intention was only to omit faces of an object that are in direct contact with another object, not faces that are "shadowed" and the method I propose is not CPU intensive - it's very similar to a common lighting problem (flat shading and gouraud shading were one of the first colouring techniques I learnt in 3D graphics before 3D enabled hardware became common) which is readily handled by OpenGL and could potentially offload the calc to a GPU during physics/aerodynamic areas of the trajectory

It's a lot more intensive than it needs to be for what you're getting out of it. You could get the same effect by simply storing a bunch of properties and doing vector math every frame rather than running a lighting type of function on the CPU or trying to send it off to the GPU and waiting on the info getting back from there. I mean, vector math and storing variables what FAR does, and it really doesn't hit performance that much and it's not even completely optimized.

I realise that this doesn't take into account re-adjustment of airflow as it passes around objects, but it does give a better first order approximation of drag effects and lift, without interfering with the remainder of the simulation

What do you mean exactly by "without interfering with the remainder of the simulation?" It would be a pretty poor aerodynamics model if it didn't affect the rest of the simulation, so I have to assume you mean something else by this, since you just said you meant something other than light and occlusion when you were speaking about light and occlusion.

[majic79]

Ferram4 - technically occlusion is correct (see meteorological and dentistry definition) in the context it was intended (ie, Include/exclude - the category for exclusion from the calculation is it's direct contacting faces which can either completely or partially reduce the drag calculation for a face), and while I appreciate that it's similar, it's not the same as shadow (air != light) and I've no intention that this idea should introduce shadow effects of drag (which does occur, due to turbulence and diminished airflow - I know first hand as I get to experience it sailing inland or with terrain features that interfere with wind) and I don't want shadowing of airflow to affect control surfaces due to high angles of attack

Supersonic transition creates a shock, with a corresponding re-merging of the disturbed shock front with the surrounding air, this has a speed and a distance and is therefore a wave (a standing wave in relation to the moving body, a sonic boom to an observer) during the transition from subsonic to supersonic flight, and that distance is the wave length (and causes some quite sever effects in turbulence around the body until it passes a critical mach number) and really is only an interesting point for discussion in the transonic region - but as I'm not interested in simulating aerodynamic effects to this level, it's irrelevant to the discussion.

I think you've misunderstood what I mean by a "light function" - I've never done ray-tracing (it's too slow for me) and simple vector maths IS what I'm proposing

And by interfere, I thought it was implicit that I'm more concerned about impacting on performance - naturally a new drag model will affect the behavior of the simulation

Edited February 11, 2014 by majic79
clarification

[NWM]

Ferram4 -

[*]Engines are too heavy. This puts the CoM of KSP rockets a lot lower than it should be; I personally would drop the engine masses either to 1/2 or 1/3 of what they are and then increase the dry masses of fuel tanks to compensate. That or increase the dry mass of decouplers or something like that. Either option ends up shifting the CoM further up the rocket, making rockets more stable.

I agree most of your opinion, except of this. At first the fuel tanks are also overweighted - but are there any so durable rocket-fuel tank in earth like the kerbal ones? Do not forget it is a game, and it have to be coherent to its world. The terran "realistic" weights makes the travel irrealisticaly easy in the kerbal world! Let be the game be the optimal compostite of realism and fun!

PS: I LOVE your FAR mod!

[Red Iron Crown]

I don't really care for too detailed an aerodynamic model as I don't spaceplane. Atmosphere is just something to be overcome on the way to orbit.

That said, the drag model really needs to at least take frontal area into account though, and treat streamlined vs non-streamlined parts differently. There should be good reasons for using fairings, vertical vs horizontal staging, etc, which the current model doesn't reward.

[ferram4]

Ferram4 - technically occlusion is correct (see meteorological and dentistry definition) in the context it was intended (ie, Include/exclude - the category for exclusion from the calculation is it's direct contacting faces which can either completely or partially reduce the drag calculation for a face)

Okay, yeah that makes sense. Sorry, it's just a bit of a knee-jerk reaction, and I wish there were a better term for it. It reminds me of objects "orbiting" around Lagrange points and the confusion that can stem from that, and then we end up with uninformed people getting misconceptions about what can work and then everything goes to hell.

Supersonic transition creates a shock, with a corresponding re-merging of the disturbed shock front with the surrounding air, this has a speed and a distance and is therefore a wave (a standing wave in relation to the moving body, a sonic boom to an observer) during the transition from subsonic to supersonic flight, and that distance is the wave length (and causes some quite sever effects in turbulence around the body until it passes a critical mach number) and really is only an interesting point for discussion in the transonic region - but as I'm not interested in simulating aerodynamic effects to this level, it's irrelevant to the discussion.

Okay, I think I see what you're talking about here. You're considering the actual thickness of the shock the wavelength; I was working under the assumption of the shock having no thickness. I haven't done work involving shocks with actual thicknesses in awhile.

I think you've misunderstood what I mean by a "light function" - I've never done ray-tracing (it's too slow for me) and simple vector maths IS what I'm proposing

Oh. FAR does what you want then, though it does it on a part-by-part basis and won't even account for a fuel tank being half-buried in the side of a fuselage. I haven't figured out a good way to do that yet and I don't know much about graphical stuff to be honest.

And by interfere, I thought it was implicit that I'm more concerned about impacting on performance - naturally a new drag model will affect the behavior of the simulation

Sorry, I got a little trollish near the end. I should have realized that's what you meant, I was just confused.

I agree most of your opinion, except of this. At first the fuel tanks are also overweighted - but are there any so durable rocket-fuel tank in earth like the kerbal ones? Do not forget it is a game, and it have to be coherent to its world. The terran "realistic" weights makes the travel irrealisticaly easy in the kerbal world! Let be the game be the optimal compostite of realism and fun!

The point isn't to make things easier dV-wise, the point is to make rockets less likely to flip out. Way, way back, FAR actually had the back of rockets produce realistic amounts of drag. Pretty much every rocket you built (unless it had tailfins) needed to be controlled exactly right or it would flip out spontaneously, since the CoM was so low on it. Now, FAR applies 20 times real-life drag to the back of the rocket at Mach 0 and 5 times real-life drag to the back of the rocket at Mach 1 to try and keep the thing more stable. Unfortunately, this also makes planes and landers behave somewhat strangely. The solution then is to reduce the mass of the engines, and then add a corresponding amount of dry mass to fuel tanks to balance out the change.

It's already about making things fun as opposed to realistic; it's just that KSP's current rocket mass distributions actually make a more sophisticated aerodynamics system a non-starter since it's almost impossible to prevent a rocket from flipping out, so things need to change.

[majic79]

Sorry, I got a little trollish near the end. I should have realized that's what you meant, I was just confused.

All is forgiven - you still make a valid contribution and I welcome constructive criticism

With regard to parts embedded within other parts, there is a solution that doesn't tax things too much if you do it on a face by face basis for each part (module) and reduce the surface area of the part by the amount that's embedded in the other part and the model should work for those cases also. I've been thinking about it and most faces are flat (coefficient for that face=1), the only problem parts are curves (nosecones) and you'd have to work out the mathematical function that describes the curve and then work out drag based on that function. Most 3D parts are constructed of polygonal faces (usually triangles to prevent concave side problems) and if the curve is approximated in 3D using polygons, then it becomes a simple solution (but more time intensive, but linear in relation to the number sides, so not a drastic performance impact)

[eggrobin]

Now, FAR applies 20 times real-life drag to the back of the rocket at Mach 0 and 5 times real-life drag to the back of the rocket at Mach 1 to try and keep the thing more stable. Unfortunately, this also makes planes and landers behave somewhat strangely. The solution then is to reduce the mass of the engines, and then add a corresponding amount of dry mass to fuel tanks to balance out the change.

Is this also the case if you run RSS / Realism Overhaul? The mass distribution should be better with these mods.

[ferram4]

@majic79: That should work for pretty much any shape, since all the parts are made up of flat polygons. You could grab it straight from mesh even. The only issue I can see is determining whether any particular face is exposed or not.

@eggrobin: There are values in the config.xml that can be changed to fix that. I believe that the Realism Overhaul pack includes a fixed FAR config to adjust those drag properties.

[DaMichel]

Apparently it is not so hard to find out if a point is within another object

http://objectmix.com/graphics/132802-efficient-calculation-point-inside-outside-mesh-intersectionlocation.html

You just need to cast a ray and count the number of intersecting faces. So for a whole triangle you can for example use several locations on said triangle to obtain an estimate of the fraction of occluded/exposed surface area.

Regarding the actual drag model, what would be wrong with adding extra drag to "free" top/bottom nodes, like FAR does? Furthermore, the mass factor could be simply removed couldn't it? Parts do have a drag coefficient already which must be tuned properly: nosecone -> small number, blunt cylinder -> larger number, very big nosecone -> large number, etc. For this to make sense however the drag value for, say a nose cone should be lower than the additional drag of a free node. Should be doable.