Page MenuHome

Shapekeys animation is blocked after second append of the same object.
Closed, ResolvedPublicBUG


System Information
Operating system: Linux-5.3.0-40-generic-x86_64-with-Ubuntu-19.10-eoan 64 Bits
Graphics card: GeForce RTX 2060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 435.21

Blender Version
Broken: version: 2.83 (sub 9), branch: master, commit date: 2020-03-16 13:32, hash: rB20f6700c8864
Worked: I don't know which version worked previously. Fresh compilation.

Short description of error
An animated shape key on an appended object is editable only when this object is firstly appended or unique. Appended next objects from the same file are blocked in shapekey animation curves for no apparent reason. Single works, multiple do not.

Exact steps for others to reproduce the error

  1. Create a shapekey for a default Cube.
  2. Animate this shapekey to have some action.
  3. Save file and restart blender.
  4. Remove default cube and append the one from file saved in (3).
  5. Check:
    • the animation: works
    • the editability of animation curves: works, they are editable.
  6. Append the second cube from the same file (3).
  7. Editing of curves is blocked for this object, which I consider a bug.

Actions taken to test this further:

  • change object name
  • change object and object data name
  • change object, objdata and shapekeys names
  • change shapeaction name
  • any change of datablocks do not work.
  • setting an override thru outliner do not work (nothing or the above helps)

I don't know if this is by design, or is it some nasty bug, but this problem severely limits my student's work on his MsC. I could not find any solution in the blender.stackexchange or by googling. Please advice and thank you for your hard work!

Event Timeline

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Confirmed.Mar 17 2020, 5:41 PM
Philipp Oeser (lichtwerk) changed the subtype of this task from "Report" to "Bug".

Can confirm the behavior.

Second appended cube's KeyAction is marked as linked (not sure why that is -- 2.79 did the same here though), looks like the Action cannot be made local [like the one from the first appended cube]
Interestingly, you can still edit it in the DopeSheet > Shape Key Editor sliders (that change is lost on save / reload though... and is probably another bug in itself...)

No expert in Animation & Rigging but the "workaround" for now would be to make the Action local "by hand" like so (it can then be edited again):

To me, this looks like a bug though, dont really see why this Action cannot be made local.
CC @Sybren A. Stüvel (sybren), @Bastien Montagne (mont29)

It seems that the Action is kept linked at the first Append already, which is strange because I had the "Localize All" setting checked.

Upon further inspection, the shapekey and its action are actually local:

>>> D.meshes['Cube'].shape_keys.library is None
>>> D.meshes['Cube'].shape_keys.animation_data.action.library is None

But for the second cube, the action is not local:

>>> D.meshes['Cube.001'].shape_keys.library is None
>>> D.meshes['Cube.001'].shape_keys.animation_data.action.library['reproduce.blend']

What seems to happen is this:

  • Cube + its shapekey (Key) + the shapekey's action (Action) are linked in.
  • Cube (object, mesh, material) are made local by "expanding", i.e. by simply marking it as local.
  • Key is NOT explicitly made local, as it's not a "linkable" datablock.
  • Action is made local by copying, as it's indicrectly used via the not-local Key. After copying, pointers are changed so that the local copy is used.
  • The Key is made local by some other means, as it's part of a now-local mesh.

The resulting situation is that there are two copies of the Action: a local copy, and the linked-in copy. After appending the Cube again, the linked-in copy is still there, so it doesn't get made local, the pointer shuffle doesn't happen, and the animation is not editable because it's a linked datablock.

I think the correct solution would be to remove the linked-in Action after it has been copied, but I want to discuss that with @Bastien Montagne (mont29) first. Bastien, what do you think?

This is really an ID management issue, not really related to animation (besides the fact that affected ID is an Action)...

@Sybren A. Stüvel (sybren) thanks for initial investigation, will try to fix that.