|
Animating The Inanimate, Part Four Page 2 of 2
Philosophizing bones Before I move ahead and go about pontificating on where to place Ralph's bones in relation to his body, here's a quick word about what could be described as the philosophy of bones. By definition, in order for bones to do anything constructive, you must have at least two of them. Picture this: I'm assuming most of you have both an upper arm bone (Humerus) and two lower arm bones (Radius and Ulna). For the sake of this discussion, I'm going to combine the two lower arm bones into a single uber-bone, which I'll call the Ulnius. By itself, the Ulnius wouldn't be doing a whole lot in terms of moving your forearm if it didn't have the Humerus to anchor it and hold what's around it in place. But since the Ulnius is attached to the Humerus, two things happen. [an error occurred while processing this directive] First, the skin surrounding the Humerus won't be dragged limply along by moving the Ulnius, since the Humerus is the bone that influences the skin around it. That's good, because the thought of boneless human skin being dragged limply along isn't a particularly pleasant image. Second, the Ulnius/Humerus hierarchy and the influence each bone has on the skin surrounding it means that your arm is capable of many different positions just by moving the Ulnius, and even more by combining movements of both bones. The long and short of it is that you need two bones to get anything to move the way you want it: one anchors, and one moves in relation to it, each influencing the skin around it. Of course, this concept can be expanded; again, just look to your average human bone structure for countless examples of parent/child bone relationships. However, there's a twist here. Bones don't necessarily have to be set up in a parent/child hierarchy. As long as a model has at least two bones, they'll do their thing without having to be connected as parent and child, which I'll show in a minute. Let's move back into the virtual world and apply this principle to Ralph. If I were to place a single bone into Ralph's skin, it won't do me much good at all. Figure 5 illustrates what happens if I place and rotate a single bone. Not too stellar there -- I might as well just be moving Ralph's vertices and stuff directly without all this bone garbage. However, if I add a second bone as a child bone of the first, the way I did in the bone-adding example earlier, I've now set up a hierarchy of bones that each influence a section of Ralph's body. Figure 6 shows what happens just by rotating the one child bone, at which point I'd be inclined to go out on a limb (no pun intended) and say that the results are a whole lot better than my first try.
Actually, this little sidebar on the philosophy of bones has gotten me most of the way to where I want to go with Ralph in terms of how to set his particular bones up. Using just two bones, Ralph is pretty much at the point where I can do what I need with him by moving his two bones (coupled with the rotation of the base and the squashing and stretching I alluded to before). However, the bone placement isn't all it could be -- Ralph's movements look a little funny, and it's hard to get some of that cartoony exaggeration of movement I'm shooting for here. Besides, who says the bones have to be connected like they would inside a flesh and blood human being? I can create two parent bones for Ralph instead of having a hierarchy, both of which I can turn their respective sides so they serve as virtual handles that actually protrude out of Ralph's "back" (fig. 7). Why in the name of all that is good and holy would I want to do such a thing? Actually, the reasoning is pretty simple, as I'll now elaborate on by giving you yet another long-winded example.
Imagine Ralph were a real peanut, except picture him being about a 18" tall and made of soft plush material. Now let's imagine that my hands and arms are invisible. What would give me the best range of movement considering what Ralph needed to do: controlling him from the inside like a puppet (like I originally set him up) or just grabbing his upper an lower halves and manipulating him directly from the back? In Ralph's case, I chose the latter. Ralph needs side-to-side and up-and-down "head" movement, so the most direct thing to do (again, were Ralph an actual object and my hands invisible) is to steady Ralph's lower half with one hand and move his upper half with my other hand. This is pretty much what I'm doing by making two parent bones and turning them on their sides. Figure 8 shows Ralph in all his rendered and composited glory after I've animated him in two quick shots (falling, getting up, and hopping) for one of his spots, and he's doing some pretty complex movements for only having two bones in him. Keyframing the rotation of both the lower and upper bone, combined with some strategic base rotation and a little bit of squashing and stretching made Ralph able to do all the things the scripts asked of him.
As you move ahead... Keep in mind that what I've shown here is barely scratching the surface as far as bones go. I'm shallow like that. Obviously, you can have any number of bones controlling any number of models with ever-increasing complexity. Bones usually also have controls such as user-definable influence spheres, weight mapping, muscle flexing, integration with IK systems, and sometimes even vertex-level accuracy, just to name a few, so check your 3D program's documentation on what's available to you. When not fleeing the paparazzi or spending his vast fortune associated with the fame and notoriety of being a DMN contributor, Kevin Schmitt can be found with his eyeballs glued to his computer screen, attempting to use some of the hardware and software he rants so incoherently about. An award-winning animator, artist and multimedia producer, he is currently a freelance designer located in the enormously bustling megalopolis of Charlottesville, VA. Whether you're looking to "give him the business" of either the figurative or literal type, feel free to drop him a line. He's ready to believe you! Prev 1 2 [an error occurred while processing this directive] ![]() |