Skeletal Mesh Import Fails to Merge Bones when changing skeleton hierarchy with Shared Skeleton

Development Character & Animation
, ,
1

If you attempt to make skeleton hierarchy changes to a shared skeleton there seems to be no way to import all the changed skel meshes in a way that the skeleton can be updated and keep them all in a compatible state. I have prepared updated fbx files for all the skeletal meshes sharing the same skeleton. The same change was made to all of them, so if I were importing into an empty project this would work fine. But since I have to reimport them one at a time they each fail because individually they aren’t compatible with the rest of the meshes sharing the skeleton. Which in this circumstance are simply just waiting in line to also be reimported.

The failure to merge bones is understandable. If you import the skeletal meshes one at a time they are all individually incompatible with the old version of the skeletal meshes still waiting to also be reimported.

It feels like there should maybe be some kind of tool that walks you through importing all the conflicting skeletal meshes and won’t apply the changes to the skeleton until it gets into a consistent compatible state.

Is there a proper way to make hierarchy changes to group of skeletal meshes and their shared skeleton that doesn’t suffer from this problem?

2

Steps to Reproduce

  1. Start with a project with 2 or more skeletal meshes that share a single skeleton asset.
  2. In DCC add an intermediate bone on all of the skel meshes and export fbx for each. For example, if you have IK_Hand_L parented to root, add an intermediate bone like IK_Parent as a child of root and put the IK_Hand_L under that.
  3. Back in the editor try to reimport one of the skeletal meshes.
  4. The import will first attempt to merge the bone names of the new skelmesh with the existing shared skeleton. It will fail because IK_Hand_L exists in the existing skeleton, but has a different parent from IK_Hand_L in the newly imported skelmesh.
  5. It will then suggest regenerating the skeleton starting with the newly imported skelmesh. If you do this it will pull up a list of all the skelmeshes sharing the skeleton pointing out that it needs to merge bones from all of them into the newly generated skeleton.
  6. This will again fail because IK_Hand_L still exists in the other skelmeshes not yet reimported with a different parent than in the newly imported mesh.
  7. The import will stop at this point leaving things in a bad state. The skeleton now matches the newly imported mesh. But is incompatible with the rest of the skel meshes.
  8. Simply reimporting the rest of the skelmeshes does not resolve this bad state.
3

Hi Jaren, can you give me a bit more information on what you mean when you say that the other skeletal meshes are left in a bad state?

The workflow that I would expect in the case where intermediate bones within the skeleton hierarchy are changing would be to first fix up all of the meshes within the DCC and then reimport them individually, with the first reimport updating the skeleton asset. But it sounds like you’ve tried that (step 8) and that still left the meshes in a bad state?

We also have the a.Skeleton.AllowIncompatibleSkeletalMeshMerge cvar, which allows for merging of bones when the skeleton hierarchies are different. This will then rebuild the reference skeleton for each mesh that references the updated skeleton. But I’d be very careful about using that since it could easily break your assets. The main use case for that is bones that aren’t skinned in any of the meshes.

4

I did a bunch more testing on this [mention removed]​ .

If you see the prompt mentioned in Step 5 offering to regenerate the skeleton and click Yes, you will lose your Translation Retargeting settings. It turns out it doesn’t matter if it succeeds or if it fails. Either way your translation retargeting settings get set back to Animation on every joint. This is pretty easy to reproduce. I have a test project for this part if you want it with some simple rigged cube skelmeshes.

Other than this, you are right, if I go through the sequence and reimport all my fbx files individually everything works out ok other than the fact that I lose the retargeting settings.

I double checked that Sockets, Blend Profiles, Retarget Source, Compatible skeleton etc don’t get cleared out. Just the per bone Translation Retargeting settings.

(There is sometimes a transient bug where the bind pose on one or more of the reimported meshes gets garbled somehow, but this corrects itself upon reloading the editor so must not be saving in that bad state. I can demo this part in a video or a call if you’d like, but can only repro this one with our real data which I can’t post here. )

5

Thanks for taking the time to get the extra info on this.

> If you see the prompt mentioned in Step 5 offering to regenerate the skeleton and click Yes, you will lose your Translation Retargeting settings. It turns out it doesn’t matter if it succeeds or if it fails. Either way your translation retargeting settings get set back to Animation on every joint. This is pretty easy to reproduce.

I got a repro on this as well. Looking at the code, I see it’s because we store the retarget settings on the BoneTree of the Skeleton itself, and not the mesh. When the skeleton is regenerated, that clears the bone tree (via USkeleton::RecreateBoneTree), so the retarget settings are lost. This one is an issue with the importer itself, rather than the skeleton merging code, so I’ve created a JIRA for the pipeline team to take a look at. But I don’t think this should be a difficult one to fix, we just need to remap the retarget settings from the old bone tree to the new one.

> Other than this, you are right, if I go through the sequence and reimport all my fbx files individually everything works out ok other than the fact that I lose the retargeting settings.

Yeah, that’s the expected workflow - reimport the skeleton, the meshes and all the animations to account for any change in the hierarchy. We don’t have a better option, unfortunately, if the bones are animated and skinned. If the bones aren’t animated or skinned, the cvar I mentioned before could be an option.

> I double checked that Sockets, Blend Profiles, Retarget Source, Compatible skeleton etc don’t get cleared out. Just the per bone Translation Retargeting settings.

That’s good news that everything else is working as expected, at least.

> (There is sometimes a transient bug where the bind pose on one or more of the reimported meshes gets garbled somehow, but this corrects itself upon reloading the editor so must not be saving in that bad state. I can demo this part in a video or a call if you’d like, but can only repro this one with our real data which I can’t post here. )

If you can upload a video of the issue, I can do some digging and see if I can track down what’s going wrong. I’ve shared a Box link that you can drop the file into, you should have received a separate email about that. If you prefer, I can also make this thread confidential so you can attach the video directly.

6

As discussed, there’s a shelf at 46774002 which contains some changes to refresh the MH DNA asset when the mesh is reimported. I’ll talk with the MH team about getting this integrated. I’ll also leave this thread open in case anything comes up, it’ll auto close in a few weeks.