Maniphest T76608

Linked duplicates share animation data.
Closed, ResolvedBUG

Assigned To
Sybren A. Stüvel (sybren)
Authored By
Alaska (Alaska)
May 10 2020, 8:54 AM
Tags
  • BF Blender
  • Animation & Rigging
  • Documentation
Subscribers
Alaska (Alaska)
Mike (MikeMS)
Omar Emara (OmarSquircleArt)
Sybren A. Stüvel (sybren)

Description

System Information:
Operating system: Linux 5.4.0-7626
Graphics card: GTX 1050ti 440.82

Blender Version:
Broken: 2.79, 2.82a, 2.83 ce76e17584ee (2020-05-08 14:49), 2.90 f2178b7f9740 (2020-05-09 18:47)
I have not tested any version older than 2.79 and I haven't tested the in-between releases of 2.80 and 2.81

Short description of error:
I ran a quick search and couldn't find any other reports covering this. I'm sorry if this is a duplicate.

When creating a linked duplicate of an object, its animation data for transformations will also be linked. I don't believe this is a bug, but it seems like unexpected behavior to me.

Here's a excerpt from the manual discussing linked duplicates:

You also have the choice of creating a Linked Duplicate rather than a Duplicate; this is called a deep link. This will create a new object with all of its data linked to the original object. If you modify one of the linked objects in Edit Mode, all linked copies are modified. Transform properties (object data-blocks) still remain copies, not links, so you still can rotate, scale, and move freely without affecting the other copies.

If one of these two cubes is rotated or rescaled in Object Mode, the other remains unchanged. The transform properties are copied, not linked.

If I'm reading that correctly, the manual is saying "Everything is linked" apart from transformation data. And animation data is not transformation data, so it should be linked (which I'm experiencing). However, the animation data can influence transformation data so it shouldn't be linked?

I found this "issue" because I had two of the exact same mesh that I wished to animate for a simple scene. I animated one, then created a linked duplicate of it and animated the other only to find that the original object had copied the animation data from the linked duplicate. I believe this is a "expected" use case of linked duplicates and is why I propose that the animation data isn't linked when creating a linked duplicate.

Example of what's going on (At the end of the video, I used undo to go back to a state when the objects had keyframes to show off that the linked objects do indeed share animation data):

Exact steps for others to reproduce the error:

  1. Start Blender.
  2. Keyframe the location, rotation, or scale of any object.
  3. Create a linked duplicate of that object with "Alt+D".
  4. If you then attempt to animate any of these values on the "Linked duplicate", then they will also apply to the original object. If you animate any of the values on the original object, it will also apply to the "linked duplicate". This is because the "linked duplicate" and "original" object have linked animation data (which you can see by checking the outliner).

Note: This does not happen if the "original object" had no animation data before a linked duplicate was made. This is because there is no animation data block to link.

Note: Animation data includes more than just transformations. It includes animation object visibility, viewport display color, etc (As far as I can tell, pretty much every setting in the "Object" panel in the properties editor). It also includes things like object constraints. But I believe having these linked probably isn't necessary. Correct me if I'm wrong.

In the meantime for myself and anyone else experiencing the issue, you can unlink the animation data by selecting from the top of the viewport: "Object>Relation>Make Single User>Object Animation"

Revisions and Commits

rBM Blender Manual

Related Objects

Mentioned In
T101387: Linked object resets it's rotation after scene reopening and if it was rotated and keyframed
Mentioned Here
rBce76e17584ee: Fix T65012: Update depsgraph for matcap flipping
rBf2178b7f9740: deps/windows: Fix wrong crt for libjpeg and pthreads

Event Timeline

Alaska (Alaska) created this task.May 10 2020, 8:54 AM
Alaska (Alaska) added projects: Animation & Rigging, Documentation.
Alaska (Alaska) updated the task description.May 10 2020, 9:02 AM
Alaska (Alaska) updated the task description.May 10 2020, 9:27 AM
Alaska (Alaska) updated the task description.May 10 2020, 12:54 PM
Alaska (Alaska) updated the task description.
Sybren A. Stüvel (sybren) changed the task status from Needs Triage to Confirmed.May 11 2020, 11:08 AM
Sybren A. Stüvel (sybren) added a subscriber: Sybren A. Stüvel (sybren).

What is duplicated and what is shared is determined by these preferences:

You're right that this should be explained in the manual, though.

Sybren A. Stüvel (sybren) changed the subtype of this task from "Report" to "Bug".May 11 2020, 11:09 AM
Sybren A. Stüvel (sybren) moved this task from Backlog to Bugs on the Animation & Rigging board.May 11 2020, 11:16 AM
Alaska (Alaska) added a comment.EditedMay 11 2020, 12:12 PM
In T76608#928606, @Sybren A. Stüvel (sybren) wrote:

What is duplicated and what is shared is determined by these preferences:

You're right that this should be explained in the manual, though.

That determines what's duplicated and what's shared when duplicating the object (Shift+D) not while creating a linked duplicate (Alt+D). The issue I'm experiencing is to do with the linked duplicate sharing animation data with the original object. The code is most likely programmed this way and the manual implies this happens (when you read between the lines), however, I believe the animation data shouldn't be linked, but duplicated as one of the most common uses of animation data for a object is animating the transformation of an object which the manual says isn't linked between linked duplicate objects.

Alaska (Alaska) added a comment.May 11 2020, 12:14 PM

Reading over my report again plus all the experiences I've had over the last few days, this is more a design or documentation task than a bug.

Sybren A. Stüvel (sybren) added a comment.May 18 2020, 12:49 PM
In T76608#928683, @Alaska (Alaska) wrote:

That determines what's duplicated and what's shared when duplicating the object (Shift+D) not while creating a linked duplicate (Alt+D).

You're right. This bit of code takes care of that:

int dupflag = (linked) ? 0 : U.dupflag;

So when it's a linked duplicate (Alt+D) it won't duplicate anything.

The code is most likely programmed this way and the manual implies this happens (when you read between the lines)

Well, the introduction paragraph of Linked Duplicates states that "This will create a new object with all of its data linked to the original object", so it's quite explicit.

however, I believe the animation data shouldn't be linked, but duplicated as one of the most common uses of animation data for a object is animating the transformation of an object which the manual says isn't linked between linked duplicate objects.

The manual is correct in this sense, as the transform properties aren't linked indeed. They're set to the same values by the animation system, though. I'll clarify this in the manual.

Personally I think that linking to *all* data, as Alt+D is doing now, is easier to understand & explain than to have special cases for this.

Sybren A. Stüvel (sybren) closed this task as Resolved by committing rBM6663: Fix T76608 by clarifying the effect of animation on linked duplicates.May 18 2020, 12:54 PM
Sybren A. Stüvel (sybren) claimed this task.
Sybren A. Stüvel (sybren) added a commit: rBM6663: Fix T76608 by clarifying the effect of animation on linked duplicates.
Alaska (Alaska) added a comment.EditedMay 18 2020, 12:57 PM

@Sybren A. Stüvel (sybren) Thank you for taking the time to explain the reasoning. And the commit to the manual makes everything significantly clearer.

Omar Emara (OmarSquircleArt) added subscribers: Mike (MikeMS), Omar Emara (OmarSquircleArt).