Arma 2's Great Physics Engine!

[walker 0]

Hi [DirTyDeeDs]-Ziggy-

Now show us the video of a player hiding behind the blown up bodies and them absorbing the shots from AI and other players.

Why are the graphics so bad? How many klicks is the maximum view distance? What is maximum object count? Remember to get it working in ArmA you need to be able to cope with hundreds if not thousands of entities and objects.

Kind Regards walker

[-DirTyDeeDs--Ziggy- 0]

nah I dont have to do shit.

You dared Nemisis to provide any single example of ragdoll in MP, and I did that.

its possible. eat crow. :D

[NeMeSiS 11]

-Ziggy-;1901587']nah I dont have to do shit.

You dared Nemisis to provide any single example of ragdoll in MP' date=' and I did that.

its possible. eat crow. :D[/quote']

No, because they are not synchronized, so they dont count. What walker asked has afaik never been done, however what walker asked was something different than what was being discussed so it doesnt really matter.

[-DirTyDeeDs--Ziggy- 0]

well, Walker, pass the Crow to me then! nomnom :(

pardon.

[NeMeSiS 11]

-Ziggy-;1901596']well' date=' Walker, pass the Crow to me then! nomnom :(

pardon.[/quote']

Well, dont feel bad, walker made a rather specific request, so specific in fact that he asked for it even though it doesnt exist. ;)

[-DirTyDeeDs--Ziggy- 0]

yeah, its obvious to me I have nothing insightful or constructive to add to this discussion so I will butt out now. :j:

[maturin 12]

Take Walker with you and maybe we will get some workable suggestions for units that don't clip through houses, leaving their feet exposed like the Wicked Witch of the East.

[froggyluv 2136]

Honestly if the norm is too have these effects in games yet leave them out of MP for stated reasons -then whats the problem discussing it for SP?

Personally I find Arma series to be almost perfect up until the kill shot. Scale is magnificent, AI much improved and fun to play with (mostly), graphics very very good (on proper rig).

Its not Hollywood Im after -its variety in death and proper gravity. Variety in death means more memorable and unusual outcomes and thats a good thing. More dynamic destruction is also possible in SP magnifying these 1of a kind moments exponentionally. Gravity is gravity and when gone astray, breaks immersion.

MP already has 1 of a kind moments in that you are fighting humans and that alone lends itself to unpredictability. Ideally it'd be great to pursue these in SP and eventually possibly move to the MP realm after some years of smoothing it out as well as technological breakthrus.

Edited April 20, 2011 by froggyluv

[maturin 12]

SP ragdoll could be optimized quite easily. I personally see no need for it if you're just standing on a runway. But if you're standing on an object, like a building or bridge, let the system kick in to handle the possible drop of the edge or collision with a wall. If you're hit by a vehicle or a piece of heavy ordinance--same thing. And then freeze the ragdoll as soon as it stops moving. Make them automatically decelerate on ground slopes.

I agree that it's far from the most important thing BIS could be spending their time on, but you lost the right to say that after this game system requirements came out. Look at the fucking graphics on this thing! Having bodies hovering in mid air next in the midst of Crysis-quality visuals is just idiotic.

[froggyluv 2136]

, but you lost the right to say that after this game system requirements came out. Look at the fucking graphics on this thing! Having bodies hovering in mid air next in the midst of Crysis-quality visuals is just idiotic.

Sorry but you lost me here. NM, I understand it after reread :)

Edited April 20, 2011 by froggyluv

[CarlGustaffa 4]

Many MP games have ragdoll (I think even original Unreal Tournament back in the days). But as already stated, their end position can't be synchronized over several clients. That is usually not important in games that feature it, since picking up weapons and ammo and use the body for cover is of no importance. In Arma all of that matters.

@maturin: Consider a 100ms difference between clients between a "fall message" (see link above on "kill messages"). You start falling and is hit by a moving truck. On the other client, you reached the ground before truck impact. See the problem? Physics (and ragdoll) and synchronizing is a bitch, not trivial at all (as many seem to think).

[bwc153 10]

Because corspes hanging in midair by a toe look stupid and break immersion. A ragdoll or similar animation system would supply the seeming effects of gravity ...and gravity is good Walker. Play Warband and tell me ragdoll has zero effect on enjoyment of playing.

I've played it, I turn Ragdoll off, It's only 'enjoyment' is the ocassional laugh (when I actually have it on - rare) at how corpses slide down a seige-ramp (or hill) and it looks ridiculous.

[b00ce 160]

The ArmA 2 physics engine is more than good enough for what it's needed for. The APC flying through the air had mass, it moved believably as it flew. Granted, the initial launch wasn't realistic, but it's a glitch caused by physboxes colliding weird and happens with games that have "real physics". I honestly don't understand why people have such a big issue with it.

The flying bodies are an issue, of course, that needs to be fixed as soon as possible. RATHER than flying around in one piece they should just die where they are; maybe pushed away a FEW metres.

Nope.

*Graphic*

http://i167.photobucket.com/albums/u125/booce/1270690493737.gif

*Graphic*

Bodies fly. Granted, you don't fly 500 meters when hit by an M230. The main difference between real life and arma is the amount of gore.

[maddogx 13]

Many MP games have ragdoll (I think even original Unreal Tournament back in the days). But as already stated, their end position can't be synchronized over several clients. That is usually not important in games that feature it, since picking up weapons and ammo and use the body for cover is of no importance. In Arma all of that matters.

@maturin: Consider a 100ms difference between clients between a "fall message" (see link above on "kill messages"). You start falling and is hit by a moving truck. On the other client, you reached the ground before truck impact. See the problem? Physics (and ragdoll) and synchronizing is a bitch, not trivial at all (as many seem to think).

Not trivial, no, but there are ways to counter the problems you mentioned, ranging from simple to complex.

As I suggested before, implementing a low CPS synch message for the ragdoll torso, say once per second, would ensure that the body is in the same position everywhere. Does anyone here seriously think a single Vector3D is much to synch across a network once per second? It's happening dozens of times per second for live units all the time.

[dmarkwick 261]

Hi all

As I point out in the first section of my last post Ragdoll physics has no benefit.

So why do it?

Why waste CPU time?

Why waste development time on it?

Kind Regards walker

You've ignored at least one valid reason, a benefit of ragdoll, even limited limb-only ragdoll, is that bodies lying in the battlefield look different each time. One of the downsides to the current system is that after a short while of playing ArmA2, you can easily identify a dead body due to it being in one of 4 or 5 poses. Seeing something on the ground that you cannot quite make out makes you act differently.

---------- Post added at 01:06 PM ---------- Previous post was at 01:03 PM ----------

Watching wonky ragdolls vibrate like jello moulds on the ground is pretty shitty too. At least characters with animated death sequences don't continue to glitch out after they're dead.

Decent ragdoll systems apply a zero-processing state after the body has reached a level of inactivity. Applying ragdoll endlessly to static bodies is a gross misuse of ragdoll :)

---------- Post added at 01:13 PM ---------- Previous post was at 01:06 PM ----------

If you all realy think Laaagdoll physics can work in MP then I invite you to get off your arse and write the code, prove me wrong I will eat humble pie if you can. Believe me if you can solve how to do it in MP you will all be very rich and could write your own ticket with any game development or simulation company in the world.

You can understand the principle of using the current system to sync dead bodies across all clients yes? Now if that current system is used to only animate one torso element, say the chest segment, in exactly the same way as it already does right now, then the client ragdoll system can pose all the other segments locally, then you have a perfectly reasonable principle for MP ragdoll.

Need a fork? ;)

Why else do you think NO GAME HAS EVER GOT RAGDOLL PHYSICS TO WORK IN MP.

ArmA2 already has unique features. If no-one ever solved a problem simply because no-one has solved it before, we wouldn't even be playing games on PCs.

And, to finish off, I would be just as happy to see (full) ragdoll applied to SP only. I play ArmA2 almost exclusively SP anyway so this would suit me just great :)

Edited April 20, 2011 by DMarkwick

[BasileyOne 10]

not matter.

until BIS plan start selling "21+"-ESRB-rated games.

which is unlikely in present time.

[maturin 12]

Ragdolls make ratings higher? Is this some sort of demented European thing?

[ProfTournesol 956]

Ragdolls make ratings higher? Is this some sort of demented European thing?

Moreover who cares about ratings ? It's only an indication not an interdiction.

[dmarkwick 261]

Ragdolls make ratings higher? Is this some sort of demented European thing?

'Tis true. In Europe, when we die, we are allocated one of 5 different poses to die in. If we die in any sort of dynamic way, no-one under 21 is allowed to look at us.

[max power 21]

Decent ragdoll systems apply a zero-processing state after the body has reached a level of inactivity. Applying ragdoll endlessly to static bodies is a gross misuse of ragdoll :)

I think the problem is that sometimes they never get to that state.

[dmarkwick 261]

I think the problem is that sometimes they never get to that state.

It's dependent on the implementation, it's not a fundamental flaw of ragdoll systems in principle. "A level of inactivity" can be defined and tweaked for individual game types, in ArmA2 for example under the (my ;)) proposed ragdoll system the level of inactivity can be defined as either a low level of movement or a timeout, or more likely both.

[Big Dawg KS 6]

As always, when people bring up ragdoll they limit their discussions to a very specific set of issues that have already been discussed to death.

There's one thing that nobody ever manages to mention though; vehicles. It's possible to die inside of vehicles in ArmA 2, so death animations would still be required. Some vehicles may permit the use of ragdoll (ones that eject you on death for example), but it would be impossible to implement ragdoll exclusively for all deaths (if that was ever an argument).

Second, I don't think I've seen too many people actually talk about the typical ranges of engagement in ArmA 2. Distance from the player/camera makes a huge difference in RV, which has a lot of optimizations (especially noticible in MP). When people are far away, they typically get less attention. The extra processing required for ragdoll may not even pay off at those ranges, let alone function correctly if physics is also optimized at further ranges (or implementing ragdoll at those ranges may require retuning the physics, further increasing the performance cost).

Now, even if implemented only at very close ranges, there's going to be a noticible difference when you kill someone 10 feet in front of you, and when you walk up to someone you killed 1000 feet from you. There's also the fact that the majority of deaths occur off-screen, and the player wouldn't even have a chance to see them. If you don't do the ragdoll calculations for these, then there is going to be a noticible difference when you discover their bodies.

And even though in most situations, bodies tend to stay at rest once they hit the ground, they still need to be simulated. If they die on the top floor of a building, they have to be moved if that building is leveled. If they die leaning up against a fence, they need to move when that fence is knocked over. There are also situations where people use scripting that allows bodies to be moved. If you don't continue to simulate the ragdoll after the initial fall, then there are still going to be situations where it looks just as bad as static animations.

The point is that with the optimization required, the increase in immersion ragdoll would provide would probably be limited to the point where it's not even worth the extra cost. Personally, I would rather see some sort of psuedo-ragdoll that just uses more advanced animation interpolation (interpolation/blending are currently the biggest limitations/possible immersion breakers with the animation system), where the transitions between animations (or the animations themselves) can be more dynamic (ex: based on momentum of individual parts).

[dmarkwick 261]

As always, when people bring up ragdoll they limit their discussions to a very specific set of issues that have already been discussed to death.

Hi BD, at last a sensible list of reasonable arguments :) and for the most part are of course correct. But I'll address each one:

There's one thing that nobody ever manages to mention though; vehicles. It's possible to die inside of vehicles in ArmA 2, so death animations would still be required. Some vehicles may permit the use of ragdoll (ones that eject you on death for example), but it would be impossible to implement ragdoll exclusively for all deaths (if that was ever an argument).

Vehicles, yes. But in-vehicle deaths are possibly already handled differently in ArmA2 to out-of-vehicle deaths, so the current system could be retained under those situations. Or, again just lock the chest segment and let the rest sort themselves out via ragdoll, although I'll happily concede this is overkill for in-vehicle deaths.

Second, I don't think I've seen too many people actually talk about the typical ranges of engagement in ArmA 2. Distance from the player/camera makes a huge difference in RV, which has a lot of optimizations (especially noticible in MP). When people are far away, they typically get less attention. The extra processing required for ragdoll may not even pay off at those ranges, let alone function correctly if physics is also optimized at further ranges (or implementing ragdoll at those ranges may require retuning the physics, further increasing the performance cost).

ArmA2 implemented limb-limited ragdoll doesn't need to be too fancy, rigid limits and heavy values could cut down on the times each unit takes to settle to a zero-processing state.

Now, even if implemented only at very close ranges, there's going to be a noticible difference when you kill someone 10 feet in front of you, and when you walk up to someone you killed 1000 feet from you. There's also the fact that the majority of deaths occur off-screen, and the player wouldn't even have a chance to see them. If you don't do the ragdoll calculations for these, then there is going to be a noticible difference when you discover their bodies.

I read recently that ArmA2 already uses reduced priority for processing distant & out of sight units, and it really doesn't matter how slow distant ragdoll takes if no-one is seeing it.

And even though in most situations, bodies tend to stay at rest once they hit the ground, they still need to be simulated. If they die on the top floor of a building, they have to be moved if that building is leveled. If they die leaning up against a fence, they need to move when that fence is knocked over. There are also situations where people use scripting that allows bodies to be moved. If you don't continue to simulate the ragdoll after the initial fall, then there are still going to be situations where it looks just as bad as static animations.

All true, but you said something interesting - "looks just as bad as static animations" - therefore, 6 of one & half a dozen of the other? :) I think the benefits outweigh this one isolated problem, and there's no reason not to simply treat whatever bodies are on top of buildings as static once they've settled. Or indeed any body anywhere. I don't think the ragdoll system as I described it earlier would allow for bodies resting against walls in any case, it might have ragdoll elements, but it's still driven by the base chest segment position.

How are bodies on roofs currently handled?

The point is that with the optimization required, the increase in immersion ragdoll would provide would probably be limited to the point where it's not even worth the extra cost. Personally, I would rather see some sort of psuedo-ragdoll that just uses more advanced animation interpolation (interpolation/blending are currently the biggest limitations/possible immersion breakers with the animation system), where the transitions between animations (or the animations themselves) can be more dynamic (ex: based on momentum of individual parts).

Pseudo ragdoll is really the only way to implement it. Hard coding the chest segment in exactly the way it already is, and allowing the client machines to handle all the rest, seems to be a reasonable compromise.

[Big Dawg KS 6]

@All of your responses:

Ragdoll is still heavily dependent on physical geometry in the world.

Implementing ragdoll inside of vehicles (regardless of how you constrain it) seems extremely wasteful. For one, the collision geometry around every seat in every vehicle would need to be accurately generated (a lot of work for the artists). It may save on the amount of animations that need to be created, but vehicle animations are usually very reusable, where modelling geometry for the interiors of every vehicle would be a huge workload.

And when you say that it doesn't matter how long the processing takes, well, anything that uses physics is time-critical. If you slow down, speed up, or skip time when simulating physics interactions, you risk getting very incorrect results. Simply ignoring these calculations when the player is not around may also cause problems when the player finally does observe the object (essentially, you have no idea where the object should be when you need to resume simulation). Ragdoll may require changes to the physics optimization/priority in order to make it work correctly, which may have indirect impacts on performance (ex: may require all physics simulation to be done on more frequent updates).

[dmarkwick 261]

@All of your responses:

Ragdoll is still heavily dependent on physical geometry in the world.

Implementing ragdoll inside of vehicles (regardless of how you constrain it) seems extremely wasteful. For one, the collision geometry around every seat in every vehicle would need to be accurately generated (a lot of work for the artists). It may save on the amount of animations that need to be created, but vehicle animations are usually very reusable, where modelling geometry for the interiors of every vehicle would be a huge workload.

I fully agree.

And when you say that it doesn't matter how long the processing takes, well, anything that uses physics is time-critical. If you slow down, speed up, or skip time when simulating physics interactions, you risk getting very incorrect results.

Well I would disagree that the time-critical element would suffer because it recieves lower priority, many physics simulations take place in not realtime, the calculations just need the appropriate multipliers. That's not any kind of problem, my 3D softwares (Lightwave etc) calculate physics and they calculate them in whatever timescale it takes to calculate them. We're talking about units who might be a couple of kilometers away, my understanding is that these units already recieve lower processing priorities.

Simply ignoring these calculations when the player is not around may also cause problems when the player finally does observe the object (essentially, you have no idea where the object should be when you need to resume simulation). Ragdoll may require changes to the physics optimization/priority in order to make it work correctly, which may have indirect impacts on performance (ex: may require all physics simulation to be done on more frequent updates).

Again, I don't see too much problem, lower priority for distant units means exactly that, lower, not none. And really, no-one would care, or even be able to make any kind of judgement at all if a body pose ends up slightly different from one situation to another. Remember, all clients will be seeing different poses in any case, only the location of the chest segment would be the same.

Plus, rigid limb limits would prevent wildly different poses anyway. We're talking about just breaking up the poses enough so that they're not immediately identifiable.

Edited April 22, 2011 by DMarkwick