Projectile motion in opflash (res)

[CareyBear 0]

I've never posted in this forum before I did a search through here and a few other places on the net, and haven't found an answer to my questions.

A brief background: I'm working on a generic artillery system for OpFlash using setVelocity and basic trig - the problem I'm running into is that the drag effect on projectiles reduces accuracy substantially at ranges over about 400m, though maximum range achievable by this system should be several kilometers.

I've tried various experiements to attempt to isolate the drag factor, but the results I'm getting are a bit inconsistent.

I *think* that Flashpoint uses a turbulent flow drag model based on kv^2 where k is roughly -2 x 10^(-2) for a shell object (such as "Shell120") - at least, using that value I've managed to get my simulated projectiles achieving the same range for the same velocity as by direct experiment in the game.

I'm also pretty sure that the k / mass values are standardised for shell objects / car objects / tank objects so that all shells have the same terminal velocity, all cars have the same terminal velocity etc.

That value for k is only an estimate though - there would be no more accurate way to calculate it without knowing the object's *mass*. In fact, assuming a mass of 1 for a shell, the terminal velocity of a shell suggests a k value of -5 x 10^(-4) - but this doesn't give me accurate projections.

I can't believe I'm simulating a simulation to try and work this out, but there you go.

My questions are:

Does Flashpoint model air resistance with a standard physics model of turbulent drag (I assume it ignores laminar flow drag effects since they're all macro bodies)?

If so, what is the mass and/or k (drag coefficient) value for a bullet / tank shell? Does the model include Archimedes' effect?

If not... What algorithm or lookup system has been used to approximate air resistance?

If anyone can help me out, I'd appreciate it.

Cheers,

CareyBear

ofpec staff

[Prospero 1]

Bear in mind that if you're using setVelocity *in a loop* to set the trajectory of your shell in real-time, you need to take loop execution rate into account, and adjust for it. Failing to do so could lead to the "inconsistency" you mentioned.

Prospero

[Harnu 0]

Also remember that everything can only fly for a certain amount of time:

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

[CareyBear 0]

Prospero: I'm not using a loop with the actual experiments except to track current velocity and position of the test object, and when I do I refer to _time rather than using inaccurate delay values. Since the object is created at the start of the script, _time is accurate enough.

The idea is not to constantly update the velocity, but to be able to calculate an accurate *initial* velocity, so that air resistance effects on the trajectory of the object are included in the initial 'firing' of the projectile - this is because a) if you're gonna simulate something, may as well be as realistic as possible about it , and b) The system I have in mind should be fully MP compatible - though that may need a custom addon.

Harnu: Damn. I didn't realise that. That's a problem with anything over about 1km range, but one I can already see a few ways around. Thanks for those numbers, though.

[ralphwiggum 6]

i'm not sure if my comments are any helpful, but 9.8 m/s seems to be the gravity rate. i'm not sure if there is a drag coefficient, but i think OFP definitely simulates gravity.

[CareyBear 0]

Yes, OFP uses -9.8m/s/s as gravity (as far as I've been able to ascertain).

OFP *does* use some kind of drag modelling - I'm fairly certain of this. The reasons I believe it does are:

1) Objects have a terminal velocity.

   Car terminal velocity (tested with: Jeep, UAZ, Trabant): 47 m/s

   Shell terminal velocity (tested with: Heat105, Shell120, and the 30mm shell - can't remember the name): 140 m/s

Terminal velocity in physics is calculated by:

tv = sqrt (mg/k)

where tv = terminal velocity, m = mass, g = gravity & k = drag coefficent.

That's how I got a value for drag.. but that meant I had to use assumed values for mass of the object.

In physics, drag affects an object in flight according to the following equation:

f = kv^2

where f is the force applied in the opposite vector to the velocity (v). Note that it is dependent on velocity. This ain't no simple math problem folks. The only way I know of to calculate this accurately in advance is multivariable calculus, and I ain't goin there..  

A way to simulate it is to use a piece of code like:

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">_k = -2 * (10 ^ (-2))

_t = 0

_v = 100

_z = 0

_g = -9.8

#uphalf

~0.1

_t = _t + 0.1

_kv = -((_k * _v)^2) / 10

_v = _v + _kv

_v = _v + (_g / 10)

_z = _z + (_v / 10)

hint format ["Time: %1\nAlt: %2\nV: %3\ndv: %4", _t, _z, _v, _kv]

?(_v > 0): goto "uphalf"

_maxalt = _z

#downhalf

~0.1

_t = _t + 0.1

_kv = -((_k * _v)^2) / 10

_v = _v + _kv

_v = _v + (_g / 10)

_z = _z + (_v / 10)

hint format ["Time: %1\nAlt: %2\nv: %3\ndv: %4", _t, _z, _v, _kv]

?(_z > 0): goto "downhalf"

hint format ["Time: %1\nMax Alt: %2", _t, _maxalt]<span id='postcolor'>

This little script is a simulation of an object given an initial z velocity of 100m/s then falling down again. This script gives very similar results to a shell being fired upwards at 100m/s.

If you do not include a drag coefficient (set k to 0 at the start of the code) it is no longer a similar result to actually doing it in the game.

Oh, the delays are just so I could 'see' the imaginary shell going up and down again via the hints. I also had a version that simulated it in increments of 0.01 seconds, but the increase in precision did not make much difference.

[fake4ever 0]

Well it certainly would be appreciated that someone from the developing team would answer this question, since it's pretty hard to figure it out just by iterating through series of tests.

I'm also developing a 'true' artillery and have faced the same air drag problem. I'm using fixed elevation angle and initial velocity as a variable. Meaning that I'm simulating mortars

firing with upper angles 45-90. This is to avoid hitting the moutains and other obstacles. Everything is working just fine, speed and direction except the damn drag. Shells fall

too short as the distance to the target increases.

[fake] r0tta

[Doolittle 0]

CareyBear!  Master of neural nets, etc.  Glad to have you working on this problem, as it stumped me.  We've been trying to figure it out for a while http://www.flashpoint1985.com/cgi-bin....94;st=0

(Just wondered if you saw that discussion though we only go as far as you've already been, so nothing really new for you.)

Doolittle

(Sure, BIS tells us all about the TIDE code )

(BTW THIS IS A GAME & I think a big thing for programmers is to fool the user into believing what they're seeing but still keep speeds high. I'm pretty sure OFP isn't doing Coreolis Effect, etc. with its physics engine.)

[Guest]

I while ago I made a feed forward backpropagation neural network kit for OFP (for the Chain of Command). One of the tests on it that I did was projectile motion.

It worked for getting single path solutions (neural nets can unfortunately not handle multivalue functions) - for every impact position there are two possible velocity solutions.

My measurements in OFP were the starting position, the initial velocity vector and the impact point. The neural net was used to find the inverse function ( f(impact pos) = v,pos ).

It worked quite well, but since OFP can't save variables in any decent way all the weights of the net get lost when you restart the mission. Re-training the net each time requires too much time.

So unfortunately a neural net solution isn't very practical.

[uiox 0]

Why you don't use the drop command?

You have Time life start pos, velocity, a timer, initial volume & density,rubbing a script call by timer, a script call by the death of particle etc...

If you look at VektoBoson's scripts like fountain or dust, you can see only a management of start pos and velocity, and effect of water fall down is due to gravity.

More with drop command you can attach particle to an object so you draw the curve in the game and maybe understand what happen with set velocity.

In game like OFP sometime math and physic are not the solution coz some parameters are not same or not present and you cannot install sensors for know the wind (an addon?   )

With this I have an idea but no time for the moment to script it :

A drop dialog laboratory with all or a part of params and change them in real time in the game.

[dinger 1]

Or you can just do it like the pros:

write a mission/script where a projectile is given a set velocity vector (I'd use the same mV and different elevations, and do it for maybe 5 or 10 different mV "Charges"), and the script records the distance travelled (actually, "solve" for 100-m increments at both "Low Angle" <45 and "High Angle">45), TOF, velocity at impact and angle at impact (at 0 to 0 ASL, of course). Use the angle and velocity to calculate the difference in distance travelled for +/- one meter of elevation.

Have the array dimensioned first according to mV steps. ("Charges"), then by distance, and record the following fields to an array:

so for example:

Charge 5

mV = 250

distance:

5000 (Low Angle)

elevation: 32.1 degrees

TOF: 25 seconds

up/down 1m: 3 m.

If you want to get fancy:

+Measure the trajectory at apogee and at 1/4 and 3/4 of the travel, and store that information (distance, height ASL) for automatic calculation of Low-Angle fire capability.

+figure out the dispersion out of the barrel you want (in angular terms). Fire out test shells at max lateral(deflection) and max range dispersion for each solution. Determine the number of meters off the target, divide that number by four, and store as

PE(d) and PE(l)

---

Okay, now you've got this massive array generated by the computer. Save the game.

Now go grab the CoC technology demonstration save.fps decoder, and grab the array.

In a script, create an array with the prefix TFT (Tabular Firing Table), followed by the weapon type (e.g., TFTM102), and put the information from the save.fps in there.

Use that information for targeting.

This is roughly how artillery is targeted "in the field". Besides, it's damn cool.

I just wish I had time to do it myself, but I've sworn off computer games for now, and will stop frequenting these boards pretty soon.

[CareyBear 0]

Actually Dinger, that was the conclusion I'd come to as to the only way to effectively do it.

I didn't know that CoC has a .fps decoder.. I'll have to try that technique. I'm currently working on a 'goal seeking' algorithm that I can set up and leave running. Uses fuzzy logic to adjust the initial velocity until it gets within a 0.1% error for range, then tries again for +10m range.. If I get the damn thing working, here's hoping I can leave it running and go to bed, then wake up and write down all the values it's spat out, then use a lookup table for 10m range increments. At least.. that's the theory..

Similar to your approach denoir.

The thing is... you can do it with a fixed elevation angle, or a fixed muzzle velocity, but both limit you.. then you can do it with both variable, and get a major headache.

uiox: That's a good idea.. I haven't played with drop, but if you can create a particle with a volume and density, then you have a fixed mass, and I can actually figure out whether OFP uses physics or approximated physics... hmm... wow, a way to get a value for k!

*wanders off to play with drop[]*

One useful item can be found here, for anyone who's interested in the physics behind this problem but hasn't done honours physics.. Virginia University Physics - Air Resistance Excel Spreadsheet

[Guest]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (CareyBear @ Jan. 23 2003,06:37)</td></tr><tr><td id="QUOTE">I'm currently working on a 'goal seeking' algorithm that I can set up and leave running. Uses fuzzy logic to adjust the initial velocity until it gets within a 0.1% error for range, then tries again for +10m range.. If I get the damn thing working, here's hoping I can leave it running and go to bed, then wake up and write down all the values it's spat out, then use a lookup table for 10m range increments. At least.. that's the theory.. <span id='postcolor'>

Somebody used my reinforcement learning algorithm for ballistic targeting. I don't know any details though:

RL thread

It's quite possible, I think but it is not a good learning system for that task. Neural nets do a much better job.