Arma 2's Great Physics Engine!

[Cookieeater 10]

Yes. In a corridor game with small levels like in some CoD. And yet corridor games don't do even that.

How about 3000-4000 on a typical ArmA2's map?

Because anything less will make for different kind of topics - "oh why one barrel did roll on the ground and another one just fell down through the wall like it has no physics?! baaaawwww"

A lot of games have server side physics with over 30 objects in them at once.(Counter Strike Source, Garry's mod, Crysis) I was thinking about improving vehicle physics by using Bullet, not add physics to anything else that isn't necessary. You won't have 3000-4000 vehicles on a map at the same time, and if you did, you'd probably crash the game. ArmA II's gameplay is affected by the shitty vehicle physics, so that takes priority over something cosmetic like a barrel.

Also your last statement is flawed. Development is progressive. Look at the Beta patches that are slowly fixing the AI. BIS adds in a new feature such as AI don't break formation, AI can travel roads now, or AI takes cover behind houses a little more. These might be small changes that release every week, but it's improved AI a fuckton in the long run.

"Why did BIS incorporate FLIR in when it doesn't simulate heat from the environment?! baaaw"

"Why did BIS add in tracers when you can see them even though they're heading at you?! baaaw"

"Why does BIS add in windows for vehicles when you can't shoot out from them? baaw"

I'd at least have the stuff even if people complain about it.

Edited April 16, 2011 by Cookieeater

[metalcraze 290]

How is my statement flawed? I meant that if BIS added proper physics for 30-40 objects it would create stupid looking situations where one object will have physics and the other one will act like it does now right in front of random player's eyes.

A lot of games have server side physics with over 30 objects in them at once.(Counter Strike Source, Garry's mod, Crysis)

On 100m by 100m maps yes.

I was thinking about improving vehicle physics by using Bullet, not add physics to anything else that isn't necessary.

Vehicle physics in the game are acceptable. Tanks feel heavy. Choppers have inertia (none of those full speed instant 180 degree turns you can see in f.e. BF games). Just because a single bug happens in the multiplayer game once in a few months means that BIS just needs to add more mass to vehicles or finetune something or whatever is needed to stop them from jumping.

If you however want vehicles in the game to have realistic physics that will mean that BIS will have to drive every single of those vehicles IRL and model their physics accordingly which is not a realistic expectation.

Edited April 16, 2011 by metalcraze

[Pulverizer 1]

if BIS added proper physics for 30-40 objects it would create stupid looking situations where one object will have physics and the other one will act like it does now right in front of random player's eyes.

It already is like that IIRC. When a mission maker inserts objects via createVehicle or the mission editor, they will have physics, while objects part of the island can only be destroyed.

Ie, a barrel placed in the editor can roll down a hill, unlike a barrel that is already on the map.

[rtka1234 10]

i think this is the new secret weapon for the us army .... the Flying Tank:cool:

[BasileyOne 10]

i will apreciate definitely good intentions/suggestions about improving Arma2 physics[hearts speaks, definitely]and could agree thats Arma2 physics wasn't perfect, if can be counted at all, but ... nature of VR engine generation thats physics really,really really hurt rest part of gaming environment in terms of resources consumptions. you can perfectly scale textures, geometry, sounds, lights LoD's, but [effectively. w/o realism or fairplay suffering impact]can't do same with physics.

another point - accepting/licensing 3rd-party stuff into project is one of worst ideas/decisions. even if you buy it with developers.

and btw from 3rd-part physics, NVidia was better. not [slowed to crawl in development]Havok or Bullet.

[Big Dawg KS 6]

How did we end up with another physics discussion? As usual it boils down to uninformed arguments with no constructive value. In the end, it's always the same conclusion; a new physics system isn't going to change anything, and it's probably never going to happen.

[NeMeSiS 11]

a new physics system isn't going to change anything, and it's probably never going to happen.

It may happen, but in ArmA3, and not patched in more then 1 year after the release of the game.

[BasileyOne 10]

How did we end up with another physics discussion? As usual it boils down to uninformed arguments with no constructive value. In the end, it's always the same conclusion; a new physics system isn't going to change anything, and it's probably never going to happen.

ie "anything isn't going my way"=="isn't going to change" in you vision ?

[MulleDK19 21]

On 100m by 100m maps yes.

You obviously don't know how physics are incorporated in multiplayer games.

[max power 21]

ie "anything isn't going my way"=="isn't going to change" in you vision ?

Yeah, like having a simpler physics engine is 'going' anyone's way. Like anyone is voting for a less functional physics solver than is possible. Get your head checked.

Edited April 18, 2011 by Max Power

[Big Dawg KS 6]

Yeah, like having a simpler physics engine is 'not going' anyone's way. Like anyone is voting for a less functional physics solver than is possible. Get your head checked.

As Max is saying, a better physics simulation would be great, but it's not something that seems important or probable. And please, no more with the "just use <insert 3rd-party physics middleware> and it will be better" suggestions; simply using someone elses physics code isn't going to fix all the limitations that RV3 faces.

[metalcraze 290]

It may happen, but in ArmA3, and not patched in more then 1 year after the release of the game.

It may happen when you will give people 16 core PCs, 5 GHz per core on some supercool new processor tech and 1 Gigabit internet channels.

I think it'd better if people got back to their weekly crying about how ArmA2 is so unoptimized with 200 AIs on their 4 years old dual-cores before going into physics territory

[NeMeSiS 11]

It may happen when you will give people 16 core PCs, 5 GHz per core on some supercool new processor tech and 1 Gigabit internet channels.

Well, that should be roughly around the release of ArmA3. ;)

All kidding aside, i do think that some ragdolls in singleplayer are possible, taking Mount&Blade as an example. That game also allowed (modded) battles with hundreds of units ingame at the same time, and at some point they added (quite simple) ragdolls. Now, to save performance you could allow only the x closest units ragdolling at the same, so old CPU's could have only 1 or 2 while my new quadcore could have >30 at the same time.

In ArmA2/3 the units the player kills should take priority, since i dont really care how someone drops dead if i dont see them. This would ofcourse mean that you would still occasionally run into units that stick out/through objects but at least it is a start.

Now for MP: I have a 100Mbit connection up and down, so for me it is not a problem, however i dont want to read more complaints about lag than we have now. :p

[BasileyOne 10]

why 1 Gbit ?

10GBASE-T [aka 10GE or 10GbE or 10 GigE &etc] http://en.wikipedia.org/wiki/10GBASE-T copper ethernet is 4 yrs old and perform very nice.

only limiting factor is eventual switch to CAT7 cable[cuz serious utilisation cause noticeable warming without "throttling" option turned on NIC drivers for legacy cables owners].

[Pulverizer 1]

Before ragdolls, I'd really like to see the soldiers that are still alive not lag and warp in MP. And vehicles not over-penetrating under low fps.

Although, I guess ragdoll would be entirely possible if they kept death animations as a fallback when there's too many active ragdolls or when a server owner wants to save bandwidth for things that actually have any importance to the game.

[roguetrooper 2]

I don't know why people insist in ragdolls. 'Random' physics is not practical in MP mode and the ArmA infantry already really dies ragdollish and in many ways.

It doesn't matter if this ragdollish look is made by prefigured animations or by in-time-physical calculations.

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.

Edited April 18, 2011 by RogueTrooper

[walker 0]

Hi all

IMHO Ragdoll is a waste of CPU and programming time that:

1) Is just Eye Candy and adds zero to game play.

2) In most implementations the physics is Hollywood not realism

3) Lags MP. (if it can be enacted in it at all)

4) Is a waste of BIS programming time. (which is a finite resource)

Hollywood Physics pretending to be real physics

Most Laaagdoll physics is about the Hollywood visions people have of what happens when people get shot. Where they get "Blown away" Fact is that even when shot by a fifty caliber all that happens is that the person shot falls to the ground, they are not jerked around like you see on TV or Films or games like COD.

The Laaagdoll physics you see in games does not happen here in reality. So why would we want to waste CPU and bandwidth on unrealistic physics. A shot that would move a body like in the Hollywood movies or unrealistic games like Battle Field would in reality just tear a chunk of the body and the body would just fall to the ground in much same way as it does in ArmA.

This flying bodies Laaagdoll rubbish just never happens in reality even point blank with a fifty caliber. Standard weapons right up to Uber sniper rifles do not kick a body about.

QCzD5uhSViY

Bodies fall when shot dead.

That is all.

Real Physics as in Newton's Third Law of Motion trumps the Hollywood crap of Laaagdoll physics.

Except for wounding where they often do not even fall and may not even be aware they were shot.

So the total purpose of Laaagdoll physics is what?

ZERO ZILCH NADA NOTHING NOWT!

Or if you want to split hairs two inches for a suspended body unaffected by friction, or resistive reaction and musculature.

The practicalities

Then we come to the practicalities; Laaagdoll physics has to either be:

Serverside Laaagdoll physics

All done on the server in which case it instantly becomes the highest overhead for bandwidth in network code. In fact for ArmA the player, entity and object bullets bushes, houses, street furniture count would make it impossible; as it would require a bandwidth beyond anything currently available and could never work across more than say one nation as distance and the speed of light would induce such massive lag, and amplifying the ping problems that even the fastest games suffer:

http://royal.pingdom.com/2007/06/01/theoretical-vs-real-world-speed-limit-of-ping/

to an intolerable level.

Consider also that either the whole model is modeled in Laaagdoll or we get anomalies. So this means visually significant parts must be modeled to prevent things like say hands not grasping the objects used. This means every finger has to be modeled.

3 Bytes of data per finger even simplified 4 fingers x 3 data bytes = 12 data bytes plus 4 bytes per thumb rotation for opposability. So 16 bytes just for one hand x 2 for for the normal compliment of two hands is 32 bytes.

Add another 2 bytes per wrist again it is rotation as well as bend. x two hands = 4 bytes totaling 36 bytes and we have not even reached the elbow.

NB Remember there are limitations on the bend and rotation for the CPU to include in the calculations, but they should not affect bandwidth.

I will forgo the rest, per arm it is about 24 bytes per arm of a simplified robotic looking body. 48 in total for two arms

Then we come the face and head neck do we want expression? Without it we can get away with say 10 bytes just get eyes to blink and jaw to open and close nodding putting eye to sight etc

So we are looking at simplified model with 58 Bytes so far another ten for legs and 6 for torso waist and hip.

That is 74 Bytes per entity just on animation we still have to put all the stuff in that ArmA already does like position in geography and the rest.

74 times 32 players a not unusual number of clients in ArmA I play on sever servers with 60 to 100 players and all this data is BI DIRECTIONAL PER CLIENT so double it.

And it all has to be pushed down the pipe for ever single client for every entity they see! In ArmA where there can be thousands of entities and we have not considered all the clutter objects houses etc etc.

If we include objects and do full vectors per object that is 3 Bytes per object part x tens of thousands...

You can just about do it on the mother board of a top of the range gaming PC for a game like Crysis but pumping it round the Internet to to anything from 32 to 100 plus clients?

Dream on.

So then you go for Client side physics.

Where each client does the physics on their own CPU, miss-matched CPUs, mother boards various amounts of RAM different graphic cards make it a horror for them to try to come up with the same calculation for each event.

Even if you can get them to do so, we then have to deal with fundamental part of physics, Chaos theory, which means that for complex physics minute changes in events amplify in something you may have heard of called the butterfly effect.

And since each client is apart and separately calculating everything these errors build up, any one who has played a game has experienced it, it is called desync and every byte of data that can vary between clients amplifies it.

BIS actually use a simplified client side physics!

And you have all experienced what desync does. As the errors build you see warping, then desync lag as the server tries to correct the error then a red chain and connection failed.

But what about the complication of Laaagdoll physics? Remember those 74 Bytes for a simplified entity model? Now you have to match them for each entity across every client! Each factor, object and entity, multiplied by each client, quickly becomes a exponential curve of errors. It is a huge extra load. As the sanity of the badly designed Laaagdoll physics model very quickly degenerates to anarchy. And in reality as in real world physics, the kind that includes chaos theory and the butterfly effect or more correctly, sensitive dependence on initial conditions, impossible to make work.

Game Over. The End. Walker

Edited April 19, 2011 by walker

[dmarkwick 261]

Hi all

*snipped for brevity*

Dream on.

It's been suggested a few times that ragdoll doesn't necessarily involve increasing MP traffic, normal current logic would suffice so that the torso is synced, and let the client machine ragdoll the limbs. There are only so many current animated death poses and each one is readily identifiable, the visual differences between semi-ragdoll poses would increase the need for player observation. If it necessitates the player feeling the need to pump a few extra rounds into something that *might* be a body, dead or alive, then so much the better :)

[Defunkt 431]

To my mind a much bigger problem than what death animation is played (ragdoll driven or otherwise) is that there's currently a pause which is either because it's waiting on the previous run/walk/whatever animation to complete or it requires the affected client to confirm the death and initiate the animation itself. Ragdoll or not that's still going to look a bit naff.

[maddogx 13]

It's been suggested a few times that ragdoll doesn't necessarily involve increasing MP traffic, normal current logic would suffice so that the torso is synced, and let the client machine ragdoll the limbs.

That's just one possible way to optimize it in MP, by the way. Here are a few more ideas:

#1: Using a deterministic physics engine, theoretically any ragdoll death animation would look almost* the same on every client, meaning that bodies would end up in more or less the same position.

(* Differences are still likely occur due to lag when a unit dies while moving.)

However, with some synchronization of the torso position, these differences could be corrected. Either synch the torso during the ragdoll phase at a low CPS, perhaps 2-3 times per second; or wait until after the ragdoll phase has completed and the body is in its final position - then synch it just once. The latter option would obviously lead to warping dead bodies in some cases, but I think it could work for the most part.

#2: Don't calculate ragdoll in real time when no players are around to see it anyway. If an AI unit is killed far away from any players, its ragdoll anim can theoretically be calculated slowly, with low priority, using whatever free CPU time happens to be available.

#3: Fall back to static death anims if absolutely necessary.

Disclaimer: I would rather see BIS work on more important things before they spent time implementing something like ragdoll. I'm just saying it's probably not as impossible as Walker keeps making it out to be.

[walker 0]

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

[NeMeSiS 11]

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

Technically you could say the same thing about animals and some other stuff that is already ingame, but it all has a positive effect on immersion and a small effect on gameplay.

Hell, i would waste some CPU cycles if it was implemented like in M&B for SP.

[froggyluv 2136]

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

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.

[max power 21]

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.

[froggyluv 2136]

Havent had that happen in WB too often and I play with a large amount of ragdoll. Surely there are hybrids and animations systems which could satisfy all. Ill be very interested in how BF3's ANT animation system plays out.