CCIP Functions

[franze 196]

Ok, in short, I've managed to take the getpitch code by General Barron and apply it to the formula provided by Rocket (getpitch here and range of projectile here respectively), and managed to get a working CCIP system.

This is the system I have so far (pardon the confusing syntax, I spent most of the day experimenting)

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

_su17 = _this select 0

_dragsetting = 9

_dirtest = 0

_rotate = compile loadfile "frotate.sqf";

_su17 animate ["gunsight",0.08]

;;_su17 animate ["gunsight_yaw",0]

#gunloop

~0.01

;;pitch calculation

_yaw = getdir _su17;

_vdir = vectordir _su17

_vdir = [_vdir, _yaw] call _rotate

?((_vdir select 1) != 0): _pitch = atan ((_vdir select 2) / (_vdir select 1))

_jetspeed = speed _su17 * 0.2777

;;this is our base formula! we know this is accurate!

;;_gunlead = (125 * (cos 45)) / 9.81 * ((125 * (sin 45)) + sqrt (((125 * (sin 45))^2) + (2*9.81*100)))

;;grav setting is 9 for heavy bombs, 8 for light bombs, 450 for light rockets, 500 for heavy rockets

?(_jetspeed < 1 or (getpos _su17 select 2) <= 1): goto "gunloop"

?(_su17 animationphase "gs_switch" == 0): _dragsetting = 9

?(_su17 animationphase "gs_switch" == 0.25): _dragsetting = 7

?(_su17 animationphase "gs_switch" == 0.5): _dragsetting = 450

?(_su17 animationphase "gs_switch" == 0.75): _dragsetting = 500

_gunlead = (_jetspeed * (cos _pitch)) / _dragsetting * ((_jetspeed * (sin _pitch)) + sqrt (((_jetspeed * (sin _pitch))^2) + (2* _dragsetting *(getpos _su17 select 2))))

_gunlead = round _gunlead

;;max HUD gunlead value is 105 to 1200

?(_gunlead > 1200): _gunlead = 1200

?(_gunlead <= 105): _gunlead = 105

_pipanim = (0.92 / 1180) * _gunlead

?(_pipanim > 1): _pipanim = 1

_su17 animate ["gunsight",_pipanim]

goto "gunloop"

The problem is while I can get some reasonable accuracy in pitch, the issue is taking into account banking and yaw, and moving the CCIP sight as required for these variables. For example, in straight and level flight, no yaw or bank present, only pitch applies (as above). But in a slight bank with some yaw applied, strict pitch calculation doesn't work accurately enough.

So, what I need to do is to figure out how to:

1. Implement yaw and bank factors into the calculation;

2. and make all three calculations apply to two dimensions.

Any help is appreciated.

[kremator 1065]

OMG Franze, this is FANTASTIC news mate !

What about putting what you have found onto the Discussion forum in Arma? I know that I only check this forum VERY infrequently, but Discussion is checked daily.

This is one of the 'Holy Grail' scipts that everyone has been after !

Is there any chance of releasing an ALPHA mission with this in so that other can start to think about the maths !

Well done mate - CAN'T WAIT !

[TAO] Kremator

[.kju 3245]

nuxil was working on CCIP too

from what I can remember.

Doesn't hurt to ask him about his progress I guess.

[franze 196]

Q, you must mean this thread? That's where I got the distance calculation formula.

I should note that what I have now works fair, it is not pinpoint accuracy. I expect some margin of error (as I understand it this is true of real CCIP sights as well), but I'd also like to enhance accuracy by acquiring the altitude of the aircraft from it's aiming point - that is, if I'm pointing at an object 800m in front of me, and I'm 500m over the sea, but the object is 200m ASL, the altitude of my aiming point is actually 300m. I tried some simple implementations for aiming points but they worked very poorly.

[sakura_chan 9]

I've been working on CCIP as well, however I've taken a very different approach. I've gotten my system to be really accurate in any direction, speed or height, but I haven't gotten around to implementing pitch calculations. Its accurate within 1.5 meters even at supersonic speeds. Basically I have used range tables to animate the bomb's flight path, and each point in the flightpath is a man class unit in a cargo position within the flightpath's model. Because you can getpos a units position even if it is in a vehicle, you can make super accurate calculations of the impact point over hilly terrain without having to know the height of the plane or elevation of the impact point. This range table is attached to the plane itself (from inside o2) so you can more easily implement sights using some trig. The problem I've found with Arma is that the bombs aren't really freefalling at all, they have some wierd stuff going on that causes them to fly (sort of) instead of dropping down. The weight of the bomb's geo lod also affects its trajectory.

[.kju 3245]

yes thats the one.

i think he posted at ofpec some stuff too.

might be the same though

[franze 196]

@Sakura-chan

What you've done is to force the bomb to follow a path you want it to?

What I've got thus far attempts to calculate where the bomb will hit, and the system used (APS-17 optical sight) actually has settings for what you're using. So the sight works for what you've set it for, and the variable _dragvalue changes for various weapon types. This works reasonably well, with varying accuracy depending on launch conditions.

As I've said, the problems I have now are getting the aircraft's relative yaw and bank, and applying those values to the sight. Basically I need to take all three axises [x,y,z] and force them onto a two dimension plane [x,y]. I'd use direction for yaw, but that is relative to the aircraft's direction in the world, not the actual yaw experienced by the aircraft.

I assume that vectorUp has the value I need for relative yaw, but at the same time yaw may not exist at all. In that instance, I'll only need to combine pitch and bank into the sight.

EDIT:

The other thing about calculating an altitude at the aiming point, technically if I do that all with getposasl, and use the [x,y] position but with getpos instead, it should technically get me that position's ASL... If I use pure ASL for all positions.

[Serclaes 0]

I am no mathematics genius at all, quite the opposite in fact but i do have a few observations. I am missing the velocity. While the speed command returns only the speed ahead and backwards, while the velocity is the real speed. I am even not sure if the speed command returns the airspeed or the speed over ground.

As a scripter, i would advise you to calculate a position and then write another function which converts a 3d position onto a 2d position on screen.

Also, if you can't or are to lazy to convert it to sqf, i might be of help there

[franze 196]

The way the formula I used is written (as in the first post), it uses a m/s to calculate the velocity - it doesn't need the velocity vector, only the velocity, angle of launch, altitude it was launched at, and the gravitational acceleration (in ArmA, not a constant and varies depending on mass - the reason for my variable _dragvalue).

This value is accurate at sea level but over rough terrain accuracy varies; in the real thing, they use a laser to acquire a more accurate impact point, which is why I'd like to get a function to determine the altitude of what the aircraft is pointing at.

I'm not using sqf exclusively because I've had problems with incredible slowdowns with sqf files, and I feel more comfortable with using sqs over sqf.

[[aps]gnat 28]

Great projects, but a few from comments above just made me wonder if you guys are aware of;

sideAirFriction and airFriction

These CONFIG items effect the ballistics of the bombs, especially the first. Some of the default bombs "fly" because the values are a little off (probably to get bombs to "fly" to laser targets), but addon makers (probably including me) have simply copied these valves.

With adjusted values they seem to me to do the more typical ballistic trajectory.

slowdowns with sqf files

Theres several ways to use SQF files (pre-compiled etc) and I'm no expert, but a SQF with a few very small "sleep" commands slipped in here and there far out performs a SQS anytime.

To me it seems a sqf without any sleep commands simply 100% rips the CPU time to itself and make the game perform worse.

And when I say "slipped in here and there", I don't mean 1 sleep command at the end of a loop. If you have lots of maths and lots of If-Then etc, you have to slip a few in throughout the code to ensure you "spread the load".

Good Luck!

[franze 196]

@Gnat

Well, I've had sideairfriction on my bomb types since the days of FP, since it imparted a certain amount of holding velocity and a margin of error for guidance. The calculation of distance, as implemented with my sight, seems to work best with varying gravitational acceleration (that would be _dragvalue). As it stands, a value of 9 works best with my bombs of 500kg in weight, as they seem to hold their energy better over the lighter bombs (I have no idea why this is). Any changes I make to the weapon characteristics means having to recalibrate the sight as well.

SQF - that makes sense, considering we were always supposed to do the same with looping SQS scripts. I use SQF primarily for scripts that I do not need looped, but that's still fluid as I learn more about the format.

Also, if anyone is interested, here is a description of the various ways CCIP and CCRP can work.

[franze 196]

Here's an image to hopefully better convey what I'm trying to do:

[UNN 0]

Quote[/b] ]This value is accurate at sea level but over rough terrain accuracy varies; in the real thing, they use a laser to acquire a more accurate impact point, which is why I'd like to get a function to determine the altitude of what the aircraft is pointing at.

I would be interested in any pure maths solution, if you find one. Not sure if it applies to your problem, but what about the modelToWorld command? That should handle all the translations, so any maths you do before that can assume your aircraft is flying straight and level?

[franze 196]

Well, the problem I found with using that command and similar functions is that you can get a position that doesn't 'exist' in the game world - meaning, you can have a position at the center of the planet because it doesn't know where the ground level is. We can find out what the sea level is at our aiming point, but how do we know where the land begins at our aiming point?

[UNN 0]

Quote[/b] ]Well, the problem I found with using that command and similar functions is that you can get a position that doesn't 'exist' in the game world - meaning, you can have a position at the center of the planet because it doesn't know where the ground level is. We can find out what the sea level is at our aiming point, but how do we know where the land begins at our aiming point?

Thats always been a problem in OFP and ARMA. But does'nt the same apply with the pure maths function as well? I assumed you had already prepared some sort of sampling script to determine the land intersect, similar to the way COC's Command Engine does it. Although I appreciate in your case it's not ideal, as you probably want a quick routine to run every cycle to ensure an accurate impact point without the performance hit.

All this is handle quite well in VBS2 so we can only hope it makes it's way into ARMA2.

[sakura_chan 9]

@Sakura-chan

What you've done is to force the bomb to follow a path you want it to?

No, it just calculates the flightpath. because it is a 3d model, it doesn't need any calculations to correct for direction. It basically does what yours is missing (2d calculation and elevation), and yours has what I'm missing (pitch). Perhaps we could swap code and work out a final solution?

edit*

here is my ccip range:

[MehMan 0]

Hmm, if you make this work I might just love you. And reconsider finish my su-25.

[franze 196]

No, it just calculates the flightpath. because it is a 3d model, it doesn't need any calculations to correct for direction. It basically does what yours is missing (2d calculation and elevation), and yours has what I'm missing (pitch). Perhaps we could swap code and work out a final solution?

edit*

here is my ccip range:

http://i179.photobucket.com/albums/w312/lethalSakura/ccip.jpg

Getting the pitch is easy thanks to General Barron's getpitch and getbank functions. I modified my code to simply use that script in it's entirety.

The problem right now isn't really the distance calculation, it's modifying how the sight reacts to changes in the aircraft and the calculation. If I'm in a 90 degree bank with no pitch or yaw, then the sight's Y axis is shifted to the sight's X axis.

The way I calculate the distance is this:

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

distance = (speedinms * (cos pitch)) / gravityacceleration * ((speedinms * (sin pitch)) + sqrt (((speedinms * (sin pitch))^2) + (2* gravityacceleration * launchingaltitude)))

This is a literal translation of:

This does not take into account air resistance, which may be part of the reason for accuracy errors.

[franze 196]

Small update:

No headway yet on the ASP-17 transitional problem, but a better understanding of the CCIP system as implemented only works in a vacuum - meaning, I only have a system that works without air friction. So, the next step is factoring in a linear air friction to the distance value, but that apparently is a complex feat in itself...

EDIT:

Hit another dead end. Trying to calculate an object's free fall = impossible with computer systems. Haven't had any luck finding a simple way to calculate the distance with the addition of friction.

[t_d 47]

I wrote a function that could be useful for your issue. fWorldToScreen.sqf is given a position (in your case the bomb impact position) and calculates the screen coordinates for it.

Should work as long as FOV is 0.7, but havent test it very much.

Be careful: the function does not check if the position is seen on screen and will always return some values.

fWorldToScreen:

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

_camPos = positionCameraToWorld [0,0,0];

_camDirPos = positionCameraToWorld [0,0,1];

_camUpPos = positionCameraToWorld [0,1,0];

_tmpObj = "HeliHEmpty" createVehicleLocal [0,0];

_tmpObj setpos _camPos;

_camPosASL = getPosASL _tmpObj;

_tmpObj setpos _camDirPos;

_camDirPosASL = getPosASL _tmpObj;

_tmpObj setpos _camUpPos;

_camUpPosASL = getPosASL _tmpObj;

_vecDirCam = [_camPosASL, _camDirPosASL] call fVectorTo;

_vecUpCam = [_camPosASL, _camUpPosASL] call fVectorTo;

_tmpObj setpos _camPos;

_tmpObj setVectorDir _vecDirCam;

_tmpObj setVectorUp _vecUpCam;

_relPos = _tmpObj worldToModel _worldPos;

deleteVehicle _tmpObj;

_fov = 0.7;

_aspectRatio = 4/3;

_scrDis = _relPos select 1;

_d = 2*tan(deg _fov) * _scrDis;

_h = _d/sqrt(_aspectRatio*_aspectRatio + 1);

_w = _h * _aspectRatio;

_x = (_relPos select 0)/_w;

_y = (_relPos select 2)/_h;

_x = _x + 0.5;

_y = 0.5 - _y;

[_x,_y]

needs VectorLib.sqf (not all of its functions):

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

{

private['_v1','_v2','_f'];

_v1 = _this select 0;

_v2 = _this select 1;

_f = if (count _this > 2) then { _this select 2 } else { 1 };

[(_v1 select 0) + _f * (_v2 select 0),

(_v1 select 1) + _f * (_v2 select 1),

(_v1 select 2) + _f * (_v2 select 2)]

};

fVectorLength =

{

sqrt( ((_this select 0)^2) + ((_this select 1)^2) + ((_this select 2)^2) )

};

fVectorNormalize =

{

private['_l'];

_l = _this call fVectorLength;

if (_l != 0) then {

[(_this select 0) / _l, (_this select 1) / _l, (_this select 2) / _l]

} else {

[0,0,0]

}

};

fVectorSubstract =

{

private['_v1','_v2','_f'];

_v1 = _this select 0;

_v2 = _this select 1;

_f = if (count _this > 2) then { _this select 2 } else { 1 };

[(_v1 select 0) - _f * (_v2 select 0),

(_v1 select 1) - _f * (_v2 select 1),

(_v1 select 2) - _f * (_v2 select 2)]

};

fVectorTo =

{

[_this select 1, _this select 0] call fVectorSubstract

};

fVectorProduct =

{

private['_v1','_v2','_sp'];

_v1 = _this select 0;

_v2 = _this select 1;

_sp= if (count _this > 2) then { _this select 2 } else { false };

if (_v2 in [_v2]) then {

[_v2 * (_v1 select 0), _v2 * (_v1 select 1), _v2 * (_v1 select 2)]

} else {

if (_sp) then {

(_v1 select 0)*(_v2 select 0) + (_v1 select 1)*(_v2 select 1) + (_v1 select 2)*(_v2 select 2)

} else {

[

(_v1 select 1)*(_v2 select 2) - (_v1 select 2)*(_v2 select 1),

- ((_v1 select 0)*(_v2 select 2) - (_v1 select 2)*(_v2 select 0)),

(_v1 select 0)*(_v2 select 1) - (_v1 select 1)*(_v2 select 0)

]

}

}

};

fVectorAngle =

{

private['_v1','_v2','_v1l','_v2l', '_result'];

_v1 = _this select 0;

if(count _this > 1)then {

_v2 = _this select 1;

} else {

_v2 = [_v1 select 0, _v1 select 1, 0];

};

_v1l = _v1 call fVectorLength;

_v2l = _v2 call fVectorLength;

if ((_v1l * _v2l) != 0) then {

_result = acos(([_v1, _v2, true] call fVectorProduct) / (_v1l * _v2l))

} else {

_result = 0;

};

_result

};

fVectorSide =

{

private['_vDir','_vUp'];

_vDir = vectorDir _this;

_vUp = vectorUp _this;

([_vDir,_vUp] call fVectorProduct) call fVectorNormalize

};

[franze 196]

T_D, thanks for the input, but that doesn't really help much at this point. The problem now is adding drag into the distance calculation and adjusting the sight x/y inputs.

[General Barron 0]

I don't think it is possible to calculate the trajectory in a single line when you factor drag into it. Maybe with some very advanced calculus, but I asked something similar on a math forum and was unable to get an answer.

So, rather than try to calculate a trajectory in one equation, why not just simulate it?

So, every loop, you simulate the bomb's trajectory until it hits the ground. Then you know the impact point, and you animate your sight. Repeat continuously.

To do this, you should only need the plane's velocity and position. You then run a loop, where each step you apply gravity and airfriction from a given delta T, to update the bomb's virtual position. Then check if this new position is in the ground or not.

Something roughly like this:

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

while {bombsight is on} do

{

#define DELTA_T 0.1 //time step used in trajectory calculations

#define GRAVITY 9.8 //acceleration due to gravity

_bombPos = getposASL plane;

_bombVel = velocity plane;

//simulate bomb trajectory

while {_bombPos select 2 > *ground altitude at that point*} do

{

//adjust bomb velocity for gravity

_bombVel set [2, (_bombVel select 2)-GRAVITY*DELTA_T];

//adjust bomb velocity for air friction

//(need to look up calculation for this)

//adjust bomb position using time step and new velocity

_bombPos = _bombPos PLUS (_bombVel TIMES DELTA_T); //matrix operations need to be done here

};

//we now have the impact position if we were to release the bomb right now

_bombPos

//somehow animate sight

...do something...

//wait a bit before recalculating the sight

sleep 0.1;

};

As for positioning the sight itself, you could just use T_D's world to screen pos function, now that you have the world pos where the bomb will impact.

So, say you feed that pos into his function, and you get a result of X=.75, y=0.2. You now just animate your sight or dialog or whatever so that the reticle is at that position on the screen.

It shouldn't matter what your pitch or bank or yaw is, assuming that T_D's function takes all of this into account.

Alternatively, you could just position an object or particle or waypoint in the 3d world at the impact position itself. No need to bother with 2d screen calculations, as the graphics engine takes care of that for you (obviously, you'd want this to only be local to the player in MP).

[franze 196]

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.

What I've got works now, but it doesn't take into account the effect air drag has. It seems that the air drag in ArmA isn't constant, so the trick is figuring out how to calculate the air drag for a given speed. I tried a set coefficient and gradually adjusting that for a given speed range, but it was highly inaccurate.

To give a better explanation, I only need the distance the object is going to travel horizontally. If we figure the aircraft releases the weapon from a -90 degree pitch, there is effectively no horizontal movement (ignoring wind and other factors). At a pitch of -35 though, there is a much greater amount of horizontal motion, but eventually due to air resistance there will not be anymore horizontal distance traveled.

So using horizontal distance, we always know that eventually the object will hit the ground, we aren't concerned with the trajectory - only the horizontal distanced traveled.

[havocsquad 0]

I believe the most effective means for handling the HUD distance from the flight path marker is...  Take the horizontal bomb flight distance from "pickle" time to boom.  Now compute the horizontal distance from "pickle" point to the flight path marker point in which your plane will become a "lawn dart." into the ground

Then subtract the bomb horizontal distance from the "lawn dart" distance and then determine the angle from impact point to flight path marker point.

The angle number is a decent "absolute value" to use to control in HUD.

I believe good ole SIN, COS, TAN, COSIN, SEC, COT will handle how you plot the CCIP line and death dot on the screen.

[vektorboson 8]

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.

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).

Quote[/b] ]What I've got works now, but it doesn't take into account the effect air drag has. It seems that the air drag in ArmA isn't constant, so the trick is figuring out how to calculate the air drag for a given speed. I tried a set coefficient and gradually adjusting that for a given speed range, but it was highly inaccurate.

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

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.

Anyway, this equation needs to be integrated twice and the resulting position needs to be checked whether it is near the ground. If it is near or below the ground, you have your impact point, and thus your distance. Otherwise you keep on integrating, or abort after a specific amount of iterations.

---

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).