A little planning... (Animation and Costumes?)
polycounter lvl 17
Seems I am going to have to learn how to animate bipeds soon. Luckily these are low poly assets so there won't be TOO many verticies to wrestle with, but I suspect it is harder than the pros make it look.
This said, I am trying to wrap my head around a certain pipeline or order of operations.
We are working on an XNA game. The heads of the avatars are going to snap to a NULL on the body. This way we will only have to animate the body and they can change heads all day. The problem is with clothes.
Even in WOW there are LOADS of new costumes. Now, I realize more than half of these combinations are simply new textures over an already existing mesh. But what I can't seem to come to terms with is how they link so many of those meshes to a pre-existing animation? Wow is a good example, but I know darn-near every game does this some how? And, I can't believe that they remake the animation for ever new shirt, robe, or pair of shoes (people would notice that he runs different depending on what he is wearing).
So, I am not sure -what- I need to ask that I haven't. Tutorials are great, but theory is even better.
Thank you for helping this little-fish.
-Andrew
This said, I am trying to wrap my head around a certain pipeline or order of operations.
We are working on an XNA game. The heads of the avatars are going to snap to a NULL on the body. This way we will only have to animate the body and they can change heads all day. The problem is with clothes.
Even in WOW there are LOADS of new costumes. Now, I realize more than half of these combinations are simply new textures over an already existing mesh. But what I can't seem to come to terms with is how they link so many of those meshes to a pre-existing animation? Wow is a good example, but I know darn-near every game does this some how? And, I can't believe that they remake the animation for ever new shirt, robe, or pair of shoes (people would notice that he runs different depending on what he is wearing).
So, I am not sure -what- I need to ask that I haven't. Tutorials are great, but theory is even better.
Thank you for helping this little-fish.
-Andrew
Replies
Animation data is stored, saved and can be loaded into most skeletons. 3dsmax has biped that imports several types of animation. You can also save/load .xml animation onto any kind of object. (File > Save/load Animation)
Some games use;
- A ref file, which includes the skeleton and the base mesh. No animation data.
- A ref file, for each armor set/piece, but are only those objects by themselves along with the naked skeleton. Again no animation.
- Then animation files are saved out and through the magic of code are all combined in game.
Most decent game engines with bone-based animation will let you apply any animation to any skeleton that has the same number of joints - usually the joints have to have the same names too.
So in theory you should be able to export "run_cycle_1" to a basic skeleton, and then skin any mesh on to that basic skeleton, and use "run_cycle_1" on those meshes by telling the game engine to do it.
You mention XNA, and also mention "null" points to snap to - I assume that means you're preserving the bones in the game engine, rather than just "baking" the animation? If so, you should be able to do this without too much trouble, it's just a matter of pointing the meshes to the animations (might wanna get a programmer to help you do this, if there isn't a good pipeline for it yet).
As an artist, the most difficult part could be the skin weighting to make all those mesh objects work with each other without horrible intersection. You may end up with a single master file that has dozens of separate bodypart components that all work together.
However, most people consider that to be the "bad-old-way." As you can imagine, storing animations in this fashion made for some ridiculously bloated model files. It also made it nigh impossible to make animations interactive. Animations could be very creative, but at the same time they were always completely static. They were also not reusable.
These days, models are exported with the bone references and weights of each vertex. In this way, you don't need to export the rig along with the model, but can export them separately. In fact, the rig, as it pertains to game engines, is a very abstract concept. The "skeleton" that most of us work with in programs ceases to exist when you export the model. Animations are exported as relative positions, and their transformation data over time. Models are just verticies, faces, and normals with bone references and weights. You never actually export a concrete skeleton "file." Just animations that then get applied to models.
That's a lot to take in. In addition to what others have said, I have a deeper understanding of how it is done nowadays; now I will admit that I lack a good primer on -how- to do these things, but I think it important, to -me- anyway, that I understand the whys before they hows.
I suppose I should look for tutorials on how to use bones (or is biped better) with my lowpoly models.
-Andrew
As for the how, that's where the line between programing and art starts to get a bit fuzzy. A lot of the how, is dependent on what engine and what file formats they plan on using. Those are normally dictated by a chief code monkey. Sometimes it requires you to create complicated text files so the engine can read in the files correctly, some times that's done for your by the exporter.
It all depends and there isn't too much vague info that applies across the board. =/
You build a model and drop a skeleton in it. There are various ways to do this in different software, but all will have great step by step tutorials.
You then skin or bind the model to the skeleton. In Max you'd use the skin modifier to do this, or possibly the Physique modifier.
At this stage, when you move or rotate a bone in the skeleton then model will follow, and depending on you software and game engine you can export this asset to the game.
The animators will then animate this asset, however what they are animating isn't the model, it's the skeleton. They could animate the skeleton with no model existing, but having the model there makes it much easier to see what is going on.
At this stage you have 3 things: an animation that drives a skeleton that deforms the model.
Now, you build a second model, and drop in (an identical) skeleton and skin it up. The animations created for the first model should also work on the second model.
The clever stuff that you want to do will require some programming, but I've worked on two games that have done this. What you do is exactly as you mentioned in your first post - you build a bunch of heads and bind them to the skeleton, and you build a bunch of torsos and bind them to the skeleton, and you build a bunch of legs, and bind them to a skeleton - in effect rather than building a complete model, you build it in bits. Once it hits the game the coders figure out a way to swap the various body parts in and out, in the same way that they can swap textures.
I am glad I saw your post. I just had that epiphany. That you can use 1 skeleton, and drop it in multiple characters (I assume it can be saved in character studio as well as its animations); what is most important to the engine and the programmers (if I understand) is that the names and number of bones are the same per character.
From there, the weights that the verticies have TO the bones are part of the exported mesh and the the exported skeleton.
Am I getting this right?
I am going to read the tutorial here:
http://creators.xna.com/en-us/sample/skinnedmodel
and hope that they get around to some of this theory.