Jump to content
Sign in to follow this  
franze

CCIP Functions

Recommended Posts

The evil thing is, that you indeed need to calculate the "actual" trajectory, since only then you know the impact point, where you can calculate the traveled distance (thus the horizontal distance).

Well, using the calculation here, I was able to calculate distance without needing to know the actual trajectory or other information. That equation doesn't take into account air drag, so I may be wrong in how well that equation will work. But I presume if we can calculate the percentage of distance lost to air drag from the maximum distance an object would achieve in a vacuum, we'd have our answer.

Quote[/b] ]

Unless I'm misunderstanding you, drag isn't constant, but depends on the square of the velocity and direction. As drag influences velocity, velocity changes; now there's a nice differential equation for the velocity v:

dv/dt = gravity accel - 0.5*air density*drag area*drag coefficient*|v|*v/mass

Yes, that's basically my problem - the drag in ArmA behaves like it does in reality.

Quote[/b] ]

I guess we can assume air density to be constant at every height, and I guess that drag area and drag coefficient are merged into ArmA's air friction coefficient.

Also I ignored lift force in above equation, as I don't know which ArmA-coefficient is responsible for lift (which is what makes them fly).

I also ignored a possible angle of attack (angle between forward vector and velocity vector) which changes the drag area/drag coefficient.

I think you're right on here, in that most of the potential problems are likely simple constants. For example, I tried to calculate a free fall object trajectory but it used the exponential function which was very limited in how well it would work.  crazy_o.gif

Quote[/b] ]

One should make a dive attack when using CCIP, anyway. The reason is quite simple: In a dive the flying direction of the bomb won't change as much, as in a level attack. The trajectory is 'flat' (compared to level attack), thus the computed impact point is more accurate because of less integration/approximation/sensor errors. AFAIR the Falcon 4.0 manual is saying something similar.

A similar thing applies to the terrain: You can assume the terrain to be 'flat' in the impact region, thus you need to calculate terrain height only once (or take the average in the impact area).

The thing is, if we can make those dive attacks just a bit more accurate than trying to guess with the lone gun pipper a la WW2-era, then it's worth the trouble. The weapons we're talking about are inaccurate by their nature, and I seriously doubt the ASP-17 sight is/was the most accurate sight ever devised, so just getting things in the general area is a start.  smile_o.gif

Share this post


Link to post
Share on other sites
The evil thing is, that you indeed need to calculate the "actual" trajectory, since only then you know the impact point, where you can calculate the traveled distance (thus the horizontal distance).

Well, using the calculation here, I was able to calculate distance without needing to know the actual trajectory or other information. That equation doesn't take into account air drag, so I may be wrong in how well that equation will work. But I presume if we can calculate the percentage of distance lost to air drag from the maximum distance an object would achieve in a vacuum, we'd have our answer.

The above formula assumes a completely flat ground; as I said, for a diving attack this may be OK, but in the general case it is not.

That formula already knows the height difference between release point and impact point, but even if ignoring drag, you need to simulate the trajectory to find the impact point and travelling distance.

Of course you can use above formula to approximate the impact point, check the actual ground height and adjust the height difference till ground height and calculated impact point are near each other.

You could also introduce a small correction factor depending on the velocity/range; the longer the projectile flies, the longer it is affected by drag. I think you could find a good factor by simple guessing/testing.

Quote[/b] ]
Quote[/b] ]

I guess we can assume air density to be constant at every height, and I guess that drag area and drag coefficient are merged into ArmA's air friction coefficient.

Also I ignored lift force in above equation, as I don't know which ArmA-coefficient is responsible for lift (which is what makes them fly).

I also ignored a possible angle of attack (angle between forward vector and velocity vector) which changes the drag area/drag coefficient.

I think you're right on here, in that most of the potential problems are likely simple constants. For example, I tried to calculate a free fall object trajectory but it used the exponential function which was very limited in how well it would work. crazy_o.gif

Where do you get an exponential function from?

Share this post


Link to post
Share on other sites
The above formula assumes a completely flat ground; as I said, for a diving attack this may be OK, but in the general case it is not.

That formula already knows the height difference between release point and impact point, but even if ignoring drag, you need to simulate the trajectory to find the impact point and travelling distance.

Of course you can use above formula to approximate the impact point, check the actual ground height and adjust the height difference till ground height and calculated impact point are near each other.

You could also introduce a small correction factor depending on the velocity/range; the longer the projectile flies, the longer it is affected by drag. I think you could find a good factor by simple guessing/testing.

The assumption of completely flat ground is one of the inaccuracies I'm going with - I had intended to augment that with a fixed laser designator for increased accuracy, but I've had trouble figuring out just how to generate a laser at the aircraft's aiming point on the ground. Sadly, laser designators do not work with fixed wing aircraft.

I did attempt to make a linear calculation by catching how much horizontal distance was traveled for a given speed and a given altitude, but I haven't figured out how to plug that data into the drag factor.

Quote[/b] ]

Where do you get an exponential function from?

The exponential calculation I ran into here, part of calculating free fall with drag.

Share this post


Link to post
Share on other sites
Quote[/b] ]General Barron, much obliged for the input. You've got kind of the right idea, in that I don't need to calculate the actual trajectory. All I need to do is calculate the horizontal distance traveled, and animate the sight based upon that amount.

I think you've misunderstood me. What I'm saying is that to calculate the horizontal distance traveled, you SHOULD calculate the actual trajectory.

You should plot it out, step by step / point by point, until the trajectory hits the ground. Then you know the impact point. I don't think this can be calculated any other way. Not when you add air friction and a non-flat terrain into account. Vektorboson (who is much better at math) seems to be backing me up on this one.

If it were a simple calculation, why didn't WWII era planes have CCIPs of some sort? A simple calculation can be done mechanically, like with a slide ruler. But for the CCIP, I'd guess you need a computer to do it, because so many calculations need to be done so quickly.

--------

The script that I posted does just that. It is a loop that plots the trajectory of the bomb, if you were to release it at this very moment. This is very simple to calculate because there are only two forces acting on the bomb: gravity and air friction. Gravity is always pulling the bomb down, while airfriction (in Arma) is always pushing the opposite direction of where the bomb is traveling.

So all you have to do is apply those two forces, over and over again, to your imaginary bomb, until it hits the ground. Then you know where the bomb would impact (almost exactly), if you were to release it right now. Repeat every frame, or as quickly as Arma can handle the calculations.

--------

Btw, for bullets and shells, Arma handles air friction as follows:

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

_Vx = _Vx + (DELTAT*(_V*_Vx*_airFriction));

_Vy = _Vy + (DELTAT*(_V*_Vy*_airFriction));

_Vz = _Vz + (DELTAT*(_V*_Vz*_airFriction));

  Where:

_Vx/y/z = velocity in each direction (x / y / z)

_V = total velocity (magnitude of velocity vector)

DELTAT = time between simulation steps

_airFriction = airFriction value from CfgAmmo

So, every simulation step, the above formula is applied to the velocity, giving you a new velocity modified by air friction. In addition, the velocity is also modified by gravity in the downward (Z) direction using the standard 9.8 m/s/s value.

This applies to bullets and shells. I haven't tested to see if it applies to bombs or missiles. They might use a different method to simulate air resistance, or they might use the same formula but use sideAirFriction instead of airFriction from the config.

Share this post


Link to post
Share on other sites
This is very simple to calculate because there are only two forces acting on the bomb: gravity and air friction. Gravity is always pulling the bomb down, while airfriction (in Arma) is always pushing the opposite direction of where the bomb is traveling.

Hi, that's not completely correct; I've done some measurements, and I found that there is also lift. Please look at the following graphs.

horizontal and vertical speed:

speed.png

horizontal and vertical acceleration:

change.png

drag/lift coefficient k = 0.5*drag area*drag coeff/mass:

coeffs.png

As you see in the last graph, the drag coefficient is much higher for the vertical component than for the horizontal. This is because of lift.

This also seen in the acceleration graph; you see that there is less vertical deceleration, though gravity is pulling the bomb.

Please note, that I have used the GBU AV8B Harrier.

Share this post


Link to post
Share on other sites
I think you've misunderstood me. What I'm saying is that to calculate the horizontal distance traveled, you SHOULD calculate the actual trajectory.

You should plot it out, step by step / point by point, until the trajectory hits the ground. Then you know the impact point. I don't think this can be calculated any other way. Not when you add air friction and a non-flat terrain into account. Vektorboson (who is much better at math) seems to be backing me up on this one.

If it were a simple calculation, why didn't WWII era planes have CCIPs of some sort? A simple calculation can be done mechanically, like with a slide ruler. But for the CCIP, I'd guess you need a computer to do it, because so many calculations need to be done so quickly.

--------

The script that I posted does just that. It is a loop that plots the trajectory of the bomb, if you were to release it at this very moment. This is very simple to calculate because there are only two forces acting on the bomb: gravity and air friction. Gravity is always pulling the bomb down, while airfriction (in Arma) is always pushing the opposite direction of where the bomb is traveling.

So all you have to do is apply those two forces, over and over again, to your imaginary bomb, until it hits the ground. Then you know where the bomb would impact (almost exactly), if you were to release it right now. Repeat every frame, or as quickly as Arma can handle the calculations.

I still think it can be done with a simple distance calculation, but I'll try your method when I get a chance and see what comes up.

And there were several 'CCIP' sights during WW2: the most well-known was the Norden bombsight on US bombers. There were a couple of bombsights fitted to German Ju-87s and Ju-88s that calculated an impact point for a given speed and altitude. And toward the end of the war there were gyro gunsights which calculated gun lead for both aerial and ground targets.

Quote[/b] ]

Btw, for bullets and shells, Arma handles air friction as follows:

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

_Vx = _Vx + (DELTAT*(_V*_Vx*_airFriction));

_Vy = _Vy + (DELTAT*(_V*_Vy*_airFriction));

_Vz = _Vz + (DELTAT*(_V*_Vz*_airFriction));

Where:

_Vx/y/z = velocity in each direction (x / y / z)

_V = total velocity (magnitude of velocity vector)

DELTAT = time between simulation steps

_airFriction = airFriction value from CfgAmmo

So, every simulation step, the above formula is applied to the velocity, giving you a new velocity modified by air friction. In addition, the velocity is also modified by gravity in the downward (Z) direction using the standard 9.8 m/s/s value.

This applies to bullets and shells. I haven't tested to see if it applies to bombs or missiles. They might use a different method to simulate air resistance, or they might use the same formula but use sideAirFriction instead of airFriction from the config.

Interesting info, I see now where you're coming from with calculating trajectory via simulation steps. smile_o.gif

Share this post


Link to post
Share on other sites
Quote[/b] ]I've done some measurements, and I found that there is also lift. Please look at the following graphs.

Well, that's too bad. I guess it makes things a bit more complicated, unless we can figure out how the lift is defined.

For my part, I fleshed out my script from before, although it is based on the shell/bullet flight model (so it doesn't include the lift that bombs use). I'll post it here; it isn't really in a usable form, though somebody might do something with it (I guess you could turn it into an FCS for a tank or artillery).

At the moment, it has constants hard coded into it for the drag and initial velocity of the projectile. Of course, you would eventually want to read these from the config.

Also note: this script was written for VBS2. The convertToASL function doesn't exist in Arma, so some other way of finding terrain height would need to be used.

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

//work-in-progress ccip / fcs script

//by General Barron

//Note, this script only takes terrain into account.

//It does NOT account for objects or buildings on the terrain!

#define DELTA_T1     0.2    //sleep step used in script (between impact point calculations)

#define DELTA_T2     0.5    //time step used in trajectory simulations

#define G_CONST      9.81   //acceleration due to gravity

#define AIRFRICTION -0.0005 //air friction constant for the ammo being computed by the CCIP

#define INIT_VEL     0      //initial velocity of the ammo being computed by the CCIP

//#define DEBUG             //uncomment for visual debuggging

while {true} do

{

//position of ammo, if it were fired right now (same as firing vehicle)

_Px = (getposASL vehicle player) select 0;

_Py = (getposASL vehicle player) select 1;

_Pz = (getposASL vehicle player) select 2;

//base velocity of ammo, if it were fired right now (same as firing vehicle)

_Vx = (velocity vehicle player) select 0;

_Vy = (velocity vehicle player) select 1;

_Vz = (velocity vehicle player) select 2;

_Vmag = sqrt (_Vx^2 + _Vy^2 + _Vz^2);

//add in initial velocity of ammo due to being fired

_Vx = _Vx + (_Vx/_Vmag)*INIT_VEL;

_Vy = _Vy + (_Vy/_Vmag)*INIT_VEL;

_Vz = _Vz + (_Vz/_Vmag)*INIT_VEL;

//simulate ammo trajectory until it impacts the ground

while {_Pz > (convertToASL [_Px, _Py, 0]) select 2} do

{

//adjust ammo velocity for air friction and gravity (the only forces working on the ammo)

_Vmag = sqrt (_Vx^2 + _Vy^2 + _Vz^2);

_Vx = _Vx + DELTA_T2*(_Vmag*_Vx*AIRFRICTION);

_Vy = _Vy + DELTA_T2*(_Vmag*_Vy*AIRFRICTION);

_Vz = _Vz + DELTA_T2*(_Vmag*_Vz*AIRFRICTION-G_CONST); //factor in gravity here

//adjust ammo position using time step and new velocity

_Px = _Px + _Vx*DELTA_T2;

_Py = _Py + _Vy*DELTA_T2;

_Pz = _Pz + _Vz*DELTA_T2;

#ifdef DEBUG

//visual debugging

_cone = "vbs2_cone_no_geom" createVehicle [0,0,0];

_cone setposASL [_Px, _Py, _Pz];

_cone spawn {sleep DELTA_T1; deleteVehicle _this};

#endif

};

//we now have the impact position if we were to fire the ammo right now: [_Px, _Py, 0]

//todo: do something with this...

#ifdef DEBUG

//visual debugging

_arrow = "vbs2_visual_arrow_red" createVehicle [0,0,0];

_arrow setpos [_Px, _Py, 0];

_arrow spawn {sleep DELTA_T1; deleteVehicle _this};

#endif

//wait a bit before recalculating the impact point

sleep DELTA_T1;

};

Share this post


Link to post
Share on other sites
Well, that's too bad. I guess it makes things a bit more complicated, unless we can figure out how the lift is defined.

The question is whether or not the lift will make a noticeable effect on the trajectory. I haven't even gotten beyond the simple range of flight calculation.

Quote[/b] ]

For my part, I fleshed out my script from before, although it is based on the shell/bullet flight model (so it doesn't include the lift that bombs use). I'll post it here; it isn't really in a usable form, though somebody might do something with it (I guess you could turn it into an FCS for a tank or artillery).

At the moment, it has constants hard coded into it for the drag and initial velocity of the projectile. Of course, you would eventually want to read these from the config.

We could theoretically adjust the force of gravity to try and take into account the decreased vertical motion as a result of lift, within a certain speed range - that's all I've done for the different sight modes, adjust the amount of gravity in the calculation for a given setting.

Quote[/b] ]

Also note: this script was written for VBS2. The convertToASL function doesn't exist in Arma, so some other way of finding terrain height would need to be used.

I think we can get the ASL height of ground by taking the X and Y position coordinates, feeding them into the old getpos function, and then getposasl from that. The old emptydetector method at the corner of the world would work too.

Share this post


Link to post
Share on other sites

making your own trajectory might be easier heh

Share this post


Link to post
Share on other sites
making your own trajectory might be easier heh

Actually what would be easiest would be setting sideairfriction to 0 on all the bomb types, which would make them behave as if they were in a vacuum.  wink_o.gif

EDIT:

@ General Barron

Running your script, I get some really wild insane values for the simulated hit coordinates - they're all over the place.

EDIT2:

The problem was the air friction value I was using was not the correct value. Using the default air friction of -0.0005 given by General Barron, the system works as desired. This is the script currently in use:

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

//work-in-progress ccip / fcs script

//by General Barron

//Note, this script only takes terrain into account.

//It does NOT account for objects or buildings on the terrain!

#define DELTA_T1     0.2    //sleep step used in script (between impact point calculations)

#define DELTA_T2     0.5    //time step used in trajectory simulations

#define G_CONST      9.81   //acceleration due to gravity

#define AIRFRICTION -0.0005 //air friction constant for the ammo being computed by the CCIP

#define INIT_VEL     0      //initial velocity of the ammo being computed by the CCIP

//#define DEBUG             //uncomment for visual debuggging

//create an object for ASL calcs

_detector = "emptydetector" createVehicle (position player);

while {true} do

{

//position of ammo, if it were fired right now (same as firing vehicle)

_Px = (getposASL vehicle player) select 0;

_Py = (getposASL vehicle player) select 1;

_Pz = (getposASL vehicle player) select 2;

//set our detector position and get its ASL

_detector setpos [_Px,_Py,0];

_detectorasl = getposasl _detector;

//base velocity of ammo, if it were fired right now (same as firing vehicle)

_Vx = (velocity vehicle player) select 0;

_Vy = (velocity vehicle player) select 1;

_Vz = (velocity vehicle player) select 2;

_Vmag = sqrt (_Vx^2 + _Vy^2 + _Vz^2);

//add in initial velocity of ammo due to being fired

_Vx = _Vx + (_Vx/_Vmag)*INIT_VEL;

_Vy = _Vy + (_Vy/_Vmag)*INIT_VEL;

_Vz = _Vz + (_Vz/_Vmag)*INIT_VEL;

//simulate ammo trajectory until it impacts the ground

while {_Pz > (_detectorasl) select 2} do

{

//adjust ammo velocity for air friction and gravity (the only forces working on the ammo)

_Vmag = sqrt (_Vx^2 + _Vy^2 + _Vz^2);

_Vx = _Vx + DELTA_T2*(_Vmag*_Vx*AIRFRICTION);

_Vy = _Vy + DELTA_T2*(_Vmag*_Vy*AIRFRICTION);

_Vz = _Vz + DELTA_T2*(_Vmag*_Vz*AIRFRICTION-G_CONST); //factor in gravity here

//adjust ammo position using time step and new velocity

_Px = _Px + _Vx*DELTA_T2;

_Py = _Py + _Vy*DELTA_T2;

_Pz = _Pz + _Vz*DELTA_T2;

#ifdef DEBUG

//visual debugging

_cone = "vbs2_cone_no_geom" createVehicle [0,0,0];

_cone setposASL [_Px, _Py, _Pz];

_cone spawn {sleep DELTA_T1; deleteVehicle _this};

#endif

};

//we now have the impact position if we were to fire the ammo right now: [_Px, _Py, 0]

//todo: do something with this...

[group player, 1] setWPPos [_Px, _Py];

#ifdef DEBUG

//visual debugging

_arrow = "vbs2_visual_arrow_red" createVehicle [0,0,0];

_arrow setpos [_Px, _Py, 0];

_arrow spawn {sleep DELTA_T1; deleteVehicle _this};

#endif

//wait a bit before recalculating the impact point

sleep DELTA_T1;

};

I recommend others try the script above with a AV-8B w/ GBU and set the first waypoint as a hold waypoint. Use it as a aiming reference and see how well it works for you.

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  

×