Change Details

Joining armatures is something that will become common in my workflow in the coming months and knowing this, I had to write an [operator](https://github.com/Mets3D/mets_tools/blob/master/armature_merge.py) to facilitate this. But it feels like this should just work without an addon. I'd like to know if the rest of the animation module agrees, and this is something that could go into Blender's Join operator, or if any of these changes are controversial. This is something I just might be able to implement myself, but I'd rather let a competent developer do it, if there are any volunteers. :) Here are the current problems when simply trying to join two armatures: #### Bone Groups Bone Groups of the active armature are preserved, but bone groups of the source armature(s) are completely nuked, or worse, assigned seemingly at random. Sometimes two armatures will have bone groups with the same name. In this case it would be best to "merge" these bone groups. It could happen that identically named bone groups have different colors, in which case this color data will be lost. In this case such bone groups could be suffixed with a .001 instead of being merged. But strictly only if the bone group colors do not match, otherwise just go ahead and merge them. #### Parenting Currently, when joining Armature A into Armature B, all objects that were parented to A are now parented to B. This is good! However, if the armatures weren't in the same place, the parented objects will move because their transform matrix and parent inverse matrix is not set. (Currently in my script I set the transform matrix, but I guess changing the parent inverse matrix would be more correct.) #### Modifier's References Sticking to the above A->B example, armature modifiers that were referencing A now reference nothing. I think these references should be redirected to Armature B. Perhaps this can be applied more generally, so that when any objects are joined into an object O, all references to the merged objects should be remapped to now target object O? Are there any cases where this would be bad? #### Vertex Groups Bone names can clash, and then they need to be appended with a .001 in their name. That's fine, but in this case the objects that were rigged with the original bone names now have vertex group names that did not get renamed. Fixing this is very painful. So, these vertex groups should be renamed along with the bones. #### Speed Just a nitpick, but I find it odd that joining complex rigs can take up to 10 seconds! I've added some timers to my python operator to show how just the Join operation is taking super long. Maybe some low hanging fruit optimization is possible there? Test files: {F9577649} (Just press Ctrl+J to see the usual result, and Alt+H to see the desired result) {F9577615} (For testing the speed)

Joining armatures is something that will become common in my workflow in the coming months and knowing this, I had to write an [operator](https://github.com/Mets3D/mets_tools/blob/master/armature_merge.py) to facilitate this. But it feels like this should just work without an addon. I'd like to know if the rest of the animation module agrees, and this is something that could go into Blender's Join operator, or if any of these changes are controversial. This is something I just might be able to implement myself, but I'd rather let a competent developer do it, if there are any volunteers. :) Here are the current problems when simply trying to join two armatures: #### Bone Groups Bone Groups of the active armature are preserved, but bone groups of the source armature(s) are completely nuked, or worse, assigned seemingly at random. Sometimes two armatures will have bone groups with the same name. In this case it would be best to "merge" these bone groups. It could happen that identically named bone groups have different colors, in which case this color data will be lost. In this case such bone groups could be suffixed with a .001 instead of being merged. But strictly only if the bone group colors do not match, otherwise just go ahead and merge them. #### Parenting Currently, when joining Armature A into Armature B, all objects that were parented to A are now parented to B. This is good! However, if the armatures weren't in the same place, the parented objects will move because their transform matrix and parent inverse matrix is not set. (Currently in my script I set the transform matrix, but I guess changing the parent inverse matrix would be more correct.) #### Modifier's References Sticking to the above A->B example, armature modifiers that were referencing A now reference nothing. I think these references should be redirected to Armature B. Perhaps this can be applied more generally, so that when any objects are joined into an object O, all references to the merged objects should be remapped to O? Are there any cases where this would be bad? (Note: I tried doing this with the current bpy.ops.outliner.remap_users() operator, but it segfaulted.) #### Vertex Groups Bone names can clash, and then they need to be appended with a .001 in their name. That's fine, but in this case the objects that were rigged with the original bone names now have vertex group names that did not get renamed. Fixing this is very painful. So, these vertex groups should be renamed along with the bones. #### Speed Just a nitpick, but I find it odd that joining complex rigs can take up to 10 seconds! I've added some timers to my python operator to show how just the Join operation is taking super long. Maybe some low hanging fruit optimization is possible there? Test files: {F9577649} (Just press Ctrl+J to see the usual result, and Alt+H to see the desired result) {F9577615} (For testing the speed) CC @sybren @jpbouza @looch and any other people interested in rigging, for opinions :)

Joining armatures is something that will become common in my workflow in the coming months and knowing this, I had to write an [operator](https://github.com/Mets3D/mets_tools/blob/master/armature_merge.py) to facilitate this. But it feels like this should just work without an addon. I'd like to know if the rest of the animation module agrees, and this is something that could go into Blender's Join operator, or if any of these changes are controversial. This is something I just might be able to implement myself, but I'd rather let a competent developer do it, if there are any volunteers. :) Here are the current problems when simply trying to join two armatures: #### Bone Groups Bone Groups of the active armature are preserved, but bone groups of the source armature(s) are completely nuked, or worse, assigned seemingly at random. Sometimes two armatures will have bone groups with the same name. In this case it would be best to "merge" these bone groups. It could happen that identically named bone groups have different colors, in which case this color data will be lost. In this case such bone groups could be suffixed with a .001 instead of being merged. But strictly only if the bone group colors do not match, otherwise just go ahead and merge them. #### Parenting Currently, when joining Armature A into Armature B, all objects that were parented to A are now parented to B. This is good! However, if the armatures weren't in the same place, the parented objects will move because their transform matrix and parent inverse matrix is not set. (Currently in my script I set the transform matrix, but I guess changing the parent inverse matrix would be more correct.) #### Modifier's References Sticking to the above A->B example, armature modifiers that were referencing A now reference nothing. I think these references should be redirected to Armature B. Perhaps this can be applied more generally, so that when any objects are joined into an object O, all references to the merged objects should be remapped to now target object O? Are there any cases where this would be bad? (Note: I tried doing this with the current bpy.ops.outliner.remap_users() operator, but it segfaulted.) #### Vertex Groups Bone names can clash, and then they need to be appended with a .001 in their name. That's fine, but in this case the objects that were rigged with the original bone names now have vertex group names that did not get renamed. Fixing this is very painful. So, these vertex groups should be renamed along with the bones. #### Speed Just a nitpick, but I find it odd that joining complex rigs can take up to 10 seconds! I've added some timers to my python operator to show how just the Join operation is taking super long. Maybe some low hanging fruit optimization is possible there? Test files: {F9577649} (Just press Ctrl+J to see the usual result, and Alt+H to see the desired result) {F9577615} (For testing the speed) CC @sybren @jpbouza @looch and any other people interested in rigging, for opinions :)