49 replies to this topic

[Cayp]

stjobe, on 14 September 2014 - 10:59 AM, said:

...It's because they have no reason to lie about that.
I believe they did remove it because...

Why so sure about that? I can imagine a lot of reasons. And the main is always money.

Your belief in what devs done is irrelevant in the same way as my incredulity.

As I'm working in IT, so as you, - I really know what I should say to client to calm him down and make him forget about what he's asking for. And that's whats being said about leg animation - exactly it, and you are simply repeating it after devs with nothing to add.

They made netcode server-side authoritative and I'm happy with that.

So why IK animation should be cutted down? And I should forget about IT forever? Till next MechWarrior game?
Nobody even mentioning about possibility to bring this back! It's part of the simulation!
Why somebody decided that this is acceptable solution?
Why nobody tries to fix it?

If with next update they will say "Mech animation causes performance issues and we decided to turn it off totally. it affects the game in the least way. Now mechs just flying. pew pew" - You will eat it in the same way you ate it about IK animation?!
No?
You will want to save MechWarrior arcade mode but you don't want to save MechWarrior as a simulation? Why?!

[stjobe]

In a client-side authoritative game, the IK calculations can be done on the client; it's there the hit calculations are done anyway. However, once you go to server-side authoritative, all the calculations must be done on the server since a bent leg could mean a miss instead of a a hit.

So the server needs to do all the IK calculations for 24 'mechs, in addition to everything else it has to do. It also has to do it in the context of a roughly .4 second HSR environment.

You are of course free to believe that the devs lie about it and are really holding IK back out of spite or to make money, but to me that is crossing into crazy conspiracy theory territory.

[Cayp]

stjobe, on 14 September 2014 - 12:10 PM, said:

In a client-side authoritative game, the IK calculations can be done on the client; it's there the hit calculations are done anyway. However, once you go to server-side authoritative, all the calculations must be done on the server since a bent leg could mean a miss instead of a a hit.

So the server needs to do all the IK calculations for 24 'mechs, in addition to everything else it has to do. It also has to do it in the context of a roughly .4 second HSR environment.

Exactly what I'm saying!

Servers NEED to do this calculations.
Servers MUST do this calculations.
Servers are built to do this kind of work!

What's so impossible about that that we cannot even talk about it or ask?

[stjobe]

Cayp, on 14 September 2014 - 12:22 PM, said:

Servers NEED to do this calculations.
Servers MUST do this calculations.
Servers are built to do this kind of work!

I don't know if it's a language issue or an understanding issue, but you make no sense. "Servers", either in the hardware or software sense, aren't "built to do this kind of work".

They had servers (hardware) that ran servers (software) that did things one way. Then they re-programmed the software do do things another way - this introduced, according to them, performance issues that meant that they had to shut off the IK calculations.

So no, the server software is NOT "built to do this kind of work" - if it does try to do that, it has bad performance. That's what they meant when they said it was removed in a performance pass.

For the servers to be "built to do this kind of work", they'd have to re-program the server software once again, trying to squeeze out some more performance (likely in the HSR code or in the netcode) so they could switch on IK again without losing performance compared to now.

Cayp, on 14 September 2014 - 12:22 PM, said:

What's so impossible about that that we cannot even talk about it or ask?

You're of course perfectly free to talk about it (in fact, I do believe you and me are having a conversation right now), and you're as free to ask the devs why they removed it. I'd recommend Karl Berg's thread for those questions though, and I don't guarantee you'll get an answer. I'm also not sure you'll be happy with the answer if you get one.

[Randodan]

I totally agree. That level of detail is one of the things simulations do, but action games do not. So MWO has clearly moved away from simulating Mech combat to a more generic action game that doesn't care about details and no longer caters to the old-school Mechwarrior fan base. Damn shame...

[Cayp]

When talking about servers I generally understand hardware.

stjobe, on 14 September 2014 - 12:32 PM, said:

They had servers (hardware) that ran servers (software) that did things one way. Then they re-programmed the software do do things another way - this introduced, according to them, performance issues that meant that they had to shut off the IK calculations.

So what? It cannot be fixed? Because of what?
There are no hardware on our planet that can run such "high" workloads that Pentium 166Mhz was able to run for 24 mechs?!
Or there are no programmers on our planet that can write such code without "performance issues"?

stjobe, on 14 September 2014 - 12:32 PM, said:

So no, the server software is NOT "built to do this kind of work" - if it does try to do that, it has bad performance. That's what they meant when they said it was removed in a performance pass.

And bad performance not an excuse.
Server software is what devs create. If their creation is simply not good - it should be updated/fixed.

stjobe, on 14 September 2014 - 12:32 PM, said:

For the servers to be "built to do this kind of work", they'd have to re-program the server software once again, trying to squeeze out some more performance (likely in the HSR code or in the netcode) so they could switch on IK again without losing performance compared to now.

Thats exactly what I'm expecting from devs to do! Or they can just buy bigger and more servers for that work.

stjobe, on 14 September 2014 - 12:32 PM, said:

You're of course perfectly free to talk about it (in fact, I do believe you and me are having a conversation right now), and you're as free to ask the devs why they removed it. I'd recommend Karl Berg's thread for those questions though, and I don't guarantee you'll get an answer. I'm also not sure you'll be happy with the answer if you get one.

Thanks, I'll use that.

[William Mountbank]

I think it had do with lag rather than server usage. Sure, the servers will have the horsepower to do IK - my AMD K6iii could manage it for two instances at least (although I would guess each mech leg has up to 10 bones, making 200ish instances) - but if there is some kind of lag issue then your mech will be updating it's leg position maybe 200ms too late for believable simulation. Believable is the key here.

It's not really that the servers can't do it, but will it look good once its gotten to your client and turned into some kind of crazy underground waggle dance?

[Cayp]

William Mountbank, on 14 September 2014 - 01:04 PM, said:

I think it had do with lag rather than server usage.

I do not agree.
Information about all mech joint and bones orientation and position isn't so big.

Simple calculation:
1 floating point value = 32bits = 4bytes
1 Bone or joint position and orientation = 6 floating point numbers (X,Y,Z and 3 angles) = 24 bytes
Lets assume one mech have 20 bones to animate = 480bytes
24 mechs = 11520 bytes or 11,25kbytes
Lets assume this information should be transmitted 4 times per second = 45kbytes/s
And it's without compression and optimization, just raw size of data.

We cannot afford additional 45 kbytes/s per player in 21st century?

Games are now streamed as video online! Live! (Gaikai, OnLive)

[William Mountbank]

Cayp, on 14 September 2014 - 01:30 PM, said:

I do not agree.

I didn't decide to remove IK, I would it put back in, so no need to prove to me we should have it. But I would still buy the argument that if the IK data is more than 100ms out of synch, then in the Cryengine there are render problems on the MWO client that mean the animations aren't rendered believably. 45kbytes isn't a problem....... ....unless it arrives half a second late and your Atlas does the Can-can.

[Cayp]

William Mountbank, on 14 September 2014 - 01:40 PM, said:

...unless it arrives half a second late...

Yeah, right, it's the most important data in MWO traffic.
What about half second late for weapon triggering ar simple mech position? Reaallly scaary!
But wait, you are OK with it now! /sarcasm

Then why IK data is more important and harder to sync than any other?

[CycKath]

Definitely think less care and attention was given to the OmniMechs compared to Is 'Mechs with regards leg animations.

[Cayp]

Yep, MadCat looks like yellow chicken jumping over rocks, not like 75 ton stomping mech.

Edited by Cayp, 15 September 2014 - 01:21 AM.

[Impyrium]

Cayp, on 14 September 2014 - 01:30 PM, said:

I do not agree.
Information about all mech joint and bones orientation and position isn't so big.

Simple calculation:
1 floating point value = 32bits = 4bytes
1 Bone or joint position and orientation = 6 floating point numbers (X,Y,Z and 3 angles) = 24 bytes
Lets assume one mech have 20 bones to animate = 480bytes
24 mechs = 11520 bytes or 11,25kbytes
Lets assume this information should be transmitted 4 times per second = 45kbytes/s
And it's without compression and optimization, just raw size of data.

We cannot afford additional 45 kbytes/s per player in 21st century?

Games are now streamed as video online! Live! (Gaikai, OnLive)

Yeah, and I can't use OnLive. Please be aware that there are others in the world that do not have the high tech internet connections you speak of, and we pay just as much as you to keep the game going.

I'm pretty sure 45kbytes/s would make a significant difference.

[Cayp]

AUSwarrior24, on 15 September 2014 - 01:49 AM, said:

Yeah, and I can't use OnLive. Please be aware that there are others in the world that do not have the high tech internet connections you speak of, and we pay just as much as you to keep the game going.

Yep, OnLive recommends 5 Mbps. My point in that it's not even comparable to 45kbytes/s and still can be achieved.

AUSwarrior24, on 15 September 2014 - 01:49 AM, said:

I'm pretty sure 45kbytes/s would make a significant difference.

If you are so sure - please, share with us yours arguments about it.

I simply don't want to bury IK animation like majority in this thread did, just being sure with no reasons.
I see a lot of ways to make this work with low impact on internet connection.

[9erRed]

Greetings all,

A lot of the early posted videos from other games shows quite a bit of difference in how the speed, design and stride effects the leg movement. With most effecting the torso and upper body causing a side to side movement as the weight changes legs.
- Torso angle shifting, and hip angle all needing to be animated as well as the upper body movement adjustments.
- We had something similar early in the game and it made some Pilots 'car sick', so it was removed.
- This still doesn't change the actual 'gait' of the different Mech's, even if the sideways movement is removed.

Most of the animations start to fail to be believable as the Mech reach's it's upper speeds.
- We have one animation for slow walking steps and just speeding it up for faster movement.
- This is not how forward movement works for a walking element transiting to a run.
- As the speed increases so does the stride distance, in some cases the actual speed of the legs does not increase they just open up the stride length.
(IRL a person will judge the terrain in front of them and make slight adjustments to the stride to place the feet on suitable locations, all in split seconds.)
- For the game the adjusting the stride length would probably not be suitable, but extending the stride length is quite doable.
- This will also effect turning radius and slowing down as the stride must transition back to the walk gait first.
(really pushing the envelope would be to create a skid dynamic for a full stop from a run, full gyro balance effects and straight legged sliding if on hard surfaces. Not going to happen!) ~ it's a multiplayer game not a single Mech simulator.

Quite a bit of real life robotic walking and running dynamics have been done and we have working fast moving two legged machines, none that even come close to massive weights. But the walk/run action is a matter of documented and working fact.
- This is for both straight legged and 'chicken' walker styles.

The only Mech that was designed with any correct walk style was the original Catapult. A lot of work went into getting that leg design right. Using code worked out from earlier documents on avian bird styles of movement. But it lacked the weight aspect of the movement, even if the designed step animation absorbed all the weight shift, it was still missing the looks of 65Tons of machine placing it's foot down.

I do agree, the current animations need updating and tuning. Some physics added an weight implemented to the skeleton.

Just a short vid of working chicken walker legs, notice the torso doesn't move up and down or sideways, the legs take all the movement into the stride.
http://www.youtube.c...woFjzLZ5rQ#t=13

Now we just need the animation artists and engineers to build that into the movement.

9erRed

[Elizander]

I wonder what we can buy to make it more feasible for them to work on this.

[Cayp]

Thx for answering.

9erRed, on 15 September 2014 - 05:08 AM, said:

- Torso angle shifting, and hip angle all needing to be animated as well as the upper body movement adjustments.
- We had something similar early in the game and it made some Pilots 'car sick', so it was removed.

Looks like you are talking about pilots head-bob on every mech step. I wonder why it's not an option and was just removed so I'm now I'm just a floating head inside a cockpit jumping around me up and down. It was adding a lot of "feeling" the pace of mech and weight back in MW3.

[Kiiyor]

William Mountbank, on 14 September 2014 - 05:46 AM, said:

Dynamic in game Inverse Kinematics isn't that hard, it always looked beautiful in the Soul Reaver games back in the 90s.

In MWO all the mech meshes will have IK skeletons anyway, because it makes animation easy and more lifelike than keyframing the bare vertices. If you have a physics model that can take the IK skeleton, and use it to adjust the angles for some of the joints, then you can have realistic gait simulation in real time. I guess the problem is that with a server authoritative game, it's the server that is doing all the skeletal animation work, and dynamic IK is probably a resource hog or lag generator - particularly if the game engine isn't optimised for what you're trying to animate and serve to the clients.

TLDR: We won't get back legs that conform to terrain. Not soon, not ever.

This is true.

Also, while there are many posts discussing previous games running fine with this level of detail, I don't think they were running fine in multiplayer. Not with this level of detail at any rate.

Some of the dev posts on this recently have been very enlightening.

Someone was questioning HSR, and used CounterStrike as an example. "If CS can get HSR working, how can it be so hard for a game that is far more modern?"

The answer was the sheer number of things that can be going on at once. Look at the Nova. If it fires 6 lasers, that's 6 separate calls to the server, per tick, over the entire duration of the beam. If it fires 6 lasers and 4 MG's, that's 10 calls. Already, with one mech, the game is more expensive than a 4v4 match in CS, with all players firing SAWs at the same time. Now, add a potential 23 other mechs into that, because a longer TTK than CS means that is very likely that a large number of mechs could be firing at the same time. Also add component destruction - you're hit in CS, you're probably dead. In MWO, there is different damage being done to dozens of locations, internal and external, over an extended period of time. The server is also calculating different levels of weapon damage over falloff ranges. It's working out if damage is reduced because of water. It's calculating heat levels for every single mech. It's working out which mechs are covered by ECM. It's working out targeting ranges for every single mech. It's trying to keep track of what every moveable part on a mech is doing, and is relaying that information to everyone that can see the mech. It's altering the trajectory of dozens (maybe even hundreds) of LRM's at the same time. If someone throws a fist-full of SRM's down range, it's calculating trajectories for every missile, as well as max ranges and weapon spread. Hell, i've seen limbs removed from mechs in video that friends and I were both recording, that looked exactly the same. That means that the server is handling the physics of falling pieces of robot. Madness.

I can see why things like this were cut back on. I imagine the breadth of the problem became more and more apparent as HSR started to be refined.

I'd love to see kinematics make a return, but not if it costs me any of my ability to actually hit what i'm shooting at.

[r4plez]

Better animation for legs? And where is profit from that? Ergo better not expect this from PGI in near future..

[Cayp]

Kiiyor, on 15 September 2014 - 06:17 AM, said:

That means that the server is handling the physics of falling pieces of robot.

Is that so? You sure?
Then why physics of falling pieces of robot can be calculated on server side and legs cannot?!
(I think that now pieces just released free from animation to client side physics calculation, like dead mech bodies)

When comparing CS to MWO, didn't we forget that CS is 14 years old? There was no technology development during last 14 years?
Why don't you compare MWO to Battlefield 3 or 4, where every trajectory of bullet is calculated, almost hundred players playing online on one map, half of the level can be destroyed, the game itself much more intensive and tanks, heli and etc there have different body parts like mechs in MWO?
Are they suffering from poor hit detection into different parts of body? Are they suffering from heavy network load?

There is nothing so hard in all what you have mentioned for convenient servers and networks.