Joining armatures - Problems with same name on the bones #53909

New Issue

Timmy Chan · 2018-01-26T13:19:13+01:00

Timmy Chan commented

2018-01-26 13:19:13 +01:00

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

Start with empty scene
Shift+A > Armature > Single Bone
Press: Tab E Esc G Z 1 Enter
Goto "Pose Mode" and select all bones
In "TimeLine": Pick "Rotation" keying set, and set key at frame 1
Move to frame 250
Make some changes to the bones
Select all bones and set key
Goto "Object Mode" and duplicate the armature (place the new one beside the old one)
For each armature: Select it and run "Bake Action" (uncheck "Only selected"), Pick Pose and OK
Navigate to "NLA Editor"
Push down the both actions as new NLA strips
----- Done preparations, This is exactly what's done in BlenderCommunityBugReport.blend

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

Workaround:
13. Change the name of the bones in one of the armatures so that no bones have the same name across the armatures
14. 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.
BlenderCommunityBugReport.blend

**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* Bug: 13. Select both armatures, press: `Ctrl+J`, now one of the animations will fail Workaround: 13. Change the name of the bones in one of the armatures so that no bones have the same name across the armatures 14. 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. [BlenderCommunityBugReport.blend](https://archive.blender.org/developer/F1987094/BlenderCommunityBugReport.blend)

Timmy Chan commented

2018-01-26 13:19:13 +01:00

Added subscriber: @timmychan301197

Philipp Oeser commented

2018-01-26 21:17:52 +01:00

Added subscribers: @JoshuaLeung, @lichtwerk

Joshua Leung was assigned by Philipp Oeser

2018-01-26 21:17:52 +01:00

Philipp Oeser commented

2018-01-26 21:17:52 +01:00

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

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

@JoshuaLeung : mind having a look?

I can confirm this behaviour (though this is probably a known limitation). At first glance this even seemed to be implemented in 99a5f376a2 [but not sure, I havent actually verified the commit] but then was limited to drivers only in a730cda72f? @JoshuaLeung : mind having a look?

Timmy Chan commented

2018-01-26 21:46:31 +01:00

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

Joshua Leung commented

2018-01-29 03:18:01 +01:00

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:

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),
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.

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.

blender-admin commented

2018-01-29 05:13:23 +01:00

This issue was referenced by d13b943853

This issue was referenced by d13b943853953d4573a1d74bd0048bc236658783

Joshua Leung commented

2018-01-29 05:23:08 +01:00

Changed status from 'Open' to: 'Resolved'

Joshua Leung closed this issue

2018-01-29 05:23:08 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Joining armatures - Problems with same name on the bones #53909

1) Animation Data

2) Constraints