Gravity in ArmA

[TJ_au 0]

Gday,

Been doing some experimenting and charting and there appears to be a major error in the speed of gravity in ArmA. This might be whats responsible for some of the ballistic wierdness.

Using a couple of tests and ArmA seems to use a value of around 7.5m/s for gravity which is about 25% below the 9.8 - 10m/s that real gravity has. This seems a bit of a glaring error and is odd that such a mistake should be made.

[Donnervogel 0]

it would be good if you told us how you did your testing Because my scripts work fine when using 9.8m/s^2 for gravity (calculating ballistic trajectory curves for tank rounds for example) So I don't see any "weirdness" with trajectory. Infact I see that the trajectories behave realistic (not meaning that the weapons behave realistic but the physics behind the projectile work pretty realistic)

EDIT: here's a picture, green is the calculated path and yellow is the actual flightpath of the round. Looks pretty damn close to my calculations And it uses 9.8 for the gravity

[-CS-SOBR-1st-I-R- 0]

gravity depends on the location you are at.

If I remember right 9.8 was for Europe right ?

So again... where is Sahrani?

[cl10k 0]

it depends on your altitude...

places in australia and europe that share the same altitude (distance to the middle of the earth) also share the same gravity....

[Spokesperson 0]

It won't change that much even if Sahrani is down below. 9.8m/s^2 that is.

Not sure if that picture says anything, as you don't see the projectile fall at all (not significantly at least). Maybe it got there the first 0.1 seconds for instance? You won't see much of a difference between 7.5m/s^2 and 9.8m/s^2 in 0.1 secs.

I think the only way to show this is to drop something from a height. And register the current height every x:th second. Then compare it to the expected results.

When I spawn things in air they don't fall as I would expect them to. They are a bit too slow actually. But that just what I think it looks like, might be wrong.

[Donnervogel 0]

SOBR[1st-I-R] @ June 05 2007,01:20)]gravity depends on the location you are at.

If I remember right 9.8 was for Europe right ?

So again... where is Sahrani?

well the differences are not that big for other places (on earth at least - it would be somewhere inside +/-0.2 I think) 9.8 is a "generic" mean value for gravity on sea level.

Quote[/b] ]Not sure if that picture says anything, as you don't see the projectile fall at all (not significantly at least). Maybe it got there the first 0.1 seconds for instance? You won't see much of a difference between 7.5m/s^2 and 9.8m/s^2 in 0.1 secs.

what the picture shows, as I write, is that the calculation (using formulas from my physics book) match very well with what OFP produces when I use the value 9.8, That you don't see the projectile drop is something else. It does drop. that's for sure. But that path goes on for kilometers And it's not spawned. it's pure math plus visualising the actual flight path of the projectile fired from the tank.

[Spokesperson 0]

Ok, and if you input 7.5 you get something else?

Projectile "drop" occurs due to gravity.

It could be that projectile paths got one g while objects got another.

Edit: Distance doesn't matter very much. Even if it's km. The shot could be there almost instantly => no fall (practically).

[TJ_au 0]

I tested it by creating objects at set heights above the ground then timing how long they took to fall and comparing it with a predicted fall time.

the equation I used for predicted fall time was

PT = sqrt((2*height)/gravity)

which is a standard fall time prediction equation (to the best of my knowledge). To get predicted time to match fall time I had to use a value of 7.35 for gravity. This was done with streamlined objects such as bombs and rounds so that air resistance wasn't a major factor.

[Spokesperson 0]

How did you time the falling objects? Did you try different heights (shouldn't matter but I know that the engine behaves differently at places high up (=not too close to the ground, like 100m up)).

[TJ_au 0]

using a looped script that looks for the object height to go below 1 m. I take the time at the creation and the time at the impact and the difference is the fall time. I tried this with objects ranging between 500 and 1000m above ground. Thing is I got consistant results which tends to reinforce the findings. Doing this from these sort of heights the possible delay on the script executing shouldn't effect the results also. Ie on a fall of 20m the 0.5 second script update time could possible effect the timing, as the fall distance gets higher the 0.5 second script update will have very little impact on the timing.

[CharveL 0]

Friction also adds to bullet drop.

I'm fine with the gravity in ArmA but it would be nice not to be able to drive a Ural down a 200m sheer cliff and drive away down at the bottom.

[TJ_au 0]

Donnervogel,

nice work on the plotting. However i think the time frame on that test and the distance the results are viewable to doesn't prove it. The flight of the round to the distance apparent in the image would be maybe 0.5 seconds. You're not going to notice the difference between 7.35 and 9.8m/s over that time frame. What would be interesting is if you could do the same test from the top of one of the tall mountains (firing with 0 elevation to the shot) and look at the difference between the 2 traces at the end of the flight rather than the begining.

[fasad 1]

If you are using script (loops suggest you are using sqs), it could be a script delay/precision error. I've noticed that scripts are generally very casual in their timing. Try using a function.

[TJ_au 0]

Fasad,

thats why I did the experiments between 500-1000m. The time for 1000m is 15+ seconds I can't believe the scripts would be out by 25% in time especially when I'm watching the explosion of the item hitting the ground.

[Spokesperson 0]

What about manual timing then? Or say you drop a bomb, and kill some trigger guy on impact.

I think any air friction can be omitted for falling objects. It would require more cpu power. Dont think they added that for objects.

But it's possible that gun projectiles are treated differently for quality, and ("other") objects for performance. In games you (usually) dont even draw bullets, just imagine them.

[UNN 0]

Quote[/b] ]I think any air friction can be omitted for falling objects. It would require more cpu power. Dont think they added that for objects.

I would have thought they would have to implement some sort of terminal velocity for bombs and such like, otherwise they would keep accelerating. Gravity in a vacum will apply a constant acceleration.

An LGB dropped from 4000m  does not appear to travel any faster than one dropped from 1000m. At least as far as the naked eye is concerned. Although I've never bothered to check their speeds using a script.

@Tj_au

You did take the possibility of terminal velocity into account didn't you?

Edit:

There is also the Magnus effect. If I understand it correctly it applies lift to a bullet? If modeled in game, it would give the impression of reduced gravity.

[max power 21]

Magnus effect is not modelled in the game, and it accounts for very, very, very little of the total contribution to a bullet's trajectory. Too small to even consider modelling.

I have two issues with the original post.

Firstly, we must provide proof that the speed of gravity is not proper.

Secondly, we must prove that there is ballistic weirdness, and it what quality and quantity.

Outside of actually identifying the actual values/vectors for these things, there is nothing to talk about. A lot of people bring up a lot of issues on this board without providing or even requiring any kind of proof. We really have to do a better job of actually identifying issues before we go on to suggest possible causes or fixes. Let us not rely on something someone else said at some point in time.

[-SWAF-Lunatic 0]

It's also not Gravity, Gravity is the effect which causes it.

It's the acceleration due to gravity (g) g=9.81 m/s^2, as was correctly stated earlier, is due to your distance from the centre of the earth, so if you jump at the top of everest you will jump higher than if you jump as Sea Level (in theory and all factors being the same, mass carried etc).

[maddogx 13]

Lunatic @ June 05 2007,08:34)]It's also not Gravity, Gravity is the effect which causes it.

It's the acceleration due to gravity (g) g=9.81 m/s^2, as was correctly stated earlier, is due to your distance from the centre of the earth, so if you jump at the top of everest you will jump higher than if you jump as Sea Level (in theory and all factors being the same, mass carried etc).

I think we'll just stick to the generic term "gravitiy" instead of "gravity induced acceleration toward the center of the Earth". Because it's simpler.

Has anyone tried placing a tank or some other object at a certain hight, like 100m, and simultaneously creating a particle that simulates real gravity acceleration? If they hit the floor at the same time, it would prove that gravity in ArmA is correct. Otherwise we would see if it's really off.

[max power 21]

Lunatic @ June 05 2007,08:34)]It's also not Gravity, Gravity is the effect which causes it.

It's the acceleration due to gravity (g) g=9.81 m/s^2, as was correctly stated earlier, is due to your distance from the centre of the earth, so if you jump at the top of everest you will jump higher than if you jump as Sea Level (in theory and all factors being the same, mass carried etc).

I think we'll just stick to the generic term "gravitiy" instead of "gravity induced acceleration toward the center of the Earth". Because it's simpler.

Has anyone tried placing a tank or some other object at a certain hight, like 100m, and simultaneously creating a particle that simulates real gravity acceleration? If they hit the floor at the same time, it would prove that gravity in ArmA is correct. Otherwise we would see if it's really off.

I don't think we should compare unlike objects because gravity may be tweaked to work on different things differently, as in the case of non-flying objects like tanks. They may be changed slightly in order to tweak road-performance.

[maddogx 13]

I don't think we should compare unlike objects because gravity may be tweaked to work on different things differently, as in the case of non-flying objects like tanks.  They may be changed slightly in order to tweak road-performance.

Very true.

[Spokesperson 0]

Quote[/b] ]I would have thought they would have to implement some sort of terminal velocity for bombs and such like, otherwise they would keep accelerating. Gravity in a vacum will apply a constant acceleration.

An LGB dropped from 4000m  does not appear to travel any faster than one dropped from 1000m. At least as far as the naked eye is concerned. Although I've never bothered to check their speeds using a script.

Bombs a quite stream-lined and I guess it would need more than 4000 m for them to get constant velocity due to air resistance. I also think it would be strange to add that kind of thing to the game. Extra CPU-work + every object would need to have some air resistance coefficient included.

I did a soccer ball simulation once, it involved spin, air resistance etc. There are many differential equations involved. If every bullet is supposed to go through that it maybe would hit performance.

[vilas 477]

bullets trajectory i less important than flying BMPs when colides with T72 moving in column

bullet trajectory do not crush missions, but sometimes mission is failed because moving in column BMP with group of solidiers colides with something and flies :/

but this is proabably wrong made model, so every model has "mass" in geometry LOD

maybe bullets have no model and thats why behaviour is sometimes other than other model

[Donnervogel 0]

Donnervogel,

nice work on the plotting. However i think the time frame on that test and the distance the results are viewable to doesn't prove it. The flight of the round to the distance apparent in the image would be maybe 0.5 seconds. You're not going to notice the difference between 7.35 and 9.8m/s over that time frame. What would be interesting is if you could do the same test from the top of one of the tall mountains (firing with 0 elevation to the shot) and look at the difference between the 2 traces at the end of the flight rather than the begining.

Well the thing you see is after some time of flight (a distance of about 800m) of the round. I did more testing with 7.5 and the differences are. With 9.81 as Gravity I am +/-0.05m on target after 1 km. With 7.5 I am 0.2-0.3m too high after one kilometer. It increases with the same trend over larger distances. 7.5 ends up too high. There is obviously some derivation that I assume is from rounding errors and some OFP script engine delays or something. But it's really minimal.

I mean I didn't set up this test to prove the point that gravity is 9.8. I just happen to have worked on it for some time already and I just wanted to tell you that for what I am doing 9.8 seems to be closer to the value ArmA uses than 7.5. I can't tell much about falling speed. but maybe it would help if you caluclated the falling acceleration from the velocity vector (if you didn't do it already) of the object that is falling.

[Spokesperson 0]

I made a few tests. There's probably some kind of air resistance. Bombs don't fall right down. (GBU).

I get g values of around 7. Seems to change a little if the game is speeded up.

Call scripts: onMapSingleClick "[_pos] exec ""grav2.sqs"""

Test Script 1:

This one seems to get affected by air res.

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

_height=50;

_g=9.8;

_nrTests=15;

_pos=_this select 0;

_testNr=0;

#CreateBomb

_bomb="Bo_GBU12_LGB" createvehicle [_pos select 0, _pos select 1, (_pos select 2)+_height];

_t0=_time;

@(((getPos _bomb) select 2) < 0.05);

_t=_time;

hint format[" Passed Time: %1 .\n Expected Time: %2 .\n Estimated g: %3 .", (_t-_t0), (sqrt(2*_height/_g)),(2*_height/((_t-_t0)*(_t-_t0)))]

_height=_height+50;

_testNr=_testNr+1;

?(_testNr<_nrTests): goto "CreateBomb";

deleteVehicle _bomb;

onMapSingleClick "";

exit;

Test Script 2:

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

_height=50;

_g=9.8;

_nrTests=15;

_pos=_this select 0;

_testNr=0;

#CreateBomb

_bomb="CamelGrenades" createvehicle [_pos select 0, _pos select 1, (_pos select 2)+_height];

_t0=_time;

@(((getPos _bomb) select 2) < 0.05);

_t=_time;

if((_t-_t0)*(_t-_t0)==0) then

{

_estG="Trunc Error"

}

else

{

_estG=2*_height/((_t-_t0)*(_t-_t0));

}

hint format[" Passed Time: %1 .\n Expected Time: %2 .\n Estimated g: %3 .", (_t-_t0),(sqrt(2*_height/_g)), (_estG)]

_height=_height+50;

_testNr=_testNr+1;

?(_testNr<_nrTests): goto "CreateBomb";

deleteVehicle _bomb;

onMapSingleClick "";

exit;

For Camel Grens I get division by zero errors. A case that's already handled by the if statement. (Very strange). I shouldn't be getting division by zero errors there in the first case. The camel gren seems to start on the ground, not in air.

Tested the same thing with a plane. Same result.

The conclusion is that g=9.8 whether right or wrong won't be enough.