More Math Woes

[The_Mark]

Did some sloppy experiments. g seems to be around 11,25 and k about 0,18 for G_40mm_HE shell - though I don't know if the munition type affects the results. I really do hope they don't, for simplicity's sake. Keep in mind, though, that I have no idea of the error margins on these results, they could well be significant. I might do some serious experimenting on these at some point.

If you try it out with these constants, do tell about your results 

Edit: Checking the calculations. Could have some errors here and there.

[The_Mark]

Right. Velocities.

In many respects, yes, but I want to take his concept further by predicting the angle-of-launch before hand, not merely by trial and error repetitive firing.

Even though I have found out how to obtain a z velocity from the z vector...

(gunBarrelZVector * 90) * 12.167 = roundZVelocity

... I still am suffering from a terribly annoying contradiction: in order to determine the angle of launch needed to strike a target from a given distance, I must be able to predict what velocity the round will take when it is fired. That velocity is the average of the xy velocities and the z velocity. As just mentioned, though, to find the z velocity, we must look at the current angle of the barrel. How can we figure out what angle to launch at if the data it depends on is always changing? I'll have to try something else. That likely means a large chart/table of with all the possible angles and their corresponding distances.

-dRb

It's not an average. You can calculate the total speed as v = Sqrt(xy^2 + z^2), but there's a much simpler way - muzzle velocity is a fixed value. Here's an event handler that, when in the init field of a player-controlled MK19 gives the muzzle velocity (which happens to be 240m/s):

Code: [Select]

this addeventhandler ["fired",{ shell=nearestobject [player, "G_40mm_HE"];vel=(speed shell)/3.6; player sidechat format ["%1",vel]}]
From that speed you can easily determine the velocity vector, as weaponDirection returns a unit direction vector - just multiply the muzzle speed component by component:

let dirv=vehicle player weapondirection "MK19";
muzzlevel=240

which results in velocity shell == [(dirv select 0)*muzzlevel,(dirv select 1)*muzzlevel,(dirv select 2)*muzzlevel].

BTW, the mass of the projectiles do affect their trajectories (but object shape or orientation doesn't seem to matter, which means that the problem is at least solvable).

[drbobcat]

Here is some more information that I have gathered throughout my tests...

When fired at a 45 degree, the default ArmA shell exits the barrel at roughly 3960 km/h (1100 m/s) and reaches a maximum distance of roughly 5800 meters at 0 launch height, 0 impact height. However, I wish for the round to reach a maximum range of 11400 meters (the real max range when using Charge 7). Additionally, I desire the round to completely ignore air friction so that I can easily predict where the round will go before it is fired. I currently have been using these calculations to dictate the velocity of the shell:

Code: [Select]

_wAng = (((_gun weaponDirection "M119") select 0) atan2 ((_gun weaponDirection "M119") select 1));
_wElev = (((_gun weaponDirection "M119") select 2) * 90);

_spd = 475;
_zVel = (_wElev * 12.06);

while {!(isNull _round)} do
{
_round setVelocity [((_spd * (cos (_wElev))) * (sin (_wAng))),((_spd * (cos (_wElev))) * (cos (_wAng))), _zVel];
_rPos = getPos _round;
_zVel = _zVel - 0.392;
sleep 0.01;
};
This causes the round to descend at an arbitrary rate of 39.2 m/s (four times gravity, or 9.8 m/s to the best of my knowledge) and travel along a realistic looking trajectory. Because I have altered "gravity" in this case, I know my formulae will have to be changed as well, likely substituting all 9.8s with 39.2s. Please correct me if I am wrong here!

Regarding muzzle velocity, The_Mark, is that the same velocity I need to apply to the angle and distance formulas mentioned on the wikipedia article regarding trajectories (IE th = ((asin ((g * d) / v^2)) * 0.5)? I knew that it had to be a constant value, but was completely unsure as to what it was. I tried the magnitude of both the xy and z velocities, as well as the average. Of course, those were not correct as those always change depending on where the gun barrel is aiming. I will definitely have to try out your formula! If that does turn out to be the number I am looking for, all the equations I have been using thus far should begin to function correctly given that air friction has ultimately been eliminated!

I believe we are closing in on a conclusion! Thank you!
-dRb

EDIT: After experimenting with the changes The_Mark supplied, I came up with an entirely new set of numbers to work with. If I keep the constant of 39.2 m/s for z-velocity deceleration, I need a "muzzleVelocity" of 640 for the round to land at ~11400 meters when fired at a 45 degree angle. Current angle prediction formula fails to be accurate when the range falls towards one extreme or the other:

Code: [Select]

((asin ((39.2 * _dist) / (640 ^ 2))) * 0.5)
And the new setVelocity code:

Code: [Select]

_wVec = _gun weaponDirection "M119";
_spd = 640;

_xVel = (_spd * (_wVec select 0));
_yVel = (_spd * (_wVec select 1));
_zVel = (_spd * (_wVec select 2));

_round setVelocity [_xVel,_yVel, _zVel];

while {!(isNull _round)} do
{
_round setVelocity [_xVel,_yVel, _zVel];
_zVel = _zVel - 0.392;
sleep 0.01;
};

What is it that I am doing wrong? While I realize I could just fire 85 different rounds, gather the data, and put it all into a table for the player to use, I'd much rather get this formula working correctly. *grumble*

EDIT 2: I have noticed that gravity has always been listed as 9.8 m/s² not just 9.8 m/s. How does that translate into an algorithm for constant vertical deceleration? Specifically, how would that change if I were to intensify the effects of gravity (see the 39.2 previously mentioned)? Also, I still have yet to correctly determine the muzzle velocity I need to plug in to the calculations in order to derive an accurate angle of launch... Anyone have any thoughts?

[The_Mark]

Acceleration (and deceleration, which is just acceleration with a minus in front of it) is defined as the change of speed with regards to time, ie. mps/s; a constant acceleration of +9.8m/s^2 means that an object's speed grows 9.8m/s in one second. 2s*9.8m/s^2=19.6m/s after two seconds, etc. Generally, for a constant acceleration a you can calculate an object's speed at time t, with the initial velocity v0 with the function:

Code: [Select]

v(t) = a*t + v[sub]0[/sub]
This means that your algorithm for constant vertical deceleration (the new setVelocity code) is valid. It should produce perfect parabolic trajectories, but you have to remember that you can't disable the physics engine in its entirety, and it could create anomalies at range limits - it has a .01 sec window in which to screw things up by accounting for air drag and slowing the shell minutely. Though, this is just a guess; I don't have that deep knowledge of the inner workings of the game. You could, though, use setpos to guide the shell precisely through the trajectory.

Extremely short-range shots will not obey the range equation, by the way - you have a rotating and tilting barrel, the muzzle of which defines the starting point of the trajectory. The starting height will vary according to the angle at which the gun is tilted. Still, that's not a major concern, as you can just aim through the sights in that case

As for the launch angle, you can derive it from the Pythagorean theorem and basic trigonometry, provided you have the initial velocity vector. You have to consider that you have the vertical component of velocity, z, and the horizontal components x and y. First, you need the total horizontal component xy = Sqrt (x^2 + y^2) as per Pythagoras, and then you can consider this probably poorly done ASCII drawing of a vector triangle:

Code: [Select]

         xyz
             /| z
           /  |
         /    |
       /      |
     /        |
   /          |
 /  a         |
------------->
              xy
Here you have the horizontal component xy, the vertical component z and the total muzzle velocity xyz (whose magnitude is given by Pythagoras: xyz = Sqrt(x^2 + y^2 + z^2), or from the muzzle velocity recording event handler I presented before) and the angle a, which is the launch angle. Then, from trigonometry you can see that tan a = z/xy, or as well, sin a = z/xyz or cos a = xy/xyz, so you get a = atan z/xy = asin z/xyz = acos xy/xyz.


Then, to show off advanced mathematics my progress at examining ballistics in ArmA: The realistic drag equation, where F~v^2 produces a frickin' complex solution, with an awfully awkward singularity at the limit approaching maximum range and _several_ beyond it. More of that later, first something about the relation F~v. It's solvable, quite easily. It can be tuned to give quite accurate velocity predictions, at least on MK19 at some angles, though dunno about the range, as I have kept at predicting velocities with somewhat simpler equations (yes, I'm lazy). However, my gut feeling about terminal velocity experiments says that F~v^2 is what we should be looking at, but I still have to confirm this properly.

Well, as for the math for F~v^2... it's still a bit beyond me. Fortunately, I've got my trusty Mathematica, and here's a screenshot of my current notebook:



Yeah. How you like them apples.

[drbobcat]

Well, it seems that no matter how accurate my calculations are, the shell will never land exactly where I want it to because a 0.01 loop is not fast enough. Therefore, I will instead setpos the round to where it needs to be to land where it should. Completely factoring out air resistance in ArmA is an extremely challenging task, and one that I feel is not worth tackling when alternative methods will render the results I am looking for.

I shall post again when the script has been updated. Thank you.
-dRb

[Mr.Peanut]

This problem is solveable by taking a more simple equation and fitting it given data from the game. You need to gather the data in the flattest possible area. Your artillery and your target area should be all the same altitude. Record the position of the artillery.  If possible orient the artillery at one of the cardinal directions. Fire your artillery at 5 degree increments in the vertical. At each each increment take at least 5 shots. For each shot, record the muzzle velocity, weapon direction, the position at which the shell hits the ground, the ASL pos at which the shell hits the ground and the wind.

Give me that data and I will fit the equation for you. As well as determine the drag coefficents.

[The_Mark]

That's too easy

What we seem to have in ArmA is something where the drag coefficient is a constant for each object (that use ordance-type simulation, at least), regardless of direction - at least that is my hypothesis, yet to be comprehensively tested. Yes, I fail at basic rigor here. Nevermind that, though. Without all the chaotic effects of turbulence, eddies and such we should be able to derive an exact solution for trajectories, even with wind accounted for. Approximations, while being a physicist's tool of choice, get boring after a while.

[Mr.Peanut]

Even with the best equations, in this case you do not know how the engine exactly behaves. Your model will only ever be an approximation of the ArmA engine physics. For each ordnance type you will need to determine the mass and lateral and axial drag coefficents. This is best done by least squares fitting your data to your equations, whatever they may be.

[The_Mark]

We can reasonably assume that the engine bases its ballistics on relatively simple mathematics with as much as possible real physics in it (hence the relation F~v^2 is a more than likely candidate). As for not exactly knowing how the engine exactly behaves, well, that's where physics comes in - trying to figure out how it works, approximately, or, if possible, exactly. With the most preeminent chaotic factor (non-constant drag coefficients) (possibly and likely) eliminated from the engine we do have a chance of finding an exact solution. It's, after all, just a simulation.

As for determining the mass and drag coefficients, they both can be included in a single constant, which I've called k in this thread.

[drbobcat]

*sigh* I guess if all the variables in their entirety were modeled within an algorithm, I could possibly apply ONLY an initial velocity to the round at the beginning of its journey. Letting the game's physics engine take over from there, it would travel the distance it needs to. That does sound terribly complicated, though. You shared with us your understanding of the air drag formula many posts ago, The_Mark, could you again state it but articulate what each variable represents?

I currently am using a method that calculates a distance based on the current launch angle. A position is derived from that distance and the round is setPos-ed overhead, given a sharp negative velocity, and the shell strikes the ground. To make it less of a rifle and more of a howitzer, sway has also been implemented, increasing accordingly with the time the round is "in the air." Lastly, there is also a minimum range to take into consideration, thereby giving the gun pronounced vulnerability.

Code: [Select]

        _spd = 747.3955;

_dist = (((_spd ^ 2) / 49) * (sin (2 * _wElev)));
if (_dist < 2500) then {_dist = 2500};

_time = (((2 * _spd) * (sin _wElev)) / 49);
if (_time < 2) then {_time = 2};

        ...

        _rPos = [((getPos _gun select 0) + (_dist * (sin _wAng)) + ((random (_time * 6)) - (random (_time * 6)))),((getPos _gun select 1) + (_dist * (cos _wAng)) + ((random (_time * 6)) - (random (_time * 6)))),500];

sleep _time;

_round setPos _rPos;
_round setVelocity [0,0,-250];
Suitable for now, but it has one major flaw. It completely bypasses the land between the target and the gun. Not only is this quite unrealistic, it also makes things a little too easy. So, if I -could- somehow interpret ArmA's air friction model, I would again have a more believable trajectory. *ponder*

We'll see,
-dRb

[The_Mark]

Well, from the assumption that the drag force F~v^2 (meaning F behaves like v^2, that is, F = k v^2, where k is some constant), we have the differential equation

Code: [Select]

a = k*v^2 + g
Where a is the objects total acceleration, k the constant of relativity and g the constant gravitational acceleration (around 11.3 as it would seem in ArmA after a quick experiment). k represents here, among other things,  the mass of the object and its drag coefficient - the other factors in it are not important, as they're (probably) constants in ArmA, such as the density of air. k has to be experimentally determined for each projectile (about 0.0006 for G_40mm_HE, needs improvement as well); I haven't got a clue where e.g. the mass of an ArmA object is defined. Next, I'll be determining a more accurate value for k(G_40mm_HE).

The differential equation itself could be easily used to run a quick simulation in a script to determine the impact point from muzzle velocity alone. Running the simulator backwards would be a bit harder, iterating between simulations of shells fired from the gun and ones fired backwards from the impact point. It might converge at the right spot, but not necessarily, I just thought of that. The simulations would require accurate constants, though.

Mind you, if ArmA models any sort of trans- and/or supersonic behaviour, the equations won't work. I doubt that it does.

[Mr.Peanut]

Well,
I plotted du/dt vs u for shots fired straight north, but at a low elevation. u is east-west velocity, wx is east-west wind component.  In ArmA the wind stayed constant for the duration of the shots. The end result is very close to du/dt = -k*u*V, where u is the east-west velocity component, V is the magnitude of the total velocity and k is a constant.

Sh_105_HE M119:
trial     direction     elevation        u0          V0        k(x10^-4)
1          -0.0977     2.26974    -1.6063     1088.37     4.3263
2          -0.0977     2.26978    -1.03005   1079.37      4.3384
3          -0.0977     2.26978    -1.23268   1078.38      4.2707


where u0 is the initial east-west velocity, and V0 is the magnitude of the full initial velocity. (I know I need more than three trials for rigor). I would like to fit the trajectory to the formulae for quadratic drag, but I made the mistake or recording z and not z_asl. BTW I used DSTS to record the trajectory data. Great tool!


The drag coefficient was ~(4.3118 +/- 0.036)*10^-4 for Sh_105_HE. Wind was not included in the calculation because it ruined the data fit.  So it looks like BI handles dispersion by adding noise to the initial velocity (I guess any addon maker could have told us this?) uses quadratic drag with a constant coefficient and ignores wind. I will take a quick look at the north-south component next and see if it is consistent with these findings. It looks like trajectories can be only be calculated using numerical methods. Use a parabola or linear drag to give the initial guess, and then relax the solution. Or gather more statistics, fit to a linear drag and estimate the errors in k.


edit: drag coefficient for north-south and up-down motion are almost the same as that for east-west. I also fitted for g.  ArmA appears to use a value of ~9.7 which is odd. They must have tuned it slightly. So there you go. Now I guess I should also test for some trajectories fired at higher elevations. The winds were also consistently low and constant for this first test.

edit2: tried more cases and the results are consistent. For this second group of tests k = (4.34 +/- 0.02)*10^4. this time the average g was 9.8. Wind seems to have no noticeable effect on trajectory.

So I think we can be conclusive about this for Sh_105_HE. I would imagine all artillery type ordnances have the same drag coefficient. It is possible to estimate the trajectory by integrating forward. The only missing piece of the puzzle is what the artillery muzzle height is as a function of elevation.  You might need  to add a small vertical offset for the artillery. I don't claim it is bug free, but it should give an idea of how you might proceed. Assuming artillery is on a level surface.

Code: [Select]

_gun = _this select 0;
_muzzle = _this select 1;
_muzzleOffset = _this select 2;
_muzzleLength = _this select 3; // Length should be such that (_muzzleOffset + _muzzleLength * sin _elev) gives you muzzle height above the ground
_vm = _this select 4; //magnitude of muzzle velocity
_k = _this select 5; //drag coefficient
_dt = _this select 6; // Your time increment. Should be set as small as possible i.e. 0.01 or smaller
_maxRange = _this select 7; // Maximum range. No idea. Maybe 3000-5000? Is 3-5 km reasonable?
_pos = getPosASL _gun;
_vectorDir = _gun weaponDirection _muzzle;
_elev = 90 - acos ((_vectorDir select 2) / sqrt ((_vectorDir select 0)^2 + (_vectorDir select 1)^2 + (_vectorDir select 2)^2));
_vectorDir = _gun worldToModel _vectorDir; //transform to model coordinates
_x = 0;
_y = 0;
_z = _muzzleOffset + (_pos select 2) + _muzzleLength * sin _elev; // ASL height of muzzle
_u = _vm * ( _vectorDir select 0);
_v = _vm * ( _vectorDir select 1);
_w = _vm * ( _vectorDir select 2);
_gl = "logic" createVehicleLocal [0,0,0];
_zASL_Land = -666;
_posw = [];
_lastPos =[];
while {_z > _zASL_Land or _y < _maxRange} do
{
   _lastPos = _posw;
   _vel = sqrt(_u*_u + _v*_v +_w*_w);
   _u = _u - _k *_u*_vel*_dt;
   _v = _v - _k *_v*_vel*_dt;
   _w = _w - (_k *_w*_vel + 9.8)*_dt;
   _x = _x + _u*_dt;
   _y = _y + _v*_dt;
   _z = _z + _w*_dt;
   _posw = _gun modelToWorld  [_x, _y, _z];
   _posw set [2, 0];
   _gl setPos _posw;
   _posASL = getPosASL _gl;
   _zASL_Land = _posASL select 2;
};
deleteVehicle _gl;
//Now _lastPos holds the shell position just before impact with ground.

[drbobcat]

Commendable work, you two. You both are not only talented practicioners of math, but also quite patient and resourceful. I shall begin experimenting with these equations and such as soon as I can gather up some free time. As a side note, however, I was looking over the Biki entry for CfgAmmo and noticed that there are many settings dictating a round's ballistic characteristics, including air resistance. I was wondering how they could play into your calculations.

http://community.bistudio.com/wiki/CfgAmmo_Config_Reference#sideAirFriction

Source: http://community.bistudio.com/wiki/CfgAmmo_Config_Reference

I shall return in a while and edit this post so that it contains the sideAirFriction values for "SH_105_HE" (M119 round) and "G_40mm_HE" (M203/Mk19 round)

- dRb

[Mr.Peanut]

I can't see how side friction applies because I got the same drag coefficient no matter what side. Maybe this is more applicable guided missiles?  If I get a chance tomorrow, I'll run the same tests on the G40.

What the hell is deflecting ammo?

[drbobcat]

Okay. I came to the same conclusion as you: "sideAirFriction" is applicable only to missiles. As to your question, I believe "deflection" is ArmA's value for the angle a bullet will take when and if it ricochets.

I'll continue to look for some sort of exact value we can give 'K' so your formula will consistently return accurate results regardless of whatever weapon is being fired. Having to test each and every time to find 'K' would be a pain. I do have another question to ask The_Mark, though. If the value of 'a' is the total acceleration of the round with air friction, would that be equal to the muzzle velocity (v) that we plug into our old friend, the algorithm for angle of launch ((asin (gd / v^2)) * 0.5)? That would be excellent if it were. I'd highly prefer allowing ArmA's physics engine to handle the flight of the artillery shell over any other "creative" solution.

Back into the thick of it,
-dRb

EDIT: Woah. Interesting. Here are the "airFriction" values for the two forementioned rounds. That attribute is not listed on the cfgAmmo Biki...

SH_105_HE = -0.00045
G_40mm_HE = -0.0005

The estimated drag coefficient given by Mr.Peanut was ~(4.3118 +/- 0.036)*10^-4 , or ~0.000434. That is extremely close to (4.5 * (10^-4))!