|Engine Module Type String||Animator|
|Module Type Usage||Single Type|
Animator modules enable the Drag[en]gine to apply animations to game models. Animator modules are Single Type modules since only one can animate objects at the same time. You can use though for different games different Animator modules if you like. This module is not the most important one since the task is rather well defined and small in size compared to other modules. Launchers usually do not download Animator modules on their own since games do not request them.
Since the task of an animator is rather well defined and small you do not have to worry much about picking the right module. Usually it's best to pick the one with the most supported features. Speed is usually not a concern since other modules like Graphic or Physics modules suck up most of the speed on the their own. Chances are that in the future some parts of animations can be moved to external cards but so far animations are pure CPU.
Animators are objects capable of producing an animation state for a component. Every animator composes of a set of rules and controllers which indicate how the final animation state is produced from a set animation. Some rules can also produce animations without the help of the animation but external informations like for example where another object is located or a reference state captured before. Controllers provide the values required by rules and one controller can be attached to more than one rule. Every animator is coupled to a component. More than one animator can act on one component one after the other if complex animations are required that can not be done using one single animator. Animators can not be used at the same time as a collider component if the rig of the component is driven by physics. Animators can though be used if the rig is kinematic. The animator object has peers into the animator module. This way the creation of animations can be accelerated if possible.
Animators store 4 kinds of information to produce animations on the fly: an animation, a component, a list of controllers and a list of rules. The animation object is the source of animation data that can then be mixed up with itself or procedural content. The component is the destination where the produced animation state is applied to. The others two are the main work horses so they get a longer description. In addition each animator has two blending factors: source and destination. If we say the produced animation state is 'A' and the present animation state in the bound component is 'B' then the new animation state stored in the component is 'A'*sourceFactor + 'B'*destFactor. Hence you can use more than one animator to blend together multiple animations.
The controllers are your puppet master controls which which you influence the production process easily and quickly. Every controller has a value range and a current value. This is like a scrollbar in an application which has a minimum, a maximum and a current value not lower than the minimum and not larger than the maximum. You are free to chose any boundaries for a controller that match your script. The animator module does the normalization itself so you do not have to do this task on your own. The range can also be 0 if this is required which makes a controller practically static. In addition a controller can be frozen. If a controller is frozen all changes to its value parameters ( minimum, maximum, current value ) are rejected. Hence if you need to freeze your animation at some point you can simply freeze the controller for it without having to alter your code. An additional clamp flag indicates how values beyond the range are handled. This is useful if your controller represents a time value for example. If you have a looping animation you would set clamp to true which wraps the value around on the boundaries. If you have an animation that plays once and then stops you set clamp to false in which case the value below minimum are set to minimum and values above maximum are set to maximum.
Rules define how the final animation is produced using controllers to vary the result. The power in this system comes from the rules and therefore they are subclassed to provide a growing set of animation production tools. Some abilities are common to all rules. Every rule can be disabled which removes it from the production process without having to really remove it. Furthermore each rule has a list of bone names. If this list is empty the rule operates on all bones in the component. If one or more bone names are specified the rules operates only on the bones with the matching names. This way individual areas of the body can be animated without influencing others. Like the animator the rules always have a source and destination blend factor. They work the same as above just with the state the rule produces and the state already produced by the rules before. In addition you can assign a controller to either one of the blend factors so the value is taken from them.
See the following classes to get started with Animator modules.