UnrealOni/ALS
This is a mini overview of similarities and differences between versions 2 and 3 of Advanced Locomotion System by LongmireLocomotion when it comes to importing a new character into the system (via FBX).
Getting foot IK and ragdolling to work
For simplicity we are discussing characters that have already been carefully adapted for UE4 in Blender or such, so that no retargeting is needed. That is:
- the skeleton is assumed to have the same layout as that of Unreal's SK_Mannequin (same bone hierarchy, including the auxiliary IK bones; "twist" bones are optional);
- the bones are assumed to have the same names as in Unreal's Humanoid rig;
- the local axes of each bone are supposed to be consistent with UE4's conventions (primary bone axis is either X or -Z, secondary is typically Z or -Z).
A good example of such a character can be obtained if you export Unreal's SK_Mannequin to FBX.
Under the above assumptions, the character FBX can be imported into any project that features a basic UE4 Mannequin (such as a basic ThirdPerson game template, or the ALS2 project, or the ALS3 project). Since the skeleton of the imported character is conventional (same bone names and bone orientations as for the Mannequin), one can typically choosing UE4_Mannequin_Skeleton under Mesh/Skeleton in the "FBX Import Options" dialog. Immediately after that, the new Skeletal Mesh can be set as the Mesh property of the pawn entity (the isolated mannequin in the middle of the level), and the game is immediately playable, i.e. basic locomotion immediately works on the imported character.
Two things, however, might not work right away: foot IK and ragdolling. The following explains how to get them both to work, so you can start running around and having fun.
For simplicity we assume (for now) that we are working with an exported/reimported FBX mannequin that has exactly the same proportions as the project's original Mannequin.
Ragdolling
Ragdolling is the easier of the two. The imported character simply needs to have a suitable Physics Asset (collision boxes/cylinders/capsules around the limbs, and joints between them with appropriate rotation constraints.
(If there is no physics asset, then ALS will typically send the character flying instead of ragdolling. If the physics asset is present but somehow incorrect, the character may flex incorrectly, or become separated from the playable character's capsule, or get stuck in the ground, etc.)
A Physics asset can be generated (or chosen from existing ones) at any time, including during the initial import of the FBX character (it's in the same section as where you choose the Skeleton).
ALS has a rather elaborate implementation of ragdolling (the character stays interactive while in the ragdoll state, and is able to get up in a smooth transition from the ragdoll state), so it is best to start with the included Physics asset that is already used by the ALS project's default Mannequin. Generating a new physics asset is also possible, but it will take you some time to adjust all the collision shapes and constraints. So, if you are at the initial FBX Import Options dialog, just go to Mesh/Physics Asset and pick the existing Mannequin's physics asset. If you already imported the character either without a specific physics asset or with a newly generated one, open the new Skeletal Mesh in the Editor, and in the left-hand panel (Asset Details), pick the correct Physics Asset under the Physics section.
The above procedure is exactly the same in ALS2 and in ALS3, although there are some differences in the name of the entities, blueprints and assets.
Foot IK
It is very frustrating when you import a Mannequin, make sure its skeletal mesh has exactly the same settings as the included Mannequin (including the Physics Asset), but somehow the foot IK does not seem to work. In ALS3, the new character is actually expected to have correct IK immediately upon import - indeed, the default "Post Process Anim Blueprint" (under the Skeleton Mesh section in Asset Details for the Mesh) is None, which is consistent with the corresponding setting of the included Mannequin mesh. In ALS2, the included SK_Mannequin has, in the same field, the setting "Mannequin_PostProcess_AnimBP", so it is necessary to open the new Skeletal Mesh in the editor, go to Asset Details on the left, scroll to the Skeletal Mesh section, and set "Post Process Anim Blueprint" to "Mannequin_PostProcess_AnimBP". The confusing part is that even after you do this (set the correct "Post Process Anim Blueprint"), and save all the assets in the project (just in case), the new character will still not appear to have working foot IK.
Somehow this crazy situation is resolved if you close the ALS project and open it again. Apparently IK support is properly initialized only for those character assets that are already present in the project when it opens.
Custom body proportions - locomotion (ALS3)
Suppose you import a female character that has comparatively shorter arms and narrower shoulders/hips than the slightly buff Mannequin. In the standard ThirdPerson project or in ALS2, you will see no problem: both Unreal's Starter Pack animation and ALS2's locomotion set will look OK on this character, despite the different proportions. In ALS3, however, you will see a problem: the new character will have a characteristic "slender" look (thin arms, stretched-out hips and shoulders, elongated spine), because Mannequin_Skeleton is forcing specific distances between joints (the same as for the Mannequin).
The setting responsible for this behavior is located in the Skeleton asset, under Skeleton Tree (left panel), but it's one of the advanced settings which are not visible by default. Reveal it as follows.
- In 4.19 and later, click the "Options" dropdown immediately below the "Skeleton Tree" header, and check the "Show Retargeting Options" box: a "Translation Retargeting" column appears besides the skeleton tree.
- In 4.18 and earlier, click the "Bones, Active Sockets" dropdown in the lower right corner of the "Skeleton Tree" panel, and check the "Show Retargeting Options" box: a "Translation Retargeting" column appears besides the skeleton tree.
You will see that the "UE4_Mannequin_Skeleton" skeleton used in ALS2 or in the Third Person template has "Translation Retargeting" set to "Skeleton" for all bones except "root", "pelvis" and the seven IK bones, whereas "Mannequin_Skeleton" (ALS3) has "Animation" set for all bones. What does that setting mean, actually?
The skeleton of a character contains information about the placement of each joint with respect to the parent bone (e.g., the length of a limb or spine section, the left/right displacement of a hip joint, etc). This relative placement is typically not modified during animation (i.e., characters don't typically get dislocated joints). So the only non-trivial information in an animation (besides the root and pelvis movement) is the rotation at each joint. However, animations always imply the existence of a skeleton, and each animation asset typically includes not just joint rotations, but also the relative translations corresponding to the skeleton for which the animation was originally intended. That means that, for example, if you export an animation to FBX from Unreal and open it in Blender, the animation will clearly show the proportions of the skeleton for which the animation was made. In our case all the animations are intended for Unreal's male Mannequin, with long arms, wide shoulders, etc.
When playing back an animation on a character, Unreal Engine can either use or ignore the translation data included in the animation.
- To use the translation data means to place the joints according to the animation, i.e., in our case, based on the proportions on the male skeleton - this setting of "Translation Retargeting" is called "Animation" and is the most rigid of the available settings.
- To ignore the translation data of the animation means to place the joints according to the mesh itself, or rather to its own internal skeleton - that is, the bone structure you see in the Mesh editor (if you enable the display of bones), and not to be confused with the Skeleton Asset (in our case, the male Mannequin's skeleton). By setting "Translation Retargeting" to the not-so-intuitive "Skeleton" value, the engine is told to take only rotation data from the animation and, as for relative translations, the engine will look them up in the internal skeleton of the mesh (and not in the Skeleton asset).
Thus, to make a female character look OK in ALS3 (or any other character with custom proportions), you will need to modify the "Translation Retargeting" value and set it to "Skeleton" for all non-IK bones.
Custom body proportions - ragdolling
Suppose you have imported a custom-proportioned character (e.g., a female with a smaller upper body and much narrower shoulders) and hooked it up with the Physics Asset of the base mannequin. If you try going into the ragdoll state, you will likely see what appears to be a sudden dislocation of the spine and shoulders. It looks similar to the "slender look" described above (an animation issue occurring only in ALS3, due to overly strict "Translation Retargeting"), but it is in fact very different. For ragdolling the issue is that Unreal does try to adapt the collision shapes to the new character but, in doing so, it sometimes does not sufficiently reduce the size of the collision shapes. If the collision shapes of the upper body retain a large size but are brought much closer to each other, they form a cluster where shapes overlap a lot not only with their nearest neighbors, but further along the chains. Collision between adjacent shapes (e.g., between pelvis and spine_01, spine_01 and spine_02, etc) can be disabled, as a setting of the constraint linking the two shapes/bones (and typically is disabled, which allows, e.g., thigh and calf shapes to overlap at the knee). But collision between, e.g., pelvis and spine_02, or between spine_01 and spine_03, can not be disabled. Therefore, if such non-adjacent shape pairs do overlap, they will repel with enough force to stretch the character, overriding the joint constraints and effectively dislocating the skeleton - even though the skeleton used is the correct one, and not that of the Mannequin.
This dislocation behavior can only be fixed by editing the Physics asset, i.e., by reducing the size collision shapes and adjusting their placement, so that they only overlap with their immediate neighbors.
The recommended procedure is this:
- make a duplicate of the mannequin's Physics Asset;
- configure the custom character to use that copy instead of the original;
- set up the display mesh of the Physics asset to the custom character;
- edit the collision shapes so that they only overlap with adjacent ones.
Custom animations - blueprint fix
If you want to replace or complement ALS's locomotion animations with your own, and do not want to follow the convention of animated IK bones (ALS expects locomotion animations to have motion tracks for the IK bones that exactly replicate the motion of the actual foot_l and foot_r), you need to modify the animation blueprint (either Mannequin_PostProcess_AnimBP for ALS2, or Mannequin_IK_AnimBP for ALS3), as described HERE (ALS thread on UE4 forum, post #442). In the Anim Graph, disconnect the "Use cached pose 'Sub-Graph Input'" and "Local To Component" nodes and add two "Copy Bone" nodes between them and the first "Transform (Modify) Bone" node of the "Foot IK" block. For both these new nodes, check "Copy Translation" and "Copy Rotation" and set "Control Space" to "World Space" (in the "Details" panel on the right). Set the source and target bones like on the picture in post #442 (copy from foot_l to ik_foot_l and from foot_r to ik_foot_r).
After you to this, you can configure the animation blueprint to use any locomotion animations, including those that do not contain animation tracks for the IK bones at all. Also, the "Translation Retargeting" value "Animation" (for the Skeleton Asset) becomes completely irrelevant, since the animated position of the IK feet (if available in an animation) will be overridden by that of actual feet immediately before foot IK processing.