Character Animation Movement
Understanding Model World-space Movement
For many applications, it is sufficient to let HeroEngine animate models as if they were stationary. HeroEngine can then move the model around the world however it likes, without actual position of the object (as seen from the server) changing, nor communicating about this movement in any way.
However, for realistic characters this method often becomes a problem. Since animation and the world-space movement of the model are not being performed together, world-space constraints of the animation may be violated. For example, if a character's foot is supposed to stay planted on the ground while he moves forward, the foot will appear to slip if the forward motion does not correspond to the animated flexing of the character's leg.
For applications where it is important to eliminate such artifacts, HeroEngine provides an option for coupling the world-space motion of the character (which is controlled by HeroEngine) and the animation of the character (handled largely by the animation data). This is called variable delta accumulation.
Furthermore, there are optional techniques that can be employed alongside VDA which may help simplify the animation process. The remaining sections discuss these techniques and when they can be employed.
Variable Delta Accumulation
Variable Delta Accumulation (VDA) does not require any special pre-processing during export. Animations are exported as-is.
The idea behind VDA is to play back the animation as you normally would, but instead of actually applying the root bone animation, you ignore it and apply its delta to the model matrix instead (in other words, it moves the character or asset instance directly). This is the exact opposite of CME: instead of having constant motion where the root bone is allowed to move around the model matrix, VDA has non-constant motion of the model matrix but keeps the root bone locked to its relative location from the character.
Move to Origin and the Synthetic Root Bone
Although root motion accumulation may sound relatively simple (at least the VDA type), there are many subtleties that can make it difficult to use. The reason for this is that animations are often ambiguous as to how they should be accumulated, blended, set up initially, etc.
For example, suppose I animate a character sauntering forwards such that their root bone turns from side to side as the walk progresses. If, in the middle of that animation, when the root bone was pointing, say, 15 degrees to the left, I transition to a standing-still animation, what should happen? Should the character turn to face forwards again, or should they remain pointing 15 degrees to the left?
The answer is, well, it depends on what the animator intended! But unfortunately, that information is not encoded in the animation. There is no way for HeroEngine to know. so it cannot just "do the right thing."
Here is another example: an animation with a character walking forwards has its root bone start about 3 feet off the ground. Another animation with the character climbing up a ladder has it start at the origin. When you play the walking animation, you want the root bone to stay 3 feet off the ground. But when you play the climbing animation, you don't want the root bone to snap down to floor first, and then climb. But there's no information in the two animations that differentiates between the two cases.
This is where the exporter Move to Origin (MTO) options and the concept of a Synthetic Root Bone (SRB) come in.
An SRB is a bone that has no physical analogue in a skeleton - it isn't the pelvis, the feet, the scapula. It is a bone that is created as a parent of what would otherwise be the root bone (usually the pelvis), and typically placed on the floor directly below the character. When animating, this root bone is moved to maintain its relative position on the floor to the character, and can even be script-driven in many animations.
The Hero Export utility has a button for creating a Synthetic Root Bone automatically for you. It will create the SRB and link it to the the first bone named "Bip01" (CASE SENSITIVE). This is what Biped calls it's COM bone, but it works with regular bones as well; just make sure you name the bone right (at least temporarily during the creation of the SRB, after that you can change it to whatever you want).
The idea behind the SRB bone is to encode what the animator expects to have happen regarding motion accumulation. Since the SRB is the root of the skeleton, it will be the bone that HeroEngine processes for motion accumulation. Thus, by having a separate bone that has nothing to do with the actual movement of a bone in the character, the animator is given the control necessary to directly specify how accumulation should occur.
Ideally, this bone should be placed at the origin of the world on the first frame of each animation. But this can be annoying for animators to have to do, as various art tool features may occasionally prevent this from happening. This is where MTO comes in. When you turn on the "Move to Origin" option in the exporter settings, the exporter will automatically re-align the animation or model to coincide with the origin, both for orientation and translation.
MTO has several sub-options, each corresponding to a translational or rotational axis that can be reset to the identity during export. Usually, you should leave all of them checked, so that models and animations will always be stored and processed in an identity reference frame. The Hero Export utility automatically selects most of these options correctly for you, so you don't have to worry about this.
MTO can be set under two different settings categories in the exporter: Models and Animations. Usually, you will want to turn it on in both, so that the root pose of the model and the start of the animation are both at the origin. However, if you have a specific result in mind, it can be convenient to disable MTO along certain axes. But, much more often, it is better to use the difference between the SRB and the actual root bone of the model to achieve placement rather than trying to rig MTO to only partially operate on your data. Again, the Hero Export utility generally selects the correct settings for you so you seldom have to worry about this.
Just in case it hasn't been stated enough - you almost always want MTO to be on when using motion motion extraction. The only cases where this is not true tend to involve bizarre animations or a group of objects that are all part of the the same animation (but in which case it's not entirely clear what "motion extraction" really means, except in really simple cases). So if ever you are tempted to turn Move To Origin off, resist! You are likely to just be causing problems further down the line.
In some cases, it is difficult to make the SRB be an actual bone in the skeleton, and one that is also actually the root bone. Sometimes it is easier to make the SRB be a child of the real root bone in the skeleton, or sometimes just a completely separate object in the scene. Some people like to have a "ground shadow" object, some like to have a "bounding box" object - conceptually, the SRB is the place and orientation where the game itself thinks the object is. In these cases, making it actually be the root of the object is tricky or restrictive. The solution in all these cases is to indicate that this transform or bone is the SRB by a naming convention. Simply have the word "SyntheticRootBone" somewhere in the name (any mix of upper and lower case - so "Bounding Box (syntheticrootbone)" and "SYNTHETICROOTBONE object" are both valid), and when exporting, HeroEngine will make that bone be the root of everything else in the scene, and do all MTO and motion extraction with that bone. This is how the Hero Utility sets up the Synthetic Root Bone, so by using this you are all set.
This concept also helps when using objects that have multiple root bones, or places where a conventional skeletal hierarchy does not work well, and instead many bones are not joined together, but free-floating (such as cloth and muscle animations). Using this naming convention, the SRB becomes a root bone to all the other bones (but only at export time), thus allowing code that uses a conventional tree hierarchy with a single root to use these animations just as easily.
How to use the SRB
Think of the SRB as your positional "key" in the animation. It represents where the character is located and facing at any moment. So if the server or client moves the character, this is what moves. The SRB represents the One True Location and Orientation of the character at any moment.
To make a character move, you move the SRB. You can also hold the SRB stationary and move the character away from it, but the true location of the character doesn't change. Why would you do this? Perhaps you want the character to dance around a little (victory condition met!), there is no need to actually affect the location of the character in anyway during this secondary animation.
For animations that need to splice together precisely, the SRB is your key to linking them together. Make sure they line up at the end of one and the start of the next, and everything will go smoothly (assuming you animated the rest attractively).
Using SRB and VDA, your animation process is fairly straight forward. The SRB is the "where I am at and facing" indicator and VDA makes sure that every it moves precisely as you animated it.
Adding Animation Notes
Animation notes are necessary for the synchronization of sound and effects that will be added later to an animation in the engine. To add animation notes you must access the Curve Editor and select the highest object in the hierarchy. In the case of a biped animation, that will be the Bip01 root bone, or if you are adding to a grouped animated asset, you must select the group. Once the object is selected, click on the Tracks menu in the curve editor or Dope Sheet(max 8) and go: Tracks--> Note Track--> Add. This will create a note track in a sub slot of the object selected.
Switch over to the dope sheet ( Modes--> Dope Sheet ) and find the track you just added. Right click and choose Add Keys. To place keys on the desired frames, simply click in the note tack space. Once the keys are placed, right click on them to open the pop up dialogue and add the note.
When adding notes for animations be sure to follow the format designated for that particular action. For example, when adding notes to a combat animation most common terms will be: "Swoosh"; "Whoosh", "Impact 1of3"; "Impact 2of3"; etc. Impact notes must always be numbered. Check with the person who will be adding effects and/or sound to get a better idea of exactly what notes they will need.
CME Animation is not supported, and is only listed here for legacy purposes
Constant Motion Extraction
Constant motion extraction (CME) is an export-time process that converts an animation whose start and end frame have different placement for the root node into an animation where they are identical, thus "extracting" the constant motion of the animation. The extracted constant motion is then stored separately along with the animation for future use during playback.
Consider the scenario where a model walks forward five steps. In this animation, the root node of the model starts at some position, but ends five steps forwards. If the animation were played back looping, the model would forever walk five steps forward and then snap back, five steps, snap, etc.
What we would rather have happen is for the model to simply continue walking forward. We can do this by first observing that there is a constant velocity vector that, if applied each frame, would eventually move the root bone from its initial position on the first frame to its final location five steps hence. This velocity vector is simply the difference between the starting location and the ending location, divided by the duration of the animation.
Once we have this velocity vector, we can compare it to the actual motion of the root bone, which is almost certainly not a constant linear motion. Stepping through animation frame by frame, we can look at the difference between our linearly moved root bone and the actual root bone, and replace the positional animation of the actual root bone with these difference. Thus, we replace the actual animation of the root bone with the difference between its animation and the constant one we're extracting.
What we're left with is an animation which, if played back while moving the model forwards at the constant rate we've determined, will reproduce the original animation with all its nonlinearities. However, to HeroEngine, it seems like it's just moving at a constant rate, which makes it very easy to deal with programmatically.
This is the CME process, in its entirety.
Now, it is crucial to understand that CME in no way requires the actual animation to be linearly moving, or in a straight line, or anything like that. CME can handle any kind of animation, including walking in circles or turning around. The only thing you need to be aware of is that the root bone may be severely displaced from the model matrix for animations like these, and if that displacement is going to be a problem for your game design or your plans for animation blending, then you may be better suited using the VDA method of accumulation described in the following section.
When CME is enabled, it will make the exporter perform the constant motion extraction when the file is exported. However, there are 6 sub-settings that control how this extraction is performed. These are the 3 positional tolerances and the 3 rotational tolerances labeled by axis that appear as sub-settings when CME is selected.
These tolerances are necessary because, most of the time, it is not strictly possible for the animator to make the first and last frames of an animation line up exactly in the axes where you do not want accumulation to take place. For example, when a character walks forward, if the ending frame was slighty higher up than the first frame, accumulation that did not use a tolerance value would continue to accumulate this "drift", and thus the character would continue to get further and further from the ground over time. Clearly, this is not desirable, and the tolerance values help prevent this.
The tolerance values set a threshold below which the motion is considered "irrelevant" for purposes of extraction. The positional tolerances are expressed in art tool system units, and the rotational tolerances are expressed in degrees. For the positional tolerance, each axis is checked to see whether or not the difference between the first and last frame along that axis exceeds the tolerance value specified. If it does not, then accumulation will not be performed on that axis.
Rotational tolerances work similarly. If the total rotation of the root node along each axis does not exceed the tolerance for that axis, then that rotation will not accumulated.
CME is a nice root motion scheme because it allows HeroEngine to always consider models to be moving constantly through worldspace. However, it has one significant drawback: for animations which move highly non-linearly through worldspace, the root bone of the model can be severely displaced relative to the model matrix. Thus, where HeroBlade "thinks" the model is, in general, is very far from where it actually appears. This would happen for animations such as a frog hopping, where the frog stays in one place for the majority of the animation and then suddenly springs far forwards. In this case, the constantly moving model matrix will move smoothly over the duration of the animation, but the root bone will generally be either at the start of the jump or the end. Sometimes, this is not a problem, but depending on how you're switching between animations, or how you're using the model matrix to make decisions in your engine, it can be a big problem. Thus, HeroEngine also provides an alternative mechanism: