Library Override: Change handling of Animation Data when it exists in both liboverride and linked reference IDs #110067

New Issue

Closed

opened 2023-07-13 17:46:24 +02:00 by Bastien Montagne · 4 comments

Bastien Montagne commented

2023-07-13 17:46:24 +02:00

Owner

In current Blender versions (up to 4.0 alpha) and since the beginning, when both the liboverride data-block and its linked reference have a (non -matching) AnimationData data, the animation data from the linked reference replaces the one from the liboverride.

This is typically a problem when the data initially linked and overridden have no animdata. Then when animation is created for the liboverride, a new, non-matching liboverride animdata is created. This data would then be lost if the linked data gets animated later on.

The proposal here is to reverse this behavior:

If a liboverride have animdata, always keep it.
This has potential complex side-effects:
- Part of the animdata items (e.g. the drivers) is not overridable currently, these would be reset regardless to the linked reference animdata.
- Some data (like the active action) would be kept.
- NLA behavior in that scenario is not clear currently (needs to be investigated/tried out further).

In current Blender versions (up to 4.0 alpha) and since the beginning, when both the liboverride data-block and its linked reference have a (non -matching) `AnimationData` data, the animation data from the linked reference replaces the one from the liboverride. This is typically a problem when the data initially linked and overridden have no animdata. Then when animation is created for the liboverride, a new, non-matching liboverride animdata is created. This data would then be lost if the linked data gets animated later on. The proposal here is to reverse this behavior: * If a liboverride have animdata, always keep it. * This has potential complex side-effects: * Part of the animdata items (e.g. the drivers) is not overridable currently, these would be reset regardless to the linked reference animdata. * Some data (like the active action) would be kept. * NLA behavior in that scenario is not clear currently (needs to be investigated/tried out further).

Bastien Montagne added this to the 4.0 milestone 2023-07-13 17:46:24 +02:00

Bastien Montagne added the

Animation & Rigging

labels 2023-07-13 17:46:25 +02:00

Bastien Montagne commented

2023-07-13 17:47:23 +02:00

Author

Owner

@SimonThommes @dr.sybren @nathanvegdahl Here is a task to keep track of this topic.

@SimonThommes @dr.sybren @nathanvegdahl Here is a task to keep track of this topic.

Sybren A. Stüvel commented

2023-07-25 12:46:23 +02:00

Member

Sorry for the delay. This was discussed in the 2023-07-13 Animation & Rigging module meeting.

The proposal here is to reverse this behavior: If a liboverride have animdata, always keep it.

👍 from the A&R module.

We got confused a bit about the drivers though:

Part of the animdata items (e.g. the drivers) is not overridable currently, these would be reset regardless to the linked reference animdata.

This sounds like the drivers in the library AnimData would effectively replace any drivers in the kept liboverride animdata. That would be the desirable outcome, as the drivers are typically seen as "part of the rig" and not something animators would add.

The confusion comes from our (Nathan's and my) understanding of what we discussed face-to-face before, that there would be a rather hard choice between "100% local AnimData" and "100% linked-in AnimData", which seems to differ from what you described above. Again, what you describe above is indeed desired, we just didn't think it would be (practically) possible without major work.

Sorry for the delay. This was discussed in [the 2023-07-13 Animation & Rigging module meeting](https://devtalk.blender.org/t/2023-07-13-animation-rigging-module-meeting/30261). > The proposal here is to reverse this behavior: If a liboverride have animdata, always keep it. :+1: from the A&R module. We got confused a bit about the drivers though: > Part of the animdata items (e.g. the drivers) is not overridable currently, these would be reset regardless to the linked reference animdata. This sounds like the drivers in the library `AnimData` would effectively replace any drivers in the kept liboverride animdata. That would be the desirable outcome, as the drivers are typically seen as "part of the rig" and not something animators would add. The confusion comes from our (Nathan's and my) understanding of what we discussed face-to-face before, that there would be a rather hard choice between "100% local `AnimData`" and "100% linked-in `AnimData`", which seems to differ from what you described above. Again, what you describe above is indeed desired, we just didn't think it would be (practically) possible without major work.

Bastien Montagne referenced this issue from a commit

2023-08-07 18:55:42 +02:00

LibOverride: Fix persistent override property in some RNA pointer cases.

Bastien Montagne referenced this issue

2023-08-07 19:05:01 +02:00

LibOverride: keep some anim data from liboverride when it exists in both IDs. #110900

Bastien Montagne commented

2023-08-07 19:17:30 +02:00

Author

Owner

This sounds like the drivers in the library AnimData would effectively replace any drivers in the kept liboverride animdata. That would be the desirable outcome, as the drivers are typically seen as "part of the rig" and not something animators would add.

This is the goal of the new behavior yes.

The confusion comes from our (Nathan's and my) understanding of what we discussed face-to-face before, that there would be a rather hard choice between "100% local AnimData" and "100% linked-in AnimData", which seems to differ from what you described above. Again, what you describe above is indeed desired, we just didn't think it would be (practically) possible without major work.

It is doable, but not with the default generic handling. It requires custom code and relying on complex subtleties of the liboverride apply & diffing code when it comes to RNA pointer properties.

Think the proposed patch (!110900) has the expected behavior, more testing on it is more than welcome!

> This sounds like the drivers in the library `AnimData` would effectively replace any drivers in the kept liboverride animdata. That would be the desirable outcome, as the drivers are typically seen as "part of the rig" and not something animators would add. This is the goal of the new behavior yes. > The confusion comes from our (Nathan's and my) understanding of what we discussed face-to-face before, that there would be a rather hard choice between "100% local `AnimData`" and "100% linked-in `AnimData`", which seems to differ from what you described above. Again, what you describe above is indeed desired, we just didn't think it would be (practically) possible without major work. It is doable, but not with the default generic handling. It requires custom code and relying on complex subtleties of the liboverride apply & diffing code when it comes to RNA pointer properties. Think the proposed patch (!110900) has the expected behavior, more testing on it is more than welcome!

Philipp Oeser referenced this issue from a commit

2023-08-09 14:34:41 +02:00

LibOverride: Fix persistent override property in some RNA pointer cases.

YimingWu referenced this issue

2023-08-14 10:47:35 +02:00

NLA editor: NLA strip disappears for linked armature #111103

Bastien Montagne referenced this issue from a commit

2023-08-15 16:06:16 +02:00

LibOverride: keep some anim data from liboverride when it exists in both IDs.

Bastien Montagne commented

2023-08-15 17:07:24 +02:00

Author

Owner

Implemented by f188d6709f, closing.

Implemented by f188d6709f, closing.

Bastien Montagne closed this issue

2023-08-15 17:07:27 +02:00

Blender Bot added the

label 2023-08-15 17:07:28 +02:00

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#110067

No description provided.