Welcome, Guest. Please login or register.
April 25, 2024, 09:05:26 PM

Login with username, password and session length

Search:     Advanced search
we're back, baby
*
Home Help Search Login Register
f13.net  |  f13.net General Forums  |  The Gaming Graveyard  |  Game Design/Development  |  Topic: MoCap - Why isn't it used more? 0 Members and 1 Guest are viewing this topic.
Pages: [1] Go Down Print
Author Topic: MoCap - Why isn't it used more?  (Read 4114 times)
SnakeCharmer
Terracotta Army
Posts: 3807


on: March 04, 2008, 06:25:28 PM

More specifically, why isn't it used more in MMOs?  Wouldn't you save money by the truckloads in terms of animator costs?  It seems to be it would be an invaluable tool in game development - and not just in MMOs.  How many animations could be 'filmed' in a week that would take a crew of animators months to do?  Everything from an NPC just milling around, or a PC shifting their weight on the balls of their feet, nevermind combat animations such has going from run to kneel, or changing directions, that sort of thing.

The last MMO that I can think of that had/has realistic human movement was SWG, and it came out nearly 5 years ago, not to mention the 5ish years of development it underwent.  Did it have the benefit of Lucas Arts mocap studios?  EQ2 has some pretty decent animations, but no where near the quality of SWG - at least until SOE removed the fluid movement of preCU SWG, and put in the snappy movement right before CU.  Hell, I can't think of a game that had as fluid of combat animations as SWG, again preCU.

Is it really that cost prohibitive?  You don't even need actors, just devs to suit up and run around like chickens.

Moving a bit forward in immersion, how far away are games away from the environments and avatars being truly interactive?  Hurdling a rock or fence, proping a foot up on a small rock or box. 

I guess I am just wondering how long until stickish animations are replaced by truly athletic, fluid ones.  CoD4 has some fine avatar animations to be sure.  As did Rainbow 6: Vegas.  But it still left me feeling a bit blah.  MMOs are even worse.

Maybe I'm not playing the right games, and I realize it's harder than it sounds.  But avatar movement doesn't seem to have advanced much at all in the last 5 years. 
Kail
Terracotta Army
Posts: 2858


Reply #1 on: March 04, 2008, 07:18:45 PM

You don't even need actors, just devs to suit up and run around like chickens.

You do need actors if you want it to be any good.  You can't stick sensors on Brad McQuaid, translate that into a computer, and expect to get a menacing ogre on the other side, it's really not that easy. And you're not just adding an actor, you've also got to have people trained to operate cameras, set up lighting, you've got to train your animators, pay for equipment, and so on.

I'm personally of the opinion that a lot of games should be moving away from motion capture.  Probably the biggest offender I've seen here is Sega (I haven't played any of their recent stuff, so this is all circa Sonic Heroes), where they use motion capture for every goddamn thing, from Shinobi to Phantasy Star to Sonic Adventure, and it looks universally awful.  Motion capture takes the movements from a real live actor, which is fine when you're trying to animate something a real live person would do, but it's hard to do well when you're trying to animate something inhuman or superhuman.  So when Hotsuma in Shinobi jumps a thousand feet up in the air in a cinematic, it looks like a guy doing a bit of a hop and then the ground shoots away from underneath him, for example.  It's horrible.  I'd say it would work for things like Rainbow Six or Call of Duty or something, where you're rendering primarily realistic environments, but MMOs are typically not very realistic.  I hit you with a battleaxe, you don't jump a bit, go "ow" and loose six hit points.  Especially when you've got races with odd proportions, like in Warcraft your Orcs and Gnomes and Dwarves and Trolls and Tauren, motion capture has a lot of difficulty translating a human's movements to skeletons that don't match a human build.

Plus, the problems you're describing don't sound like they'd be fixed by using motion capture.  I haven't worked with mocap, but I'd assume that things like animation transitions and environmental animation would be more trouble to do with motion capture than with traditional animation.  As far as I know, character movements are handled as a series of discrete animations or animation cycles.  If you're running, the game will play PC_run_anim or whatever.  When you stop, it will play PC_run_stop_anim or something.  It doesn't matter if you're using motion capture or not, there's going to be a skip between those animations.  And if you want characters to be able to react realistically to their environment, if you're doing that with motion capture, you've got to load a TON of data for all your possible animations into memory, and even then it's not really feasable to capture data for every possible movement the player can make.  I'd say a better route would be something like procedural animation, where you've got a set of rules in place as to how a character moves and the computer animates your character according to those rules.

And there's also the problem of control.  If you press the duck button, you want to duck NOW, you don't want to wait for your character to execute a realistic ducking animation.  Games with fluid animation tend to have floaty feeling controls, 'cause when we're moving around in real life we tend to prepare ourselves to move before we move (e.g. we crouch a bit before we jump), but the game doesn't know you want to move until after you push the button, so you either delay the action (push button, crouch, then jump) or you get a jerky looking character animation (push button, character flies into the air from a standing pose somehow).

Though, yeah, I am getting really pissed off at every damn FPS that comes out with super water shaders and light bloom and real time particles with characters with ten thousand polygons and full displacement maps, but still using the same basic animation system as Quake 2.  I'M LOOKING AT YOU, FUCKING UNREAL TOURNAMENT 3.
Sairon
Terracotta Army
Posts: 866


Reply #2 on: March 05, 2008, 01:42:48 AM

I've never used mo cap, but the sample rate you would need to use with mo cap would need to be a lot higher than for traditional animation. With traditional animation you can say "let this bone here move torwards this transform here using bezier interpolation over time", and then that transition would have "infinite" resolution. However with mo cap you don't have that sort of control so I'm guessing the use very high sampling and some predefined interpolation. This means you're going to get a truckload of data which can take a whole lot of memory. Also, unless you filter it in some clever way, you would miss out on potential performance.

Transition between animation is easily fixed with animation blend, which I think most games of today use. Using animation blend you get a pretty good transition between most animations, however it's totaly oblivious to the enviorment and external forces. What is often meant with procedual animations today is just having your physics simulation handle the animation data and blend it with your physics simulation.
Margalis
Terracotta Army
Posts: 12335


Reply #3 on: March 05, 2008, 02:35:14 AM

Motion capture for things like swinging swords around often looks really bad, in part because people really do dress up developers, give them cardboard tubes and film them.

vampirehipi23: I would enjoy a book written by a monkey and turned into a movie rather than this.
Trippy
Administrator
Posts: 23621


Reply #4 on: March 05, 2008, 04:57:31 AM

The thing about mocap is that you don't just capture some data of people moving around and then you are done. That's just the starting point. You have to spend time cleaning up the data since the data capture process is not perfect and you have to massage the animation data to fit into the game requirements (e.g. particular rest positions, looping movements and so on). Depending on what you are trying to achieve it doesn't always save you time and/or money or give the best results.

Switching over to movies, if you watch those special effects features on movie DVDs you can listen to the animators talk about the process. On the LotR for example, even though they mocap'd pretty much all of Gollum's movements via Andy Sirkas's performances what you saw on screen was a mixture of the mocap work and hand animation because that's what they felt gave the best results.

If you rely too heavily on just using the mocap work without having the animators spend a lot of time adjusting things or redoing parts by hand you end up with something like Final Fantasy: The Spirits Within which had a definite "uncanny valley" look to a lot of the mocap animation, which they used extensively.
slain
Terracotta Army
Posts: 1


Reply #5 on: March 05, 2008, 10:08:18 PM

Because not that many people know how to use the data correctly and when to use it and when not to.
The expense of Mocap comes from the gear, i.e.   A pro setup for a decent capture area is worth around 500 - 750 K,
then you have the techs to keep it calibrated and running, the actors at $500 - $900 per day (and yes you *need* actors unless you want dev spaz motion)
you then need to clean the  data to get rid of marker swap and occlusion errors, and filter out the inter frame  jitter. If you have ever done
this task you will know that it is like pulling teeth, 200 markers in a set at 120 hZ (fps) is a lot of animation curve data to sift through and
clean!

Having said all that, if you have decent actors you would be surprised what movements they can mimic given the right weighting to props
some foam paddign and sand bags.  Also typicaly you would downsample by plotting your captured data to a character rig before using it.
This will lose you some of the nuance you get from good data but at a realsitic sample rate for real-time. Also there is no reason why you cant blend mocap
with keframed or pose to pose data.     
Morat20
Terracotta Army
Posts: 18529


Reply #6 on: March 06, 2008, 10:25:07 AM

Motion capture is also a bitch to modify after the fact. Witness SWG's attempt to "speed up" movements. It looked like characters were having seizures at times. :)

Traditional animation means you can just go back to the tools and modify it, not drag in an actor and say "I want you to swing that sword again but faster, because we need to shave a full second off the total animation".
Trippy
Administrator
Posts: 23621


Reply #7 on: March 06, 2008, 03:40:27 PM

Once the motion capture data is put into the animation system it's the same as "hand" animation. That's just SOE's SOP to not care about the quality of that sort of stuff

EQ II had/has the same problem with its combat "running" animations where they just sped up the original combat walking animations instead of redoing the animation. In the original EQ II design when you were in combat you could only move at walking speed, this was to prevent people from running to zone lines and escaping death (the designers didn't like that "feature" in EQ).

Edit: sped
« Last Edit: March 07, 2008, 01:48:28 AM by Trippy »
Prospero
Terracotta Army
Posts: 1473


Reply #8 on: March 06, 2008, 08:29:51 PM

I still have nightmares about cleaning up mocap data. I wrote a mel script that helped simplify things a lot, but it was still a lot of tedious handwork. It definitely seems like the way to go for things like gymnastics or martial arts where there are a lot of subtle movements. I don't think mocap is a good fit for stylized animation; it seems like something like TF2 would be a bad fit for mocap.
DarkSign
Terracotta Army
Posts: 698


Reply #9 on: March 21, 2008, 09:24:06 AM

This message spammed to you by www.truebones.com

 Oh ho ho ho. Reallllly?  Oh ho ho ho. Reallllly?  Oh ho ho ho. Reallllly?  ACK!  Oh ho ho ho. Reallllly?
Pages: [1] Go Up Print 
f13.net  |  f13.net General Forums  |  The Gaming Graveyard  |  Game Design/Development  |  Topic: MoCap - Why isn't it used more?  
Jump to:  

Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC