Append: in localize All case, LibOverrides does not behave properly and will leave Main data in invalid state. #109004

New Issue

Benoit Alexis · 2023-06-15T11:41:39+02:00

Benoit Alexis commented

2023-06-15 11:41:39 +02:00

Problem

in Localize All case, append process does not handle LibOverride data properly currently: LibOverrides are kept as-is, but (some of) their dependencies may be made local directly. This leads to local liboverrides with local ID references, and/or linked data using local IDs...

Current append code relies on the premises that all newly linked data is made local. This is no longer applicable when linking liboverrides, since their linked references should never be made local (regardless of whether liboverrides themselves should be kept as liboverrides, or also be made fully local data).

Solving this issue is not trivial, and will require some careful thinking and design.

Solution Ideas

There are two possible ways to handle liboverrides when appending:

Remove them to get fully local data without any linked dependency.
Keep them as local liboverrides.

Currently, Blender tries to implement behavior 2. However, from a consistency and logical PoV, it would likely make more sense to rather go for behavior 1?

Regardless of the final outcome, Append process needs to be modified to take into account LibOverride data usages:

LibOverride reference pointers to linked data should not be ignored anymore.
These reference pointers should be handled in a specific way:
- They should never become local.
- Any data used by these linked reference must therefore be copied in case it needs to become local (and cannot be directly made local anymore).
- These liboverride reference linked IDs should never get their ID pointers remapped to local copies either.
If behavior 2 is kept, there is the complex topic of what to do with 'regular linked data` from appended liboverrides (e.g. a liboverride Object usually still uses a simple linked obdata ID, not a liboverride of its reference obdata)?
- This point alone is imho a strong reason to switch to behavior 1. Achieving proper consistency in behavior 2 feels simply impossible, even from a theoretical PoV.

Original Report

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 516.94

Blender Version
Broken: version: 3.6.0 Beta, branch: blender-v3.6-release, commit date: 2023-06-13 23:42, hash: 962331c256b0
Worked: (newest version of Blender that worked as expected)

Short description of error
Based on my experiments for #108967 I found a new crash in 3.6. Drag and dropping a specific collection asset from the asset browser in Append mode will cause a crash if this same collection asset was previously imported.
(duplicating the collection works fine, and link mode 'twice' does nothing but change the position of the previously imported collection).

Context about attached files:
The collection asset in "VP_Simulator" was dropped in "WUX450ST.blend" in linked mode, with Instance collection unckecked. Then I parented the "projector" to the object "wux450st" and put the asset collection in another collection which I made an asset.

Exact steps for others to reproduce the error

Add attached files in asset library
Open new scene
Append WUX450ST collection to the scene (uncheck instance from redo panel)
Append same collection again (crash(

No crash if I import the asset collection projector_sim in append mode

# Problem in `Localize All` case, append process does not handle LibOverride data properly currently: LibOverrides are kept as-is, but (some of) their dependencies may be made local directly. This leads to local liboverrides with local ID references, and/or linked data using local IDs... Current append code relies on the premises that _all_ newly linked data is made local. This is no longer applicable when linking liboverrides, since their linked references should never be made local (regardless of whether liboverrides themselves should be kept as liboverrides, or also be made fully local data). Solving this issue is not trivial, and will require some careful thinking and design. # Solution Ideas There are two possible ways to handle liboverrides when appending: 1. Remove them to get fully local data without any linked dependency. 2. Keep them as local liboverrides. Currently, Blender tries to implement behavior `2`. However, from a consistency and logical PoV, it would likely make more sense to rather go for behavior `1`? Regardless of the final outcome, Append process needs to be modified to take into account LibOverride data usages: * LibOverride reference pointers to linked data should not be ignored anymore. * These reference pointers should be handled in a specific way: * They should never become local. * Any data used by these linked reference must therefore be copied in case it needs to become local (and cannot be directly made local anymore). * These liboverride reference linked IDs should never get their ID pointers remapped to local copies either. * If behavior `2` is kept, there is the complex topic of what to do with 'regular linked data` from appended liboverrides (e.g. a liboverride Object usually still uses a simple linked obdata ID, not a liboverride of its reference obdata)? * _This point alone is imho a *strong* reason to switch to behavior `1`. Achieving proper consistency in behavior `2` feels simply impossible, even from a theoretical PoV._ --------------------------------- _Original Report_ **System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 516.94 **Blender Version** Broken: version: 3.6.0 Beta, branch: blender-v3.6-release, commit date: 2023-06-13 23:42, hash: `962331c256b0` Worked: (newest version of Blender that worked as expected) **Short description of error** Based on my experiments for #108967 I found a new crash in 3.6. Drag and dropping a specific collection asset from the asset browser in Append mode will cause a crash if this same collection asset was previously imported. (duplicating the collection works fine, and link mode 'twice' does nothing but change the position of the previously imported collection). Context about attached files: The collection asset in "VP_Simulator" was dropped in "WUX450ST.blend" in linked mode, with Instance collection unckecked. Then I parented the "projector" to the object "wux450st" and put the asset collection in another collection which I made an asset. **Exact steps for others to reproduce the error** - Add attached files in asset library - Open new scene - Append `WUX450ST` collection to the scene (uncheck `instance` from redo panel) - Append same collection again (crash( No crash if I import the asset collection `projector_sim` in append mode

WUX450ST-test.blend

1.2 MiB

blender.crash.txt

38 KiB

VP_Simulator - test.blend

1.1 MiB

Benoit Alexis added the

labels 2023-06-15 11:41:40 +02:00

Pratik Borhade commented

2023-06-16 05:56:05 +02:00

Thanks for the report. I can confirm the crash.

YimingWu commented

2023-06-16 05:56:06 +02:00

I am able to replicate the crash with following steps:

new file
Append asset Projector_Sim into the scene twice

Edit:

Can't replicate the crash in debugger...

I am able to replicate the crash with following steps: - new file - `Append` asset `Projector_Sim` into the scene twice Edit: Can't replicate the crash in debugger...

Pratik Borhade added

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Append: in localize All case, LibOverrides does not behave properly and will leave Main data in invalid state. #109004

Problem

Solution Ideas

Append: in `localize All` case, LibOverrides does not behave properly and will leave Main data in invalid state. #109004