Joining armatures - Problems with same name on the bones
Closed, ResolvedPublic


System Information
Windows 10, NVIDIA GeForce GTX 1060 3GB

Blender Version
Broken: 2.79 (sub 0), branch: master, hash: 5bd8ac9

Short description of error
When joining (CTRL+J) two armatures, bones with the same name will get something like ".001" appended to the name. However this does not behave the same as if we have changed the name of the bones manually before joining. The bones with keyframes (or animations) will fail to update accordingly as the name of the bones gets changed. The bone constraints get lost. (This also causes naming problems on weighted meshes)

Exact steps for others to reproduce the error
Based on a (as simple as possible) attached .blend file with minimum amount of steps

  1. Start with empty scene
  2. Shift+A > Armature > Single Bone
  3. Press: Tab E Esc G Z 1 Enter
  4. Goto "Pose Mode" and select all bones
  5. In "TimeLine": Pick "Rotation" keying set, and set key at frame 1
  6. Move to frame 250
  7. Make some changes to the bones
  8. Select all bones and set key
  9. Goto "Object Mode" and duplicate the armature (place the new one beside the old one)
  10. For each armature: Select it and run "Bake Action" (uncheck "Only selected"), Pick Pose and OK
  11. Navigate to "NLA Editor"
  12. Push down the both actions as new NLA strips

----- Done preparations, This is exactly what's done in BlenderCommunityBugReport.blend


  1. Select both armatures, press: Ctrl+J, now one of the animations will fail


  1. Change the name of the bones in one of the armatures so that no bones have the same name across the armatures
  2. Select both armatures, press: Ctrl+J, now both of the animations will work

One more thing:
If there are some meshes weightpainted for the bones. The "auto name change" will break the constraints, while "manual name change" will retain them.

Philipp Oeser (lichtwerk) triaged this task as Confirmed priority.Fri, Jan 26, 9:17 PM

I can confirm this behaviour (though this is probably a known limitation).

At first glance this even seemed to be implemented in rB99a5f376a21099a1 [but not sure, I havent actually verified the commit] but then was limited to drivers only in rBa730cda72ff94ea0?

@Joshua Leung (aligorith) : mind having a look?

As written above, a workaround would be manually renaming the bones before joining the armatures. This means that it wouldn't be too difficult to make it automatically rename them for us when joining. Manually renaming all the bones would be a long lasting pain

Ok, so carefully re-reading the bug description, it sounds like there are two parts to this: 1) Animation Data, 2) Constraints

1) Animation Data

Technically, this isn't a bug.

We deliberately don't try to fix animation data when joining armatures, as it is assumed that doing so wouldn't be too useful to do so in most cases. Specifically, we assume that in most production pipelines, you wouldn't really want to be doing any rig merging/splitting once animation has begun. For example:

  1. If you do modify the rigs during animation/production, it's likely that the changes would be minor enough or that they would be known to break animation (and thus, it doesn't make sense to patch the old data over),
  2. If you're modifying the rig during the pre-production stage, any animations that have been made are likely to be just test animations. So, it's not a big deal if we lose those. The animators would likely be making some fresh shots anyway to test out the changes in the rig.

Furthermore, in most pipelines, the armatures/rigs are defined in one file, while all the per-shot animation are defined in many other unrelated files. This operator can only really fix anything that is connected in the here and now. Again, there's not much point doing it.

Granted, in a few simple cases (provided the right conditions are in place), it might be ok support such functionality (and it would also be quite useful to have it). It recently put in place some similar code for Grease Pencil (in the new branch), so it's not a big deal to adapt this for this case.

2) Constraints

I haven't checked yet whether there are problems here. More investigation needed.