Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Air Resistance Modelling

  1. Feb 2, 2007 #1

    I'm trying to model air resistance to try and predict where destroyer gun shells will land on an online computer game. I've tried quite a few things which have met with some success but are not accurate enough. I think however this time I might have found a better solution in the form of the equation below.

    I've taken air resistance to equal 'x' and horizontal speed to equal 'u' and have taken a constant 'k' which represents the constant factors of the shell's area and air density.

    I've drawn what I think will be the behaviour of the shell's speed in flight plotted against time. Given that the area of a speed/time graph is always equal to distance travelled, and also that the integral of graph's line equation produces the graph's area, then I think I've come up with a valid equation but I'm not sure.

    http://img489.imageshack.us/img489/7430/pic1001vs2.jpg" [Broken]

    I could do with someone to have a look at this as it's been a long time since I did anything of this nature.

    Please I must request that you don't blind me with science as obviously it's a computer game not reality so the modelling to reality used by the game's engine won't be particularly realistic and also I'm not experienced enough to understand a really complex reply.

    I just need one of your guys to have a look at let me know if the equation at the end is valid and if there are any mathematical errors in my methods or any fundamental physical flaws in what I've done.

    Thanks in advance for the help :smile:
    Last edited by a moderator: May 2, 2017
  2. jcsd
  3. Feb 2, 2007 #2
    I've run the figures through against measured and recorded values taken from the game. These values are for the quoted range on the gun sight. We all know in the game that they can achieve greater distances but they're not specified. That's obviously what I'm trying to achieve. To be able to adjust the scope to accurately hit these distances. Not sure if made that clear earlier. It's a bit irrelevant anyway.


    The value of k changes for each measured flight and distance. I'm a bit disappointed by this to be honest. I was hoping to find a constant they might have used for all pitch angles of the gun and therefore all horizontal velocities. A plot of the value of k using the above formula against distances of 1600m to 4200m is shown below:

    http://img63.imageshack.us/img63/2424/pic2uq9.jpg" [Broken]

    Would it be safe to assume that the graph continues in a straight line downwards the way it does after about 2800m? I assume it's eventually going to converge on something but I think that point may be so far beyond range that it might not be an issue and I can thus assume a straight line after this point.

    Is there anyway I can evaluate how the game evaluates k in my equation for each distance and horizontal speed? Clearly it's not the rigid constant I had hoped it would be throughout :confused:
    Last edited by a moderator: May 2, 2017
  4. Feb 2, 2007 #3


    User Avatar
    Gold Member

    Hi Adder_Noir,

    This is a very interesting question. Please forgive as I just started my differential equations class, but I may have a few suggestions (whether they are good or not, I'm sure someone will correct me).

    If you could model your system with change in velocity over time (acceleration), mayb it would make a difference?
    [tex]\frac{dv}{dt} = ?[/tex]

    Where the question mark is exactly how the object is affected by the gaming environment. For example, in real world, you would calculate the force on the object falling, which would be newtons second law and drag. You should do this for the gaming environment through experimentation and eventually you may get an equation. Once you have written it down, you can begin working out the equation for velocity and eventually position.

    I see that you have:
    [tex]\frac{du}{dx} = \frac{1}{k}[/tex]
    So youre saying that the change in position as its related to air resistance is only inversely related to k? I'm sure other factors will affect this in addition to k.
    btw, youre suppose to integrate both side of the equation:
    [tex]du = \frac{dx}{k}[/tex]
    if you wish to eventually arrive an equation for u.
    The line is converging to the equilibrium position.
  5. Feb 2, 2007 #4
    It's possible that I don't quite your derivation: it seems to me that you are integrating velocity with respect to velocity, or sth.

    What I'd do is the following:

    - assume some starting muzzle velocity and elevation
    - model drag deceleration as constant times velocity squared
    - gotta throw in the gravity acceleration as well
    - write horizontal-vertical dynamic equations of shot motion
    - take small step size, and then update trajectory, one by one: angle, acceleration, velocity, position
    - stop updating when altitude drops below level, and voila, the other position coordinate is your range
    - run for several time steps to achieve needed accuracy, not to drop too much below level

    Might not sound so simple, but it really is. I somehow always wanted to play a bit with this myself, but never got to it; now was as good time as any, so here the C code that does the above: http://caslav.gmxhome.de/misc/range.c

    As an example, I set the muzzle velocity and elevation to 1758m/s and 30deg, according to British WW2 naval 380mm gun (http://en.wikipedia.org/wiki/BL_15_inch_/42_naval_gun) [Broken], and then tweaked the drag constant to reach given ~30,000m range. The page also comments that a coastal battery with the same gun can reach ~40,000m due to higher elevation, which, interestingly, is pretty much what the code above produces once you increase the elevation to ~45deg, not touching the drag constant previously determined.

    Chusslove Illich (Часлав Илић)
    Last edited by a moderator: May 2, 2017
  6. Feb 2, 2007 #5


    User Avatar

    Staff: Mentor

    You guys are using waaaay too much math here. Since this is a computer simulation, you'll want to use a numerical/iterative approach, which is best simulated in Excel before coding it into the game. Here's how it works:

    Start with an angle, a velocity, and a drag coefficient. What you are calling "K" is drag coefficient - you'll need to play with it to find something that makes sense. It will be in terms of acceleration - no need to express drag as a force, since it is proportional to accelration anyway.

    1. Use geometry to find the initial horizontal and vertical components of velocity (Vh and Vv).
    2. Your next vertical speed is Vv-9.8/dt-Vv*K
    3. Your next horizontal speed is Vh-Vh*k
    4. For distance this interval, average the current and previous speed and multiply by dt. Total distance is this distance plus the previous.

    The two distance colums are x and y coordinates of the trajectory.

    This question has come up before and I've played with it - I may whip something up for you over lunch....
    Last edited: Feb 2, 2007
  7. Feb 2, 2007 #6


    User Avatar

    Staff: Mentor

    Alright, here you go (see attached). If this is homework, I will need to hurt you....

    One thing - I didn't average the velocities for each iteration - if the iterations are small enough, it doesn't really matter.

    Attached Files:

  8. Feb 2, 2007 #7
    Some superb replies by everyone thanks a bundle!

    Don't worry Russ no need to send the boys round it really is for a pleasure pursuit. BattleGround Europe in fact to be precise.The potential kills we could be getting and town control using the 400+ large HE rnds off the destroyers is mind boggling. Could swing entire campaigns if nailed down.

    Note by the way I'm not coding anything, I'm trying to deduce what the coders have used to plot shell trajectory.

    That's great work Russ I'll download it now (I've already had a look at it in work) and run it against some measured data from the game. If I can get a constant value of k worked out I'll be delighted :redface:
  9. Feb 2, 2007 #8


    User Avatar
    Science Advisor
    Gold Member

    Drag is directly proportional to velocity only for very viscous systems (actually low Reynolds numbers, but we'll leave it at viscosity), like a marble falling through honey or heavy motor oil. For lightly viscous materials like a fast projectile through air, drag is proportional to speed^2.
  10. Feb 3, 2007 #9
    Added a few touches to the code (attached), so that it will now produce something like:

    Code (Text):

    Drag constant [m^-1]: 2.20e-05
    Muzzle velocity [m s^-1]: 732.0
    Max range delta at target [m]: 10.0
    Solutions per muzzle elevation:
     elevation,      range,      ftime,  impactvel,  impactang,      tstep
         [deg],        [m],        [s],   [m s^-1],      [deg],        [s]
           2.6,       4619,        6.7,        661,       -2.8,    0.01250
           5.6,       9214,       14.0,        598,       -6.4,    0.01250
           9.3,      14010,       22.7,        540,      -11.4,    0.01250
          13.8,      18763,       32.8,        492,      -17.9,    0.01250
          19.2,      23175,       44.0,        456,      -26.1,    0.01250
          26.1,      27107,       57.3,        434,      -36.3,    0.02500
          30.5,      28743,       65.1,        430,      -42.4,    0.02500
    (sorry if you don't have a C compiler handy--from the initial post I took it as an implementation problem--but I anyway abhor spreadsheets)

    The input data above is set for the mentioned gun, using more detailed source for comparison-- http://www.navweaps.com/Weapons/WNBR_15-42_mk1.htm , table "...using SC standard charges". The results compare pretty decently to those from the said table.

    However, I find Russ' version curious--it seems to me it shouldn't work well, but using the same example table, it pretty much does :) In velocity update, instead of product between drag deceleration (constant times velocity squared) and time delta, he's using product of constant and velocity. So when I tweek the constant to give said range for one of the elevations (same as I did in my code, only the constant turns out different), I also get good results for other elevations. It only starts undershooting slightly at high elevations (eg. at 30.5 deg).

    By the way, noone to comment on my using (wrongly converted from ft/s) ~Mach 5 muzzle velocity in previous message? Struck me odd last night, when I stopped to think about WW1 vintage gun firing hypersonic projectiles...

    Attached Files:

  11. Feb 3, 2007 #10
    Yeah I guessed they probably wouldn't be able to do that!

    Awesome work and response from everyone. That's really, really helpful.

    I just have one question before I delve back into it again sometime over the next few days. I know I said I'm trying to work this out for use in someone elses game, but I am actually considering writing a game intended for use as a massive online multiplayer game myself after having seen how successful this one is remembering that the graphics are way outdated and the team behind it is small.

    So my question is:

    Although I've used an inappropriate equation for the medium's (air) viscosity, are the mathematical principles behind what I did correct or are there any glaring fundamental mathematical concept errors?

    Thanks again to everyone :cool:
  12. Feb 4, 2007 #11
    I definitely have a hammered-in view of the solution, so I might not realise if it indeed is possible to go the way you started. But I'll point few problems that I see there.

    Let's assume that you do indeed have a graph of horizontal velocity vs. time [tex](t, u)[/tex] as drawn, including knowledge of [tex](t_0 = 0, u_0)[/tex] and [tex](t_1, u_1)[/tex] (I invert your 0 and 1 for [tex]u[/tex], so to have index 0 indicate shot start, and 1 impact). In that case, you could compute the range [tex]s[/tex], as:
    [tex]s = \int_{t_0}^{t_1} u \mathrm{d}t[/tex]
    or if you want to integrate over velocity, after partial integration:
    [tex]s = \left. ut \right|_{0}^{1} - \int_{u_0}^{u_1} t \mathrm{d}u[/tex]

    But there it stops. First, where do you get the graph (functional dependence of time and horizontal velocity) from? If you say that [tex]u = x / k[/tex], where [tex]x[/tex] is your drag, then you either must know function of drag vs. time, which you don't, or assume drag is constant, which is gross simplification (and then you don't need [tex]k[/tex] anyway). Second, while [tex]u_0[/tex] is your known starting velocity at [tex]t_0 = 0[/tex], you wouldn't have the values [tex](t_1, u_1)[/tex] at impact, so you wouldn't know integration limits (you only know the altitude at impact, zero).

    And then again, after writing [tex]u = x / k[/tex], you make the integral:
    [tex]\int_{u_0}^{u_1} \frac{x}{k} \mathrm{d}u = \int_{u_0}^{u_1} u \mathrm{d}u[/tex]
    which, well, isn't the range (if you compare to integration over velocity given above).

    Mathematically speeking, what you have here in our little gunnery practice, is an ordinary differential equation boundary value problem (BVP-ODE), which the code I gave solves by explict Euler time integration with linear shooting. Which is just a lot of dry phrases for the step-by-step list in my first post :)

    Chusslove Illich (Часлав Илић)
    Last edited: Feb 4, 2007
  13. Feb 4, 2007 #12
    I've wondered a bit why does my code, when drag constant is calibrated at one elevation from given historical data, tend to overshoot a bit for lower elevations, and undershoot for higher. I realized that shells may be reaching quite an altitude at highest trajectory point, where air density is noticeably less.

    So I split the air density out of the constant, such that it too multiplies the drag, and computed it in each step by simple parabolic fit of standard atmosphere data. Just for the comparison, I took the shell mass out as well, but it is a given constant. The results are now very good indeed, with less than 1% difference in range to historical data at all elevations. The code is attached.

    Code (Text):

    Shell eq. drag area [m^2]: 0.0379
    Shell mass [kg]: 879.0
    Muzzle velocity [m s^-1]: 732.0
    Max. range delta at target [m]: 10.0
    Solutions per muzzle elevation:
     elevation,      range,      ftime,  impactvel,  impactang,      tstep,     maxalt
         [deg],        [m],        [s],   [m s^-1],      [deg],        [s],        [m]
           2.6,       4562,        6.6,        650,       -2.8,    0.01250,         54
           5.6,       9016,       13.9,        581,       -6.5,    0.01250,        239
           9.3,      13629,       22.5,        522,      -11.6,    0.01250,        625
          13.8,      18281,       32.4,        478,      -18.2,    0.01250,       1297
          19.2,      22863,       43.7,        451,      -26.0,    0.01250,       2355
          26.1,      27522,       57.2,        443,      -35.1,    0.02500,       4036
          30.5,      29905,       65.3,        447,      -40.3,    0.02500,       5271
    With air density and shell mass out, the nameless drag constant becomes one with known name in the field, "equivalent drag area" or something like that.

    Chusslove Illich (Часлав Илић)

    Attached Files:

  14. Feb 4, 2007 #13
    Awesome reply caslav. That's what I really needed. Someone to point out where my mathematical mis-conceptions were.

    I'm printing off this thread so I can pen & paper work through your solution. it looks very elegant indeed and I'd like to get to know it a bit better!

    Thanks again for the help.
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook