Compatible Skeletons questions

We’re evaluating a change in our setup that relies on template anim blueprints to support multiple characters. We’re not so interested in sharing animations but we do intend to share ABPs as much as possible.

In our initial tests we have SkeletonA and SkeletonB. Our animations were exported to SkeletonA. And now we want to have a character whose templated ABP uses SkeletonB, but should be able to play the existing SkeletonA bound animations. To this end we’re trying to use compatible skeletons.

  • SkeletonA
    • SK_Mesh_A
  • Animation_A
  • SkeletonB
    • SK_Mesh_B

The two skeletons have the same hierarchy and the same orientation on all joints on the reference pose. They have different proportions though.

When trying to play Animation_A on that skeleton the animation looks wrong, and some joints are out of place making it look squiggly.

I want to understand the requirements for compatible skeletons.

  • Does the reference pose on compatible skeletons need to match completely?
  • We have some twist bones set to “Skeleton” translation retargeting. All other bones are set to “Animation”. Is this relevant for compatible skeletons?

We’ve also had a prop joint (last in a chain) rotated 90 degrees when playing the animation in SkeletonB. Any idea where this could be coming from? I checked that the reference poses are identical but we still have this rotation issue on these prop joints.

Thanks!

Hey there,

Skeleton compatibility allows access to animations on another skeleton; it doesn’t handle the retargetting directly. The runtime retargetting options drive that.

Does the reference pose on compatible skeletons need to match completely?

No, the structures need to match, but the ref pose does not. However, the closer the ref pose and proportions, the better.

We have some twist bones set to “Skeleton” translation retargeting. All other bones are set to “Animation”. Is this relevant for compatible skeletons?

Yes, the animation retargetting options are very relevant because after applying skeleton compatibility adjustments, further adjustments are made by the animation retargeting system during animation playback.

Regarding your prop joint, this indicates that the ref pose is different in some way for that mesh. You may want to check that your meshes’ ref pose is set up to match SkeletonB’s ref pose and also that SkeletonB’s ref pose is set up to match SkeletonA’s.

Admittedly, this can get complex because it is a set number of options, and you need to plan how you will do the runtime retarget. Still, the access to play those animations on alternate skeletons is useful. It can be difficult to achieve the visual look you want, as the retargeting isn’t as complete. It is highly performant, though.

https://dev.epicgames.com/documentation/en-us/unreal-engine/animation-retargeting-in-unreal-engine

I will also recommend looking at the latest runtime IK retargetting tools. On Fortnite we use a schema where SkeletonA and B are compatible in terms of their, but we don’t mark them as skeleton compatible use a method where:

All animation is built on SkeletonA. At runtime, we have a non-rendered skeletal mesh component drive an attached visual skeletal mesh component for SkeletonB, where we use runtime retargetting (or copy pose from mesh, depending on the case) to drive the other child. This has been very performant for FN, and offers the best option for visual fidelity as well.

Dustin

Hi Dustin,

We’ve explored the invisible skeleton approach and want to evaluate this alternative. Most of our animations are exported to SkeletonA, even with varying proportions this worked fine using the invisible skeleton approach where we had

  • SkeletonA: plays animation
    • SkeletonB: Copy pose from mesh

We now want to test a workflow where we just have SkeletonB. For this I wanted to try compatible skeletons.

I’m still unclear on what the requirements are or how the different proportions can affect the visual result. The page you shared states that Animation Retargeting is meant for animations that use the same skeleton. Which isn’t our case.

What I’m missing are some guidelines on how to make skeleton compatibility work. At the moment the two skeletons match on structure. We’re getting results like this:

[Image Removed]

It makes sense to me that the animation that is authored for SkeletonA would not play cleanly in SkeletonB without accounting for a new reference pose. How can we tell it that the animation is authored for a different reference pose?

  • Specifying compatible skeletons?
  • Specifying retarget sources? Again this options seems to be only for matching skeletons?
  • Translation retargeting in the skeleton asset, which options should we choose here? Should we change them for SkeletonA, B or both?

“What I’m missing are some guidelines on how to make skeleton compatibility work.” No problem, I can recreate the exact issue you’re having with Manny and the UEFN Mannequin that we use in the Gameplay Animation Sample and walk you through each of your questions, as well as what steps you can take to get your animation playing as well as it can.

How can we tell it that the animation is authored for a different reference pose?

The only way you can tell this is by checking what skeleton is associated with the asset. In the context of code, this is the Skeleton property of an animation, where you can fetch the ref pose.

Specifying compatible skeletons?

When you specify that two skeletons are compatible, you are saying that two separate skeleton assets (closed animation source ecosystems) can share animations and animblueprints. This can be one-directional or bidirectional.

Specifying retarget sources? Again, this option seems to be only for matching skeletons?

This section has largely been deprecated in favour of the IK retargetting setup, but say you have masculine and feminine meshes that use the same skeleton asset as a base, but they have different ref poses. In this case, let’s say that the skeleton’s ref pose is the masculine body type. You can specify that the feminine body type is a retarget source. Then in the animation asset, there is a property called retarget source that, when changed to that body type, will use that ref pose to apply the animation against. In this way, you can author animations for the feminine body type and have them still play against its proportions properly while having the one source skeleton.

Translation retargeting in the skeleton asset, which options should we choose here? Should we change them for SkeletonA, B or both?

Generally, you would change these for Skeleton B if Skeleton A is the source for all of your animation work.

Given those, a strategy that I’ve taken when dealing with the translation retargetting as follows:

  • I recommend turning on the “Non-Retargeted Animation” option in your skeletal mesh viewport. In the screenshot below, this has the translation retarget options set to skeleton, which means that only rotational data from the animation is coming through. You can see the extreme delta from the source animation to Manny.

[Image Removed]

  • Because leaving anything set as animation means that it will play the animation based off the ref pose of the skeleton as is. Typically that means we leave the root bone or any positionally important bone as such. Attach bones, IK target bones. Those should probably stay as animation.
  • For the most part, we want to use **animation scaled,**which takes into account the distance between this bone and its parent in its ref pose and scales the animation translation appropriately. Using this setting through the arms, you’ll get a delta like this. Notice that the pose differences are generally stable, and the distance between the arm and the torso is pretty good. It’s important to take into account your bind pose, if there are large differences in rotation, you can still have some issues.

[Image Removed]

  • The fingers and twist bones will probably not be working well still, this indicates that both the translational and orientation deltas between the skeletons are pretty vast and are typical for hands. For the twist bones case on Manny, where you can match the translations, but the orientation differences are the main issue, I would recommend that you either adjust the orientation on the skeleton B to match skeleton A, or you will need to use something like a control rig twist setup. (The first image is with animation scaled, the second is what the normal pose should look like, but because we’ve modified the pose through the hierarchy, the retargeted orientations are going to be wrong)

[Image Removed]

  • Then for the fingers, you need to go through each bone and choose an option that best fits against the animation your are trying to play. In the case of the example I’m using, I chose animation relative for the metacarpals, meaning we apply the rotation as an additive to whatever the translational position of the bind pose might be, this gets the knuckles roughly in the same position as the parent animation, and then from there I chose skeleton for each of the fingers**,** having the rotation data being applied with no translational offset from the parent bone. This choice is very dependent on the ref pose orientation, and if there are extreme differences, it will be off. It does mean that the animation data’s translation is not being taken into account at all though.

[Image Removed]

Hopefully, this helps guide you through the potential issues, and you’ll need to play with some of the options to see what works best. The main thing to note is that you are modifying the animation pose. Most likely, for things where you touch other characters or objects in the world, you will need to do some form of runtime IK adjustment, as now that the animations are playing more similarly to the source on your new mesh, it may not reach or overreach the correct point.

Dustin