About Inverse Kinematics
Why a tutorial about skeletons? we all use them, aren´t we? well, what i think is that we are used to the way they behave but not fully understand the concept. Is true that if you have been dealing with character animation you are going to be familiar with this tutorial but sure many things get clearer after. If you are a beginner with skeletons, much better. My only recommendation is, read it.
A hierarchy is one of those common words but i prefer to throw a definition so we all talk about the same thing. A hierarchy is just a method of ordering information (for example, geometry nodes) in a way that we take advantage of successive transformations down the structure as well as a proper ordering method. And yes, there are other methods but is not here the place to discuss data handling techniques, if you are interested you can read about that in any good C, C++ book or data handling algorithms books available.
When we talk about hierarchies we are talking about the parent-child relationship, that is defined as one parent, many childs. This means that every child has only one parent, and the structure grows in a “tree” manner.
As you can see cube 1 is the parent of cube3, cube 5 and cube2, and at the same time cube 6 and cube 4 are sons of cube3, which in fact is also a parent, so cube 1 would be the grandfather of cube 4. We use to talk about levels instead.
One of the most important issues in the 3D world is the selection and transformations tasks, we use them like one billion times a day, so better tools, much easy, straight forward and more important, less errors. If you see carefully you will realize that the nodes are the 3D objects, and that there are several colors. First, the black color which are the unselected objects of the tree, second, the white cube10 object and thirth, the grey cube7 and cube9 objects.
This coloring scheme represents how the transformation will be applied, meaning that if you are going to run a transformation this is going to be on the white element and those sons are going to receive the transformation by heritance. This means that any transformation applied to a node is traveling thru the tree structure down and the rest of the objects follow.
One important bit is that if you want to manipulate only the cube 10 but not their sons (down structure), Softimage has the ability to compensate these transformations in the inmediate sons, so nothing is traveling thru the structure.
Remember then that the way you select has tremendous effects in the way you transform, and we should talk of node selecting and branch selecting, once you get used to that you will be able to take full advantage of the hierarchy system, specially to animate.
Let´s say you have this hierarchy, select cube1 and rotate it, take a look in the values of cube1, now take a look at the values of cube 3… yes, it is compensated, these are the beauty of maths in action, (+23) + (-23) = 0.
With the same hierarchy, select cube1 in branch mode (MMB) and rotate it, take a look in the values of cube1, now take a look at the values of cube 3… yes, it is not compensated, (+23) + (0) = +23
The values are transferred because there is a hierarchical relationship, if you cut the relationship, unparent cube 3 from cube1 you will see that the rotation is no longer transferred.
Why i explain this? because someone ask me once to my surprise “How can i see if there is a node keyframe or a branch keyframe?”, well, there is not different keyframes, but the hierarchy and how you transform, nothing else. At least in Softimage.
But let´s take a look at how internally is processing the information… now let’s keyframe rotations in cube3 and in node selection of cube1 let’s rotate again… surprise? no, the keyframe on cube3 is “blocking” the complensation so it is impossible to retain the compensation. This means that the software is updating constantly the database (the internal database of objects, materials, etc…) in a optimized manner (it does not update things that are not moving) and we can take advantage of this to block or protect objects from being moved. Yes, is somewhat rude because we are creating the memory structures for the animation as well as forcing the software to update them each frame, but, if security and consistence is necesary, it becomes a valid option.
Look at the next example to see it in action.
Currently all 3d software tool are built arround the concept of static hierarchy, that means that we can not change the order, position or the hierarchy in the animation, so the hierarchy is the same the scene. And more important, all the tools are created arround the idea that these hierarchies are static. So now is time to enter the skeletons itself.
Skeleton systems are a very special case of hierarchy that has defined the next structure Null + Bone + Bone + … + Effector, represented graphically like the next picture.
As you can see, in |XSI the skeleton system structure has changed slightly, the effector is now a direct son of the root, plus you can cut it and the system works, you even can parent (later i will explain about the Force IK switch) and it works. Anyway, what is important now is that the in the case of skeleton systems the bone hierarchy is limited to one parent, one child. Second, and more important is that we have to think in the first bone of the system as the first IK element, so all the data is stored there.
Softimage XSI peculiarities
Well, there are several important issues i would like to comment about how skeletons are designed, because they have great potential in many areas but if you don´t understand them well probably the end will be a disaster.
This is quite obvious but still want to comment that if you start to draw the skeleton in one viewport you are at the same time defining the orientation of the whole system (rotating it), and it is very easy to cheat later, and i mean move/rotate/scale the whole system after it is drawn, and yes, you can do it, but i strongly recommend to work in a clean manner, drawing it correctly and orient it correctly. But what is correctly? easy, as Softimage draws the skeleont as a YZ plane, you should draw it on the YZ plane, which is the right viewport. In the case of a character, take the character as a reference looking at Z+. Keep in mind that the first definition of an skeleton system is very important, the software is relying on this for many calculations.
Just to say that the size of the skeleton is not important at all (if you don’t go for something aberrant of course), just try a comfortable size where you can see the bones grossor.
Binding envelope and skeleton structure
This is much much better than the old Softimage|3D method, partly because it does not implies that the object is going to be in the deformer hierarchy, something we learnt to live with but very anoying. Right now the objects are just linked and you can dispose your character geometry in a structure as you want.
Scale vs Length
You are going to find in the property editor a “length slider”, which affect the selected bone redifining its length. This is very different from applying a scale operator on the X direction. First of all, keep in mind that the scaling afterwards is a postdefinition process that can be helpful in many ocasions, but it is not the proper way to make the skeleton longer.
Is interesting to say that it works in a slightly different manner than the old Softimage|3D, because the scaling of a bone does not imply that you are scaling a child because it is compensating (remember?), but if you do a branch select it will be. Also, as the effector is not under a bone, it is not receiving any of these transformations which is not only faster and cleaner, but very nice.
This is something i really love, and to my joy, the guys from Softimage take the correct approach and defined this parameter per object instead than per scene (old method forcing to have all the scene working on softimage scaling or classic scaling).
The forward kinematics is the type of transformation heritance i was talking about before, which means that the transformations applied to one bone are flowing down the hierarchy, but in the case of skeleton systems we have to talk more specifically about Rotation transformations, which is what we are interested in. Later i will discuss the Scaling and Translating case in this kind of structures. In a skeleton system the hierarchy is not only a way to store/handle data, but the ultimate purpose of the technique.
But i want now to introduce how the centers are created and what can we expect from them, their behaviour as well as how to take advantage of this invaluable way of work. If you pay atention you will see that the centers of the bones are aligned to the bone itself, well, this is not exactly correct, the centers are the bones, the graphic of the bone is just that, a graphic to make it easier and more confortable to work, but you should take care about the concept itself.
Well, the famous and infamous Inverse Kinematics, or IK for short… Let’s take a look at the behaviour, so we can then start to think in the way Softimage aproached the skeleton problem.
But one of the very intersting things that happens in Softimage|XSI is that the centers are realigned to mach the proper position, making the whole system previsible and clean. Sorry about this comment but i am not a fan Maya´s IK system for specially for this and other things like this that only make things confusing and obscure.
Interestingly the bones are affected by the effector, this is due to the internal IK solver that is recomputing the chain to mach the solution you are looking for each time you move the effector.
Well, your next question is, “the more bones the more solutions?”, and the answer is yes. Probably the next question will be, “How the software finds the proper solution?”, well, that is different, it comes from the very basic coding of the Softimage|XSI solver that everytime you move the effector is looking for the solution starting the computing in the first known pose of the system, so, if the way you drew the skeleton system in the beginning is slighly concave, all the solutions offered are concave, which is just great.
Actually, in Softimage|XSI there are 2 solvers, the standar Softimage|3D solver and the new Softimage|XSI solver, which as far as i know is more accurate, but what we are looking for is the Solver Angles computation method, based on the Joint Rotations of the first pose (ala Softimage|3D) or the new method Reusing joint rotations at every resolution step. This will drive a different behaviour from the explained before, giving you, once in the longest position available to go for the other solution. Also you could specify a per joint prefered rotation angles…
2D and 3D chains
I have been all the time talking about 2D chains, mostly because it is quite rare to find an aplication for 3D chains, anyway, the only difference between them is that 2D chains are computed in the plane defined when drawing the skeleton system (plane XZ from the first bone) while the 3D chain is computer for an infinite number of planes. Useful for springs, chains, cables, and other stuff…
Yes, the skeleton systems has some drawbacks which i will try to enumerate and explain so you can have that in mind when designing your skeletons systems for you character.
The critical zone is the are near the root that, due to the limitations of the processor numeric accuracy and the software implementation we have to handle. Those areas are a strange case where the solution offered can not be very stable and produce some kind of jitter/jerkyness. This, as many Softimage|XSI parameters at the beginning can be difficult to find because they are properly organized, yes, i said properly, the critical zone visibility switch is under the camera properties, not under the skeleton.
Perfect rotations (rotula)
Something i am concerned when designing a character skeleton is that our rotation points (knees, elbows, wrists, heels, etc…) are not ideal pivots, normally there are slight translations asociated, and specially in the case of the shoulder (by far the most complicated thing to handle) this is specially true. But this is the price we have to pay to simplification and idealization when transporting very complex systems into the computer. By the way, there are several tricks to avoid perfect dumb rotations.
homogeneous vertex deformations
We are using this toolset to deform a bunch of vertices arround a known center (the bone center), till here sounds good, but why there is not any implementation of 3 diferent rotation behaviours? Again, we can solve this with some tricks, but we can start to see that this is a pretty basic tool when trying to imitate real life skin deformations.
skeletons vs Muscles
When copying nature we are always to loose, it is so complex, beautifully built and subtle that is really hard to construct a believable arm sytem, with the muscles, tendons, bones, veins, fat and skin. So keep in mind that we are dealing with a very rude representation of a ultracomplex system so don´t expect too much.
Now let’s take a better and more careful look at the same animation, because i would like to show you several things.
First, notice that there are to main areas, the yellow and the pink, that basically means that there are to goups bones and the vertices belong or are influenced by that bone in a given percentage (the software tries its best but usually is not usable).
Now look at the center, you can see like a blend of colors, which means that those vertices are influenced from both bones (each vertice factor influence is determined thru a simple distance algorithm although Softimage|XSI can perform a second method based on distance and normal orientation).
Second, now take a look at the deformation on one given point, you can see a perfect arc described by each 100% assigned vertex arround the bone center. Thirth, now take a look at those vertices in the center area, as you can see those are moving too, slightly, but moving.
Now let’s look a little bit in the internal processes that Softimage|XSI is doing. I want to add this note so you can realize what you can do with this new generation tool, but specially how flexible it is.
Supose that i modify the position of some vertices, trying to tweak my model after the skinning process has been done, this is what you will see.
This is happening because Softimage|XSI uses a very advanced architecture that stores in each object all the operations you are doing on that object and the order of those operations are vital. But the beautiful part is that you can reorder the operators after those has been created simply by drag&drop.
You probably will notice that the translation is not exactly straight, well if not, take a second look at it… okay, this is because first the vertices are rotated arround the bone, and later they are translated, creating the false effect of an additive offset.
Of course, this level of flexibility has a price, sometimes you can miss something and things become quite complex to understand, i recommend to calm down and analyze what is happening with a simple laboratory scene. If you find yourself that the software is becoming somewhat slow, try to optimize your scene, and study the software so you can take advantage of it instead of fighting with it, Softimage|XSI is not slow, in fact, is extremely fast for the kind of architecture it has but is true that if we mess up things become slugish.
Uses and tricks
It is interesting to take advantage of the skeletons systems, the main purpose is deform geometry in the animation, but you could use them for other purposes;
- You can use the skeletons to model/distort the geometry.
- You can use the skeletons as sliders.
- You can use the skeletons to measure distances.
- You can use the skeletons to move/animate the camera making some complex movements easy.
- You can use the skeletons do some simple cloth simulation.
- You can use the skeletons to control lights position and orientation, racks of lights, groups of objects.
- You can use the skeletons help the selection of things blocks of objects.
- You can use the skeletons to build any double pivoting tools.
Well, hope you enjoyed this loooong tutorial about skeletons… i think it can help… if not, just forget it.
2 Responses to “About Inverse Kinematics”
Leave a Reply