[0.19+] - Ferram's Raycast Drag Experiment v0.1

[ferram4]

While the forums were down, I decided to try implementing an often-suggested but (IMO) foolish drag model; it uses raycasting and some fluid dynamics to attempt to model the effects on the entire vessel in flight. It's decent for rockets, terrible for planes, and maybe better than what's there by default; presenting:

Ferram's Raycast Drag Experiment

A demonstration of the pros and cons of this model, and why it really won't work in KSP

Download:

Get v0.1 from KerbalSpacePort!

Get v0.1 from Mediafire!

Note: this is not intended to be used as a serious, finalized plugin; it is simply a demonstration of the problems inherent in this type of drag modelling.

With respect to the current, stock model, here are the pros and cons of this one:

Pros:

• Drag doesn't vary with mass
  
• Drag and lift vary with orientation
  
• Drag and lift are fairly accurate for very large speeds (V > 1,400 m/s)
  
• Re-entering pods automatically orient themselves properly
  
• Automatically handles payload fairings and cargo bays
  

Cons:

• Drag and lift highly inaccurate at relatively low speeds (V < 500 m/s)
  
• Discrete modeling of incoming air requires large overhead or low raycasting resolution (and this is for only the focused vessel); at low resolutions strange effects may occur while at high resolutions there is a large amount of lag
  
• Cannot account for angular velocity of the vehicle; this results in no aerodynamic damping; all airplanes are unstable as a result
  
• Can cause parts that should be affected by the airflow to be considered blocked, such as a plane's vertical stabilizer when the plane is at a high angle of attack
  

The reason for this plugin's existence is to point out the unrealistic aerodynamic behavior of this model and as a counterpoint to the frequent suggestion that this be used to model aerodynamics in KSP. It is not intended to be a "usable" or "fun" plugin, but a technology demonstrator.

This plugin is not compatible with Ferram Aerospace Research (FAR) any consequences of combining the two are the user's problem.

Edited April 19, 2013 by ferram4

[Panichio]

You did all this to prove some people wrong? Nice.

[ferram4]

It was more "I will now endeavor to prove myself wrong!"

*coding and testing interlude*

Nope, I was right, but here's what I made in the process of trying to prove myself wrong! It is quite fun if you're only playing with rockets, but anything more complicated won't work too well.

[Guest]

It seems like it's still an improvement, if only for rockets and hypersonic flight. A different system would be needed for proper handling of airplanes though.

[CAPFlyer]

Is there any way of having some hybrid solution where you use raycasting for high speed flight and your current FAR system for others?

Here's the problem I've been having - I can't use FAR for the most part because I fly mainly rockets and even when built properly, because of the way KSP handles weight distribution and how FAR handles high speeds and payload fairings, the rockets become unrealistically unstable and require unrealistic fin stabilization that should not be required as the aerodynamics of the vehicle itself are not correct. However, it is essential for me to build a proper flying aircraft. Thus, I either have to have 2 implementations of KSP installed to work both ends of the spectrum, or I just have to resign myself to only fly rockets without FAR installed because I fly rockets much more than spaceplanes or airplanes and thus the advantages of FAR are essentially nil which means I miss out on what could be a very fun part of this program and that's unfortunate.

[Taverius]

Cons:

• Can cause parts that should be affected by the airflow to be considered blocked, such as a plane's vertical stabilizer when the plane is at a high angle of attack
  

That's actually accurate, you know better than me that's the reason double-engine fighter jets have twin stabilizers

P.S. Its also something I wish FAR would do, because I'm a masochist.

[Nuke]

as a proponent of the raycast drag model i must say that im actually rather impressed that you took the time to give it a decent testing run, dispite your previous assumptions that it probibly wouldnt work. you are indeed a true rocket scientist.

i guess this challenges everyone to tweak the code and see if we cant cross off some of them cons. of course im completely lazy and i dont want to have to code another *expletive* drag model.

Edited April 20, 2013 by Nuke

[ferram4]

@Dragon01: Having a different system in place for airplanes would be incredibly wrong; physics shouldn't change based on what category your vehicle is in.

@CAPFlyer: I'll see what I can do; I suspect most of the problems can simply be fixed by giving the FAR code a good once-over to fix everything.

@Taverius: That only happens at very, very high angles of attack and normally isn't a problem. The main reasons why fighters have twin stabilizers nowadays are:

1. The rudder needs to be able to counteract the yaw moment created by having the maximum amount of unequal thrust between the engines, that is, one engine at maximum takeoff thrust while the other is shutdown. Often weight savings can come from using two smaller rudders for the job.

2. Angling the stabilizers outwards (as it is on almost all modern fighters, see F-18, F-22, F-35) can reduce the radar cross-section of the plane.

The main problem is that this model is fundamentally inaccurate for anything other than approximating the case of Mach number and velocity going to infinity.

[ferram4]

I would like you to consider a few things.

First, look at this video: http://www.youtube.com/watch?v=XfK8NrM2nF4&feature=youtu.be&t=46m26s

This clip (though the terminology could be better) demonstrates a real life example of what may be considered an unrealistic consequence of raycast drag.

I'm already aware of that type of situation, where raycast drag can model the effect of separated, recirculating air diminishing the aerodynamic effectiveness of lifting surfaces. And yes, it is nice to have that effect, to be able to model deep stall, etc. One of the few good things about this aerodynamic model.

Second. How much impact would there be if instead of using classical raycasting you used “conic castingâ€Â, where you projected a cone forward whose shape and length was a function of air pressure and velocity?

I really don't think that would work. Not only would this method probably suck on a lot of resources, it doesn't really have any solid basis in aerodynamic theory. Yes, there is the Mach cone in supersonic flow, but that just tells you the region of flow affected by a disturbance in that flow; the only way to use that would be to continue with the current method and then at every impact run another series of raycasts within that cone to see how the effect continues.

I'll be honest and say that I'm not exactly certain what you're thinking with this, would you mind elaborating on this idea and citing the aerodynamic theories you're basing it off of?

Third. Would it be possible to calculate the aerodynamic properties of each craft once for all possible configurations and roll/pitch/yaw states using “conic castingâ€Â, then apply the resulting mathematical models to the craft in a more traditional manner as to avoid the previously stated performance issues? I would gladly wait 2-4 minutes per new craft so that a more realistic aerodynamic model can be applied lag free during my flight.

Nope. Think about it: losing any individual part changes the configuration. That means that the number of configurations is huge, being dependent on the number of parts and the vessel hierarchy. It would take a huge amount of time to try and calculate all those effects and then storing them in memory would be a pain; sure, you could drop the data into an external text file to try and save memory but then you'll have a bunch of huge text files to go with each vessel. Oh, and this has been assuming that the vehicle is rigid; once you start accounting for flexing under loading things get worse.

Also, waiting 2-4 minutes for each craft might seem like a short time, but how many planes have you built where you needed to make incremental tweaks? Waiting that long to calculate the effect of moving the wings forward a meter will annoy a lot of people, myself included.

Fourth. If I understand your description correctly what you are doing is not raycasting (drawing a line from source to part and determining occlusion), it is particle tracking (following a particle’s path past the craft and determining its physical interactions).

Nope, I'm drawing a line from a source point in front of the vessel to a point behind it, moving in the opposite direction of its velocity. If I were doing particle tracking it would be a lot worse performance-wise. Also, considering the function I'm using is called Physics.Raycast I think it's raycasting.

Fifth. “Cannot account for angular velocity of the vehicle; this results in no aerodynamic damping; all airplanes are unstable as a result.†If each part had a ray cast parallel to the surface velocity vector, this would not be true. Example: vertical stab. yaw would cause ray to be cast at an angle to the part’s surface/plane, allowing lateral force to be calculated and applied in the same way as any other surface in this model.

How do I determine before hand which ray will hit which part of the vehicle? The raycasting is done per vessel, not per part. This is to try and keep things simpler.

Sixth. “and this is for only the focused vesselâ€Â. As it stands, drag is only applied to the active craft anyway (or craft within “off rails†limit at most). If this would not downgrade the current model, I feel this should not be considered a major drawback.

It does not function on loaded, but not active, vessels. When you launch a rocket and detach those SRBs you slapped on the side this model doesn't apply drag to that debris. Why? It would require even more raycasting with multiple raycast systems being active at once, one for each loaded vessel. That would require either more lag or a reduction in the raycasting resolution.

Seventh. “…such as a plane’s vertical stabilizer when the plane is at a high angle of attack†This happens in real aerodynamics as well. I agree that pure raycast would be rather inflexible in this situation, that’s why I suggested the “conic cast†technique.

While it is true that that happens in real life at say, an angle of attack of 20 degrees, it doesn't happen at an angle of attack of 2 degrees; that happens with this model if your plane's fuselage is too long. A vertical stabilizer can still be useful at an angle of attack of 10 degrees in real life while with this model in-game the plane will sideslip like crazy.

[adammada]

It would take a huge amount of time to try and calculate all those effects and then storing them in memory would be a pain; sure, you could drop the data into an external text file to try and save memory but then you'll have a bunch of huge text files to go with each vessel. Oh, and this has been assuming that the vehicle is rigid; once you start accounting for flexing under loading things get worse.

When i was thinking about using such model (way before KSP was developed) I always wanted to check how many angles should be calculated, because rest can be interpolated.

So we have vessel. Theoretically we should count Cx from every direction ( 360 degress * 180 degrees ) but should step be like 0.1 or 10 or 30 ?

Then we need to store it and be ready to interpolate. Best way to store AND interpolate would be to use:

Discrete cosine transform

So there should be experiment:

- lets calculate Cx with 0.1 step

- lets calculate DCT function using using 0.1 step point

- lets calculate DCT function using using 1 step point

- lets calculate DCT function using using 10 step point

- lets calculate DCT function using using 30 step point

Then lets see what error we get between 0.1 and others. If error is small we can use bigger steps.

About dropping things. In your current demo you count that in realtime, yes? So maybe model could use some lazy-count system. Its not like you need to count Cx from behind anytime soon. So you just count Cx once from current fly direction and fast count some more points, to do roughly interpolation. And then count rest points "in background".

[cfds]

Sorry to drag this Thread up form the grave, but I have some questions:

Why is "Drag and lift highly inaccurate at relatively low speeds (V < 500 m/s)"? Is this a problem of the raycasting algorithm? I don't see how the exposed area of a rocket should vary with the speed.

I also don't get the problem with the lag. Essentially, you are taking a picture of the craft from the direction in which it is traveling. This should by in no way take longer than the actual drawing of the vessel (unless it is a problem with unity) on the screen and you probably don't have to recalculate the exposed area 25 times a second. What is the problem here?

[softweir]

The exposed area of a vehicle doesn't vary with speed, but the way air flows over a vehicle DOES vary - enormously - and it is the shape of that flow which governs lift and drag. At low speeds, small changes of shape (such as the curve of a aerofoil) have massive effects on turbulence, the laminarity of airflow and hence the amount of drag and lift a wing produces. It is only towards the hypersonic range that shape becomes less significant than cross-section and a simple raycasting approach becomes realistic.

I am guessing that the lag is because the CPU is doing the work, and at the same time the code is forced to use inefficient calls to determine shape. If you could use the GPU then that would be faster.

[cfds]

Ok, so the reasons why it will not work are bsically the folowing:

- It doesn't work for wings, canards and the like

- It would be better than the stock implementation for basic rockets and generally non-wing parts but causes too much work for the CPU

[Galane]

https://en.wikipedia.org/wiki/OpenCL

OpenCL, cross platform, works with nVidia and ATi/AMD GPUs that are new enough. The problem there is the earlier GPUs capable of running OpenCL code are not so speedy at it. For example, a GeForce 9800GT can barely squeeze out 22 khash/second with an OpenCL cryptocoin miner program. (It doesn't fare any better with a miner written for CUDA, nVidia's hardware native GPU program environment.)

Go a few generations farther, (and change to AMD) and a Radeon HD 6870 will grind out over 300 khash/second. That's 300,000 256 bit encryption keys per second, and compared to the latest GPUs is considered very slow. There have been special systems built with multiple video cards, capable of trying over a trillion passwords a second. One could crack any 12 character password in five minutes or less. Hollywood password cracking is now real, and with the latest GPUs would be even faster.

A super accurate drag model could be done, but not many are going to want to buy a $500+ videocard to use it.

Sabre Dance at only 2 degree angle of attack? Ouch.

[ferram4]

Oh, I'm sure if everything could be pushed to the GPU things could go quite well. (Wow this topic is old; I need to get this old thing back to functioning.) The problem is that as for me, I'm actually GPU limited in KSP more than CPU limited (mobile GPUs are the best!), so I have very little incentive to actually try to make it work on that. Also, given how much CPU power doesn't get used in KSP, it makes more logical sense to work towards CPU-based multithreading than trying to rope the GPU into things (at least from my perspective).

But there's still the problem that no matter how much power you throw at it, this particular drag model is highly flawed in that it treats air as a stream of particles that don't interact with each other until the hit and then slide along the vehicle, rather than as air. If a better aerodynamic model were set up using a more-advanced-than-FAR model the problem would inevitably devolve into trying to make the simulation robust and not want to explode in the face of whatever crazy thing a particular player comes up with. And at that point, the calculations you're doing to prevent that will end up slowing things down no matter how good the GPU ends up being.

[futrtrubl]

What if you were to run both the raycast and the standard (or FAR) models simultaneously but output an average of the 2 models weighted based on speed and pressure?

[Camacha]

What if you were to run both the raycast and the standard (or FAR) models simultaneously but output an average of the 2 models weighted based on speed and pressure?

I think that would result in the worst of both, with a double performance penalty added on top

[Surefoot]

Flawed raycast model aside, i would like to have the option of using the GPU to get the benefit of a more advanced aerodynamic model (maybe more calculations, more simulated shapes, smaller time interval ?) - having a SLI of GTX Titan's my GPU are pretty much sleeping the whole time and the CPU is the actual bottleneck in this game, at least for me. Should be an option though, i too have a laptop when i am travelling

[Azimech]

I think that would result in the worst of both, with a double performance penalty added on top

Who knows? I think it's a very intelligent idea.

[Camacha]

Who knows? I think it's a very intelligent idea.

Most of what is needed to test it is available

[ferram4]

FAR already does most of what this particular model does at very high speeds, but at a much lower cost to performance. Further, the raycast model would still drop completely bogus values for wings into the physics due to the way that it functions with colliders; wings won't be modeled as very thin flat plates like they should, they'll be modeled as barn doors due to the fact that any raycast that hits the edge of the wing will add a lot more drag to the wing than it should actually get.

This model is a lot more flawed than people want to accept; it will never function as a proper aerodynamic model due to its drawbacks. If you try to merge it with another aerodynamic model the raycast model will simply make the combined model less accurate and more expensive to run.