Jump to content
Sign in to follow this  
OmniMax

The physics of ofp

Recommended Posts

Trying to get this to be made a sticky as I continue my physics work in OFP.

This topic has everything to do with the physics of operation flashpoint. It will eventually be used as a little guide for mission makers\etc who are doing things involving physics.

First, a couple rules for replying:

1. Post only about physics (ballistics, aerodynamics, &c)

2. Please do not post questions in this topic. Any questions can be made into seperate threads.

3. Please post your sources for any information you add, if you know where the information is from.

I guess I'll begin...

Share this post


Link to post
Share on other sites

said by Suma and also found in The Mission Editing FAQ:

Quote[/b] ]

bullet time-to-live is 3 seconds.

shell time-to-live is 20 seconds.

Missile time-to-live is 10 seconds.

Free fall bomb (missile with no thrust time) is 120 seconds

flare time-to-live is 17 seconds

smoke shell time-to-live is 60 seconds

satchel time-to-live is infinity

all other ammo types time-to-live is 10 seconds

Bullet names that can be used with the CamCreate command:

Quote[/b] ]

BulletSniperW

BulletSingleW

BulletBurstW

BulletSilencedSingleW

BulletSilencedBurstW

UZI

Bullet7_6W

G36a

Steyr

GlockS

Beretta

RevolverBullet

GrenadeHand

Grenade

MortarShell

AA

CarlGustav

LAW

BulletSingleE

BulletBurstE

BulletFullAutoE

Bullet7_6E

BulletSniperE

Bizon

Tokarev

Skorpion

9K32

AT4

BulletSingleG

BulletBurstG

BulletFullAutoG

KozliceBall

KozliceShell

CZ75

HuntingRifle

Bullet7_6

Heat73

Shell73

AT3

Cannon30AP

Cannon30HE

Bullet12_7

Heat120

Shell120

Cannon25HE

Heat105

Shell105

Bullet4x23

Heat125

Shell125

Bullet4x20

Bullet30W

Maverick

Bullet30A10

LaserGuidedBomb

Bullet30

HellfireApach

Hellfire

Zuni

Rocket57

Bullet30E

AT6

BISBulletCamel

BISGrenadeCamel

CH29T

The default projectile speeds (found by using uiox's bulletcam II mission):

Quote[/b] ]

M16: 900 m\s

AK74\47: 900 m\s

FN-FAL: 900 m\s

Steyr AUG: 900 m\s

G3A3: 900 m\s

G36: 900 m\s

AK47 SU: 900 m\s

M21: 900 m\s

SVD: 900 m\s

MP5: 400 m\s

Uzi: 400 m\s

Glock 17: 380 m\s

Beretta 92FS: 380 m\s

S&W: 380 m\s

Skorpian: rock.gif

M60: 1000 m\s

M2 Browning: 1000 m\s

PKD: rock.gif

Rifle Grenade(Mortar): 70 m\s

M203: 60 m\s

Hand Grenade: *** see below

Carl Gustav:

LAW: ** see below

AT4: ** see below

M1A1 SABOT\HEAT : 1500 m\s

T80 SABOT\HEAT : 1500 m\s

M2A2 Bushmaster: 1000 m\s

All bullet speeds are measured in meters-a-second (m\s)

All measurements which don't specify, have constant speeds.

For all tanks (includes M1A1, T80, T72, T55) all weapons onboard which are called "MGun" has the same bullet velocites as the M2 Browning (1000 m\s)

** Rockets do not have constant speeds. I have yet to calculate starting speeds, rate of acceleration, and end of accerleration, rate of deaccleration (Rockets include TOW, AT4, Carl Gustav, &c)

*** Hand Grenades and weapons on aircraft do not keep constant speeds. On a closer examination, they have a give or take of about 50 m\s projectile speeds based on the angle of the weapon's muzzle. This has only been noted on aircraft's cannons and not missile weapons. Research pending.

Share this post


Link to post
Share on other sites

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:

va1.jpg

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 smile_o.gif

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.

v1v2q.jpg

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:

d2sdt.jpg

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.  rock.gif

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:

data600a.jpg

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

traj1.jpg

mv300.jpg

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:

net500.jpg

After the release of the CoC Unified Artillery, I'll release the basic program used to test the nets as well as the data collection and neural net pack. It can serve as a simple foundation for anybody that wishes to play around with ballistics in OFP. smile_o.gif

Share this post


Link to post
Share on other sites

denior, that rules! And I imagine Dinger worked on that too? That is very impressive guys!

So are you going with an equation in Unified Artillery or are you using tables?

Anyways, just wanted to say I am extremely impressed!

Doolittle

Share this post


Link to post
Share on other sites

Heh Doolittle, I had firing tables in there, then Denoir got interested, and in effect he taught firing tables (or rather the sampled data graphs he's posted) to an adaptive neural network.

With huge firing tables and linear interpolation, I was getting accuracy on the order of 10 meters at 10,000m.  With the neural net, we're seeing accuracy of .1 m or less; in other words, accuracy that's better than the factors we can't control for in UA.

Writing the neural net, and teaching it the sampled data is all denoir (as are those pretty graphs). Getting the sampling routines right was a chore that had us both suffering.

Share this post


Link to post
Share on other sites
And I imagine Dinger worked on that too?

That's an understatement. When I got involved, Dinger already had a very good working system through firing tables. Being a hard-core neural network advocate, I figure that any system can benefit from a neural network or two, and UA was no exception.  wink_o.gif

The first idea was to replace the tables with a neural net that would reduce the size of the data and be faster. We came to the conclusion however that it would be better to collect new data and organize it in a manner suitable for a neural net. Dinger and I developed together the necessary sampling routines.

Quote[/b] ]So are you going with an equation in Unified Artillery or are you using tables?

Shortly after I got involved in the project and after analyzing the data collected from OFP in Matlab, I had hopes that we would be able to describe the system with a simple equation, or at least through a polynomial approximation. However after studying the data I derived the following differential equation that describes the OFP ballistics:

d2sdt.jpg

s is the desired vector function that describes the trajectory. Unfortunately this differential equation does not have an analytical solution and it's fairly tough to solve it numerically. In the end we decided to go with the neural nets after all.

So, to answer your question: neither. We use neural networks that have been trained with data collected from OFP. The system's "knowledge" is stored in a set of weights that define the neural network.

Share this post


Link to post
Share on other sites

Denoir, I just got a good idea.

The explosives effect from objects like satchel charges, rockets, grenade effect objects nearby. Ever try satcheling a jeep with 10 satchels and watch it blast off?

Is there a formula to find the peak burst pressure of the explosives? Maybe by distance? I knew if you had the correct chemical mixture, you could calculate peak bursting strength by gram.

Perhaps I should test via distance?

Oh yes, and this doesn't seem to work with winged vehicles, either, they react differently to velocity changes (1 satchel charge will send a cesna flying very far)

The one thing I love about OFP is that it is almost super realistic. Execpt the damn modeling of aircraft.

Quote[/b] ]

Edit: Experiment 1, Simple distance test

I used a jeep which I named player and a object name "H" which I called find. Inside my mission directory, I had a script called dis.sqs, which calculates the distance between the two objects named 'player' and 'find' and displays the variable in the format of "hints".

In this experiment, I placed 1 demolition charge on the right (east) side of the object name "jeep" and walked off 50 meters and detonated the explosive, repeated this 10 times, and got a mean distance the jeep was launched.

The orginal displacement value between the two objects "player" and "find" respectively was 1.53692 meters due to object's hitboxes being not centered.

the avg. distance the jeep was launched is 130.7578 meters.

the total distance in ten times it was launched is:  1445.9008 meters.

Using dumb logic, in practice, if you used 10 charges, you could send the jeep 1445 meters.

***

end of report

***

p.s: If a moderator won't turn this into a sticky, I'll just make an open source document then. But I haven't asked them to make it a sticky yet, a little busy, would Doolittle or Denoir be kind enough to PM placebo and ask? Thanks.

Share this post


Link to post
Share on other sites
d2sdt.jpg

What are the arrows above the S for?  I haven't seen that symbol used before.

Share this post


Link to post
Share on other sites

It indicates that s is a vector. It's common notation so that you don't confuse it with normal one-dimensional variables. Apart from the arrow, usually a vector is marked with bold text.

For instance, if you check the equation, look at the part that says <span style='font-size:10pt;line-height:100%'>-g*e</span>z. This part defines the acceleration that comes from gravity.

<span style='font-size:10pt;line-height:100%'>e</span>z is a basis vector (lenght 1) in the z direction: <span style='font-size:10pt;line-height:100%'>e</span>z = [0,0,1].

In the same way s(t) = [ s.x(t), s.y(t), s.z(t)].

Share this post


Link to post
Share on other sites

@Denoir:

That's an interesting approach. How did you get the data to matlab (and can you get it back to OFP?) ?

Did you train the ANNs in OPF?

Share this post


Link to post
Share on other sites

Ok, in reverse order:

Quote[/b] ]

Did you train the ANNs in OPF?

Although the training algorithms are implemented for OFP, Matlab was much more convenient to work with and test different architectures. OFP script is not very fast for raw numerical calculations. So all nets were trained in Matlab and the result was imported to OFP.

Quote[/b] ]That's an interesting approach. How did you get the data to matlab (and can you get it back to OFP?) ?

funMatrixToMatlab (part of the CoC Matrix Library) converts a matrix into a matlab compatible string. The string is then extracted from the savegame using a tool (coc internal, not released)

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">comment {

funMatrixToMatlab

PURPOSE: Converts a matrix to a matlab compatible matrix string    

SYNTAX: [myMatrix:matrix]call funMatrixToMatlab

RETURNS: string

EXAMPLE:

       A = [ [1,2], [3,4] ];

      [A] call funMatrixToMatlab

      -> "[[1 2][3 4]]"

     

HISTORY: CoC denoir 17/07/2003

DEPENDENCIES: CoC_LIBMATRIX

};

private ["_matrix","_rows","_cols","_j","_i","_str"];

_matrix = _this select 0;

_rows = count _matrix;

_cols = count (_matrix select 0);

_str = "[ ";

_i = 0;

while "_i < _rows" do

{

_str = _str + "[";

_j = 0;

while "_j<_cols" do

{

_str = _str +  format["%1 ",(_matrix select _i) select _j];

  _j = _j+1;

 };

 _i = _i+1;

 _str = _str + "];";

};

_str = _str + "]";

_str

In the other direction a Matlab->OFP a small matlab script is used:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">function [ string ] = MatlabtoOFP( matrix )

[rows cols] = size(matrix);

string = '[ ';

for i=1:rows

   string = strcat(string, '[ ');

   

   for j=1:cols

       string = strcat(string, num2str(matrix(i,j)));

       

       if j < cols

           string = strcat(string, ', ');

       end

   end

   

   if i < rows

       string = strcat(string, '],');

   end

end

string = strcat(string, ']');

string = strcat(string, ']');

These methods were used both for the ANN and for the analysis of the OFP physics.

Now, to connect this to the original topic: Those that want to do some physical modelling for OFP, I strongly recommend to analyze your data in some external application like Matlab or Mathematica or even Excel.

Share this post


Link to post
Share on other sites
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:

va1.jpg

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 smile_o.gif

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.

v1v2q.jpg

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:

d2sdt.jpg

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.  rock.gif

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:

data600a.jpg

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

traj1.jpg

mv300.jpg

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:

net500.jpg

After the release of the CoC Unified Artillery, I'll release the basic program used to test the nets as well as the data collection and neural net pack. It can serve as a simple foundation for anybody that wishes to play around with ballistics in OFP. smile_o.gif

oooooooohhhhhhh ahhhhhhhhhhhhh, look at the pretty charts biggrin_o.gif

Share this post


Link to post
Share on other sites

I've done some calculations, and apparently the strength of a satchel charge is about 280,000 joules?

The OFP engine is weird though, you can put the same bomb instead of on the side of the car, under the car, and the car will go higher and the same distance.

Am I forgetting to factor in another measurement? Time maybe?

Hrm...

Share this post


Link to post
Share on other sites
As a diffeq solver would require long CPU time for each solution a neural net was the prefered the choice.

Hmmmm if I compare Euler method and Neural method where are gains of CPU?    rock.gif

For errors look at this link (and in it a good sample of c++ artillery of Euler,Midpoint,RK3-4 methods) :

Artillery integration methods

Share this post


Link to post
Share on other sites
As a diffeq solver would require long CPU time for each solution a neural net was the prefered the choice.

Hmmmm if I compare Euler method and Neural method where are gains of CPU?    rock.gif

For errors look at this link (and in it a good sample of c++ artillery of Euler,Midpoint,RK3-4 methods) :

Artillery integration methods

RW vs OFPW wink_o.gif

Kind Regards Walker

Share this post


Link to post
Share on other sites
As a diffeq solver would require long CPU time for each solution a neural net was the prefered the choice.

Hmmmm if I compare Euler method and Neural method where are gains of CPU?    rock.gif

Big gains.

Euler method:

1) Iterative solution for range = f(alpha, zdiff...)

2) You have to search (secant method or golden cut etc) for optimal alpha.

Neural net:

1) Simple multiplication. For a typical net trained for artillery less than 100 ordinary multiplications are required.

2) You get alpha as output directly so you don't have to use any search method.

In practice the neural net is several thousand times faster than numerical solving of the differential equation.

Share this post


Link to post
Share on other sites
As a diffeq solver would require long CPU time for each solution a neural net was the prefered the choice.

Hmmmm if I compare Euler method and Neural method where are gains of CPU?    rock.gif

For errors look at this link (and in it a good sample of c++ artillery of Euler,Midpoint,RK3-4 methods) :

Artillery integration methods

RW vs OFPW  wink_o.gif

Kind Regards Walker

Don't undestand abbreviations, maybe vs, but?

With ofp it's not a question of "vs" it's only a game, more I'm not the queen of "Snow-white" I don't sayed this:

"Mirror, mirror on the wall, Who is the fairest script of all?"

And last : blues.gif (necessary cool, the blues)

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×