Page 1 of 3 123 LastLast
Results 1 to 10 of 21

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

  1. #1

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

    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.
    Last edited by ferram4; 19th April 2013 at 00:50.
    Realistic Aerodynamic Models in KSP -- Make your planes fly like planes and your rockets fly like rockets!
    Ferram Aerospace Research -- Neophyte's Elementary Aerodynamics Replacement
    Kerbal Joint Reinforcement -- Kerbal Isp Difficulty Scaler


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

  3. #3
    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.
    Realistic Aerodynamic Models in KSP -- Make your planes fly like planes and your rockets fly like rockets!
    Ferram Aerospace Research -- Neophyte's Elementary Aerodynamics Replacement
    Kerbal Joint Reinforcement -- Kerbal Isp Difficulty Scaler


  4. #4
    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.

  5. #5
    Sr. Spacecraft Engineer
    Join Date
    Sep 2011
    Location
    Dallas, Texas, USA
    Posts
    338
    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.

  6. #6
    Renegade Modder Taverius's Avatar
    Join Date
    Dec 2011
    Location
    Venice, Italy
    Posts
    777
    Quote Originally Posted by ferram4 View Post
    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.

  7. #7
    Mutants Worship Me Nuke's Avatar
    Join Date
    Nov 2011
    Location
    Alaska
    Posts
    1,686
    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.
    Last edited by Nuke; 20th April 2013 at 00:43.
    this space intentionally left blank

  8. #8
    @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.
    Realistic Aerodynamic Models in KSP -- Make your planes fly like planes and your rockets fly like rockets!
    Ferram Aerospace Research -- Neophyte's Elementary Aerodynamics Replacement
    Kerbal Joint Reinforcement -- Kerbal Isp Difficulty Scaler


  9. #9
    Quote Originally Posted by Mateus Malaguti de Souza on KerbalSpacePort
    I would like you to consider a few things.

    First, look at this video: http://www.youtube.com/watch?v=XfK8N...tu.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.
    Realistic Aerodynamic Models in KSP -- Make your planes fly like planes and your rockets fly like rockets!
    Ferram Aerospace Research -- Neophyte's Elementary Aerodynamics Replacement
    Kerbal Joint Reinforcement -- Kerbal Isp Difficulty Scaler


  10. #10
    Spacecraft Engineer
    Join Date
    Jun 2012
    Location
    Poland
    Posts
    213
    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".

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •