Realistic artillery

[Cephalid 0]

Artillery script, based on real artillery

I have been working on a artillery script, to simulate real artillery. The purpose was, that a shell generated at the locality of the artillery can hit a target over a range from about 500 meter up several kilometers with high accuracy. The fire range achieved is 9000 meters with a shell120.

I implemented also some function to correct the fire and the possibility to change between two fire modes. The script also includes a function to scatter the artillery fire over a predefined area at random. You can download a demo mission whit this artillery script here. In this mission you have to get the coordinates of the target with a laser pointer. I have not implemented the possibility given by the function mapsingleclick.

If you are looking for a working artillery addon, look at The Chain of Command.

To calculate the angle of fire, I used three differential equations.

1. Vertical flight from the ground with a defined start speed until stand still.

-a * m = Fg + Fl = g * m  + c * v0^2

t1 = sqrt[1/(g*k)] atan[sqrt(k/g)*v0]

s = -1/k * ln{cos[sqrt(g*k)*t1]} s = way until standstill

2. Vertical flight from a predefined height and zero speed until impact on the ground.

a * m = Fg - Fl = g * m - c * v0^2

t2 = sqrt[1/(k*g)]*acosh[e^(s*k)]   s = way to ground = height

3. Horizontal flight for a given period of time and a given start speed.

-m * a = Fl = c * v0^2

s = 1/k * ln[(t1+t2)*k*v0+1]

In the script artairres.sqs you find a numerical determination of the shooting angle "alpha" in function of v0 and the distance to the target. For more details read the readme attached in the zip file.

The projectile I used is a HEAT shell used by a M1 Abrams and T80 tanks (shell120). Its mass is to low and or its air resistance two high too be fired over larger distance with a realistic muzzle velocity. To fire up to a distance of 9'000 meters, I had to use a muzzle velocity of 10'000m/s. For shorter distances, in my opinion, the muzzle velocity is realistic.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">A cutaway of artairres.sqs used to determine alpha in funciton of v0 and distance

_alpha = 0.1

_dalpha = 10

_s = 0

_hmax = 0

#loop1

_alphac = false

#loop2

_alpha = _alpha + _dalpha

_kv = 0.033/_alpha

_kh = _khc+(_khm*_alpha^_khe)

_vz0 = (sin(_alpha)) * _v0

_vh0 = (cos(_alpha)) * _v0

_t1 = (sqrt(1/(_g*_kv)))*(atan((sqrt(_kv/_g))*_vz0)*_convert)

_hmax = (-(1/_kv) * ln(cos(sqrt(_g*_kv)*_t1/_convert)))

_hmax2 = _hmax + _dh

?(_hmax2 < 0):goto "loop1"

_esk = exp(_hmax2*_kv)

_t2 = sqrt(1/(_kv*_g))*ln(_esk+sqrt((_esk^2)-1))

_s = (1/_kh) * ln(((_t1+_t2)*_kh*_vh0)+1)

_dev = _dd - _s

~0.01

?(_alpha > 35):goto "plus"

?((_dev < 1) && (_dev > -1)):goto "finish"

?(_dev > 0):goto "loop1"

?((_dev < 0) && _alphac):goto "subalpha"

_alpha = _alpha - _dalpha

_dalpha = _dalpha/2

_alphac = true

goto "loop2"

#subalpha

_alpha = _alpha - (2*_dalpha)

goto "loop2"

;Some explanations of variables which may not clear.

;_dd = horizontal distance between artillery and target

;_dh = height difference between artillery and target

;_alpha = angle of fire, start with 0.1 to avoid zero division in case angle of fire is between

;0 and 10 degrees

;_vz0 = vertical velocity

;_vh0 = horizontal velocity

;_dalpha = starting offset of the angle alpha to increase alpha if the calculated distance has been to short

;_convert = 2*pi/360

The posted mission is quiet simple. It is for people interested in this kind of scripts and want to know how "real artillery" can be scripted.

I will post a more realistic mission with artillery support later.

[Doolittle 0]

Does this take into account air resistance?

What is the gravity constant you are using?  Is this _g?  I didn't see it assigned.

Doolittle

[Cephalid 0]

Yes, it takes air resistance in account that was the whole Idee of this script.

For _g I use 9.79.

If you download the sample mission and open "artairres.sqs" you will see all constants. I also use different muzzle velocity's, depending on the distance. The whole script is quiet long and includes a function to scatter the artillery fire. That's why I just published the part of it, where the angle of fire is calculated. The script "artairres.sqs" itself is started by another script called "laser.sqs". This script gives the coordinates of the artillery, target and a reverence point on sea level to the artillery script. Sea level is needed to calculate the height above sea level of artillery and target. It would also be possible to do it without this reference point.

Cephalid

[Ex-RoNiN 0]

Yes, it takes air resistance in account that was the whole Idee of this script.

For _g I use 9.79.

If you download the sample mission and open "artairres.sqs" you will see all constants. I also use different muzzle velocity's, depending on the distance. The whole script is quiet long and includes a function to scatter the artillery fire. That's why I just published the part of it, where the angle of fire is calculated. The script "artairres.sqs" itself is started by another script called "laser.sqs". This script gives the coordinates of the artillery, target and a reverence point on sea level to the artillery script. Sea level is needed to calculate the height above sea level of artillery and target. It would also be possible to do it without this reference point.

Cephalid

The scientifically agreed upon value for 3 significant digits for g is 9.81 ms^-2.

[Raw 0]

Quote[/b] ]The scientifically agreed upon value for 3 significant digits for g is 9.81 ms^-2.

It depends on where you are. Here (in central Sweden) it is 9.82 and increases as you get further from the equator (as the earth is slightly flattened at the poles).

I guess Cephalid just lives closer to the equator (or tweaked it until he got the accuracy he wanted).

The interresting question is what's used in the game, since this will determine the "real" value.

[Ex-RoNiN 0]

Quote[/b] ]The scientifically agreed upon value for 3 significant digits for g is 9.81 ms^-2.

It depends on where you are. Here (in central Sweden) it is 9.82 and increases as you get further from the equator (as the earth is slightly flattened at the poles).

I guess Cephalid just lives closer to the equator (or tweaked it until he got the accuracy he wanted).

The interresting question is what's used in the game, since this will determine the "real" value.

This is how you calculate g:

http://www.leydenscience.org/physics/gravitation/satgrav.htm

The thing is, in models it is almost always assumed that Earth is a perfect sphere (hence r being constant), rather than being deformed. Besides, the deformations aren't much larger than +/- 10km, and I don't think it makes much difference when you consider the other factors as well (mass, G).

[bn880 5]

The only problem is acceleration due to gravity in OFP is not exactly what it is on earth. I don't believe it is even 9.79. Anyway... that is not an issue as anyone can change a constant if they wish.

[Cephalid 0]

Quote[/b] ]The scientifically agreed upon value for 3 significant digits for g is 9.81 ms^-2.

It depends on where you are. Here (in central Sweden) it is 9.82 and increases as you get further from the equator (as the earth is slightly flattened at the poles).

I guess Cephalid just lives closer to the equator (or tweaked it until he got the accuracy he wanted).

The interresting question is what's used in the game, since this will determine the "real" value.

This is how you calculate g:

http://www.leydenscience.org/physics/gravitation/satgrav.htm

The thing is, in models it is almost always assumed that Earth is a perfect sphere (hence r being constant), rather than being deformed. Besides, the deformations aren't much larger than +/- 10km, and I don't think it makes much difference when you consider the other factors as well (mass, G).

Yeap, nice discussion that came up about the value of g used in OFP. I am sure it is not 9.81. I wrote a small program where I let an object fall down to the ground from about 10m. From this height the air resistance doesn't has a significant influence. I measured about 20 times the time until impact. Out of the time and the height I could then calculate g. 9.79 was about the average I got out of this measurements. I also experienced with g later during testing and with 9.79 I still got good results.

But g was definitely not the cracking point.

It was the k value (k=c/m). It took me a while to notice the maximum flight height calculated was never reached during the flight of a grenade. When artillery and target were on the same level, I got good results with a constant value, independent of the distance, but when the target was higher above sea level then the artillery, the grenades where ways to short. So I calculated the horizontal and vertical k values from dates I got from testing, depending on the angle of fire. With this measured points I could build a function which correspond with these points. That was then the breakthrough.

Well I assume there may still some bugs, which I haven't discovered yet. Let me know if you notice something and I will try to fix it.

I have attached a readme file; it has some more comments then in the first post.

[raedor 8]

Quote[/b] ]The scientifically agreed upon value for 3 significant digits for g is 9.81 ms^-2.

It depends on where you are. Here (in central Sweden) it is 9.82 and increases as you get further from the equator (as the earth is slightly flattened at the poles).

I guess Cephalid just lives closer to the equator (or tweaked it until he got the accuracy he wanted).

The interresting question is what's used in the game, since this will determine the "real" value.

it does not only depend on your distance to the equator.

g=G*m*1/r^-2

G = 6.63*10^-11

m = mass of earth in kg

r = radius of earth in m

so if you're livin at the coast, you have an other g as when you live on a mountain.

i'd take 9.80665m*s^-2, that's the international value. or, even better, you take the ofp value...

/edit:

Quote[/b] ]But g was definitely not the cracking point.

oops, sorry.

[Doolittle 0]

It's too bad you have to do this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">?(_dist < 3500):goto "aa"

?(_dist < 4500):goto "ab"

?(_dist < 5000):goto "ac"

?(_dist < 6450):goto "ad"

?(_dist < 7250):goto "ae"

goto "af"

#aa

_v0 = 500

_khc = 0.00052

_khm = 0.00000012

_khe = 2

goto "start"

Does this mean the OFP universe isn't constant?  Fits one equation?  This is almost like what scientists are doing now...trying to find one equation for the whole universe.  Suma could you just...take....two minutes....to post OFP physics stuff??  

Chephalid, I like how you searched for the LaserTarget and how you kept the grenade "live" in the air.

Doolittle

[Cephalid 0]

It's too bad you have to do this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">?(_dist < 3500):goto "aa"

?(_dist < 4500):goto "ab"

?(_dist < 5000):goto "ac"

?(_dist < 6450):goto "ad"

?(_dist < 7250):goto "ae"

goto "af"

#aa

_v0 = 500

_khc = 0.00052

_khm = 0.00000012

_khe = 2

goto "start"

Yep, I know, but there is no other way at the moment. I will try to fix it later. I am busy with working right now, I don't have time at all.

I think the problem is, that the differential equation I used does not take in account that the grenade is rotating around its pitch axis during flight. At least it would make sense. Otherwise I am not hundred percent sure, if a grenade in OFP is turning its nose in flight direction, the direction of the lowest resistance. I did some test, where I let fall a grenade to the ground, but I haven't noticed a rotation around its pitch axis at all. Also it is not possible to give a pitch angle to an object in OFP when you create it. The vertical angle you can adjust with "_grenade setdir _angle".

As I mentioned I will give this a go as soon I am finished with my current work, but this won't be before December.

Quote[/b] ]Chephalid, I like how you searched for the LaserTarget and how you kept the grenade "live" in the air.

Thx Doolittle

Cephalid

[Doolittle 0]

Hmm...I really would not believe they would change the flight path based on the direction the object is facing.  I just remembered PLANES in OFP move best when facing forward...but then again, that's just because all thrust comes out the back.

Don't forget.......in OFP if you run over a tree it doesn't fall away from you, but sometimes towards you.  Hence..this is just a simulation!  Trick the player as much as possible and be as efficient as possible because of limited processing power.

Did anyone consider that maybe moving 1 unit horizontally is the same as moving 1.5 units vertically, or something wierd like that?  I think that is what is going on in OFP space.

Also notice that based on the class of the object, it flies differently.  A barrel has very little air resistance when flying through the air, whereas a tank shell has a lot.  Has it been proven yet that MASS is even calculated in trajectories?  I think it isn't, or it is just based on what class the object is.  For example, if you throw that big carrier ship...it flies well.  It should drop to the ground like a rock but it doesn't.

EDIT: Perhaps there is no mass but air resistance is based on the size of the bounding box of the object.

EDIT: Also, when I first tried to solve this problem, I didn't look for trajectory equations on the net...I looked for GAME physics examples.

Doolittle

[dinger 1]

Well, if you do come up with a single equation that works, let me know.

I simply gave up. So we took a bunch of samples, and taught it to a neural network, and let that deal with it.

One thing that _does_ affect trajectory is the angle of attack of the object. I found this out when building the test data. If you take a round as it flies out of the barrel, and spank it on a certain vector without flattening its AoA, you will get different results than if you zeroed its AoA and then gave it the same vector.

In neither case does the shell rotate in flight.

The AoA effect is not something you'll find in a physics textbook either. For instance, fire a round out to sea from sea level at 75 degrees elevation, and plot its trajectory. You'll see that projectile hits maximum range _before_ impact. In other words, if your initial vector were something like [0, 100, 1000], right before impact, it would look like [0, -20, -1000]

That's why UA zeroes out the AoA of shells out of the tube.

Something similar happens if the shell isn't pointed in the direction of travel. If you createvehicle a shell, it's usually pointed N (unless you change this), and you'll get some skewing along those lines.

dinger

[denoir 0]

I'll re-post an OFP aerodynamics/ballistics study that I did for the CoC Unified Artillery. This is directly just a copy and paste from the chain of command developer forums:

I've had a more or less systematic approach in identifying the necessary variables. I made a set of spherical objects in O2 with different masses and volumes. I also made a number of diffent unit types - all using the spherical objects.

I then proceeded with practical experiments to see what is relevant for the system and what is not. I dropped two different objects in parallel  while measuring time and velocity.

Conclusions that could be drawn:

[*] velocity is independent of mass of object (realistic)

[*] velocity is independent of volume of object (not realistic)

[*] velocity is highly dependent on unit class

Next step was to check the recorded data:

The relation isn't linear since OFP does simulate air friction.

I made a simple polynomial fit to the velocity function and through explicit differentiation I could define the acceleration.

Btw, you can see from the graph that the gravitational acceleration in OFP is 11 m/s^2 as opposed to the real world 9.8 m/s^2

The air friction is even more visible in this example that shows the quotient between the velocities of two objects one dropped with Vz(0) = -100 m/s and the other with Vz(0) = 0.

Through repeated measurements with different velocities the air friction constant can easily be extracted.

There are some bad news though. There seems to exist an unrealistic relationship between air friction in different directions. You get different acceleration along the z-axis if you just drop the object or if you fire it of with a velocity alog the x or y axis. I still have to investigate that. My preliminary model looks like this:

It's possible however that k is cross-correlated and a function of Vx,Vy and Vz or even worse that it is k* s''(f(v^2)) where f could basically be anything and pretty hard to get a direct measurement.  

After concluding that airfriction was indeed modled in a nasty non-linear fashion in OFP, we had basically two options:

1) Numerically solving the diferential equation.

2) Train a neural net.

As a diffeq solver would require long CPU time for each solution a neural net was the prefered the choice.

The next step was to collect data. There are five relevant variables that are relevant:

1) Velocity (muzzle velocity of the shell)

2) Range (2D range between firing point and aim point)

3) Angle (elevation of the barrel)

4) Zdiff (difference in elevation between firing point and aimpoint)

5) Trajectory (Two possibilities: high angle solution and low angle solution).

To get smaller, more accurate neural nets we decided to put velocity as an intrinsic property for each neural net.

Here are some graphs of collected data:

v0 = 600 m/s.  X-axis: angle, Y-axis: range¨

v0 = 300 m/s.  X-axis: angle, Y-axis: zdiff, Z-axis: range

The first graphs shows the data that was given to the neural net to train on. After a lot of work on the sampling routines we managed to get good data for the neural nets. The results were very good. With the neural net targeting system we have a system that hits the spot on any range and zdiff. The highest muzzle velocity we sampled was 800 m/s which gives a maximum range of over 32 km.

This is how for instance the 500 m/s neural net looks like:

For anybody interested here are the scripts we used for collecting data and testing the networks. It also contains all the necessary scripts to train new nets of your own (through CoC ANN pack). In practice we did the training in Matlab because OFP script is slow at raw numerical calculations. But in principle there's no difference. You can do it in OFP and get identical results.

[Doolittle 0]

Yeah baby!  Yeah!!  I love seeing how much time people put into programming.  I really respect that.  Not that my respect for you is important, but as I read that whole post I couldn't help but smile & think "cool beans!"...

Nice work...

EDIT: But what's with the zebras?  Bah!

Doolittle

[bn880 5]

Someone did not try the Unified Artillery

[Cephalid 0]

Someone did not try the Unified Artillery

Maybe I should , but I have no time at the moment.