Apparently this is a series of more than 1 questions actually, the part in bold sums it up.

Was experimenting with animations, armatures and instancing. Tested it by making a palm tree where the stem has it's own armature and the fronds each have their own too. The fronds' models and armatures are copies of a original made by instancing and making them real, each bone was renamed with the method ".000". There is where the problems start.

Each copy is assigned the newly created armature on the armature modifier and surprisingly the vertex groups are also renamed automatically, but actions do not copy. Have to make new action for each new armature, not sure if it's a limitation of instancing. Keyframes can be copied between each frond's armature's action with no problem though.

Renaming each bone of each real copy's armature makes the bones of the other copies that weren't touched yet be renamed in the exact same way, but bones of armatures that were already changed are not affected. Not sure if it's yet another limitation.

When the stem's and fronds' armatures are joined with the stem's as the main (last selected), in any number and in any way, any other armature not joined get the problem mentioned in the title. Copying the original frond's keyframes into the stem's action (now entire model's action) do not work properly anymore, even if bones are named propperly and there were no problems copying keyframes pre-joining.

Leaving the original frond unjoined, it's keyframes can be copied, but any other action it has become unnapliable despite appearing in Graph editor and being able to be set on the Action in Action Editor and Outliner. No other action produces visual effects anymore and selecting any action other than the one active when the other armatures were joined makes the active one not work anymore too.

One workaround is to join everything at the same time, but then the original loses the action even if it isn't joined. Other workaround is to first copy the original frond' keyframes, join just one frond model and armature to the stem, paste the keyframes then delete or unlist everything else, then just copy the bones inside the single armature and the fronds inside the single mesh both in edit mode.

Anyways, having any other armature and unnactive actions become phantoms after joining 2 armatures seems like quite the bug

coudn't reproduce the issue despite it existing for about 3 days before

Coudn't reproduce the issue despite it existing for about 3 days before, that is the reason the "post-joining" examples are "visualizations"

  • $\begingroup$ A blend file would be very helpful, along with a few screen shots. (How to add a blend file) $\endgroup$ Oct 19, 2021 at 15:01
  • $\begingroup$ @MartyFouts Thanks. Just added the file, thankfully it's from before joining the armatures so more pople can see the thing in action themselves. Also added some visual explanation, it's a mess but still explains the issue fully $\endgroup$
    – Vinis
    Oct 19, 2021 at 16:15

1 Answer 1


This is not a bug, it's the expected behaviour, related to Blender datablocks structure.

Some work is needed to get the result I presume you want (a single mesh with a single armature to get exported as Fbx with the complete tree animation).

To address the problem solving you have to realize that every Blender object is constructed by many datablocks: i.e. your StemSkelly armature uses the armature datablock named "Armature" (you can read its name and its users on the green little man icon on the properties panel).

The problem lies in the fact that you have 25 different FrondSkelly objects (.001, .002, .003, ......) which ALL relie on a single Armature named "Armature.001".

The same happens with the frond meshes, which are named "Palm front healthy.001, .002, .003, ..., but they all rely on a single mesh datablock named "Cube".

When you join the armatures you are joining theese two datablocks (Armature and Armature.001), which both are merged into "Armature", while "Armature.001" doesn't exist anymore (and this freezes all others animations).

A working workflow I used to solve the issue is this:

Delete all copies of the fronds.

Apply (Ctrl A) all transforms both to original frond and frond rig objects.

Add a root bone and make it parent of all frond rig, make sure that moving root bone will move all frond mesh (delete the vertex group named "Base").

Set the stem rig in rest pose.

Use Shift D to duplicate frond and frond rig. Create a copy of its action and add a Loc Rot Scale keyframe to its root bone to place the frond in the correct place (it's important to leave the frond rig to be joined in world origin, same as stem 000, 000, 111, and use animation data to move the mesh in its correct place).

Add a "Child of" constraint to the root bone pointing at an appropriate stem bone.

Join the frond mesh to the stem mesh and the frond rig to the stem rig.

Open NLA editor, use the "Push down" button in the action editor to send the stem action to NLA, and add the frond action (that with the LocRotScale keyframe added).

Repeat for all others frond, checking the corrispondence between bones names and vertex group names after joining mesh and rigs (in my example I had to rename the vertex groups numeric suffix).

When finished and working you can bake the whole NLA stack of actions, to create a new action using visual keying and deleting all constraints, to obtain one single complete exportable action, acting on one single mesh with its single armature.

enter image description here

  • $\begingroup$ Just LOVE IT! Thought I had got this datablock stuff down already, guess I am heading back to the manual, gotta learn that thing for sure. Yes, that's exactly what I was trying to do. Tried instancing because it's a good way to repeat an object many times, thought it would copy everything from the original when made real, but it just makes many copies relying on single datablocks and a nightmare to animate... Loved the addition of this workflow, it's just perfect to my needs $\endgroup$
    – Vinis
    Oct 20, 2021 at 18:54
  • 1
    $\begingroup$ The only drawback is that in rest pose the tree will have all its fronds overlapping in the same base location. If this is a problem you'll have to find another workflow, but I think you understood the basics step you need to follow! $\endgroup$ Oct 20, 2021 at 19:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .