 The brain works in strange ways. If you give me a movie reference I can usually not only give you the name of the movie, but also the director, several actors and possibly a few other members of the crew along with some other movies they worked on. On the other hand, ask me the location of a random Dutch city and I will only be able to give you a vague approximation, possibly landing you in the middle of nowhere with, as John-Pierre (AKA Sarix/3state AKA one of the co-coders of "Melrose Space" AKA one of my friends) would say, a cow mooing up your ear. It seems that your brain will store just about anything you throw at it, but it only retrieves the stuff you find really interesting. Buzzwords work the same way. Whenever some pony-tailed Texan says he's working on a new engine featuring <buzzword> you'll see a lot of people going "Wow! <game> will be really good because it contains <buzzword>!". Invariably, after people figure out the buzzword, it becomes less relevant (because it's less mysterious). One of these buzzwords was, and actually still is, "Skeletal Animation" (and also "Skinning", "Bones", etcetra). Actually, it's not particularly complex. That is why I will explain it to you in a tutorial I like to call: SKELETAL ANIMATION FOR DUMMIES ...which is actually a horrible pun. You see, *you* are in control of the figure you're animating, just like a ventriloquist controls his wooden puppet, which we call: ...exactly. I will now refrain from any more of these awful puns. Anyway, this tutorial will also stay away from specific implementation issues since the implementation of skeletal animation probably varies from program to program. Still, follow these guidelines and you should be able to build a reasonably bonafide (groan) system. DAMMIT, JIM! A skeletal animation system is based around bones. These are basically what 3D Studio would call 'helpers'. They basically consist of a position and a matrix. The first thing you should be able to do is animate them using normal object hiearchy. Storing your objects in an intelligent fashion (such as a tree) is therefore a real bonus (sorry). So then, you've now got a couple of helpers moving and rotating and generally making idiots of themselves. What you want to do now is attach a mesh to these bones. UNDER THE SKIN (OR ANOTHER STUPID SKIN-RELATED SONGTITLE) Skinning, in its most basic form, is the process of taking a mesh (of a baby, for instance) and attaching every vertex of that mesh to one of the helpers. So, vertices 0-300 may be attached to "BoneLeftArm" while vertices 301-477 may be attached to "BoneSphincter" and so on. This data can be exported from the modelling package. Once you've attached these vertices you should then use the bone as the pivot point of the vertex. So, if you rotate "BoneLeftArm" then vertices 0-300 will also rotate in the same direction. The same with movement. And that's all there is to it. Too bad it looks really crappy. To still make sure it sounds really cool and mysterious, people also refer to this as (buzzword) "Rigid Non-Blended Skinning". ANY OTHER IDEAS THEN, WISEGUY? Why, yes. Your dancing baby will look considerably better if you use (buzzword) "Vertex Blending". Yes, this is (buzzword) "Rigid Blended Skinning". Basically, it means that your vertices are not connected to one single bone, but to *all* bones at once. Every bone will then have a certain "influence" on your vertex. So, a bone really close to your vertex will have a lot of influence whereas bones that are not, won't. These influences can be calculated, but usually they can be exported as well. This will look considerably less crappy. Any more? I HEARD YOU WERE DEFORMED Sure, there's always a better way to implement something. You may notice that in my description of the two methods of skinning I was talking about "Rigid" skinning. There's also "Deformable" skinning which uses slightly more tricky calculations for enhanced realism. As a demoscener I don't need that. If you really want that kind of detail I suggest you fake it by simply letting your 3d-package calculate it all for you and you just export an animated mesh. Tons of people do it, including certain Texans. I don't use animated meshes for the simple reason that, whenever we have skeletal animation, we have busloads of keyframing that I *really* don't want to store on a frame-by-frame basis. You're not allowed to enter 30mb demos at parties, you know. SO THERE YOU HAVE IT Indeed. I was planning one last pun, referring to the fact that you are now "completely boned up" on the subject, but I realized it could get a little embarassing. I won't make that pun, then. So, another of the buzzwords is completely demystified. That's nice. Now if only someone could demystify this whole space/time/relativity/wormhole/quantum-mechanics stuff to me I'd appreciate it. 
|
