2022-02-11 09:07:11 +11:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup bke
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
*
|
2020-02-10 15:55:43 +01:00
|
|
|
* Contains management of ID's for remapping.
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
*/
|
|
|
|
|
|
2019-02-01 12:44:19 +11:00
|
|
|
#include "CLG_log.h"
|
|
|
|
|
|
2022-03-16 17:52:16 +01:00
|
|
|
#include "BLI_linklist.h"
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
#include "BLI_utildefines.h"
|
|
|
|
|
|
2020-12-15 10:47:58 +11:00
|
|
|
#include "DNA_collection_types.h"
|
2020-02-10 15:55:43 +01:00
|
|
|
#include "DNA_object_types.h"
|
|
|
|
|
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
#include "BKE_armature.h"
|
Render Layers and Collections (merge from render-layers)
Design Documents
----------------
* https://wiki.blender.org/index.php/Dev:2.8/Source/Layers
* https://wiki.blender.org/index.php/Dev:2.8/Source/DataDesignRevised
User Commit Log
---------------
* New Layer and Collection system to replace render layers and viewport layers.
* A layer is a set of collections of objects (and their drawing options) required for specific tasks.
* A collection is a set of objects, equivalent of the old layers in Blender. A collection can be shared across multiple layers.
* All Scenes have a master collection that all other collections are children of.
* New collection "context" tab (in Properties Editor)
* New temporary viewport "collections" panel to control per-collection
visibility
Missing User Features
---------------------
* Collection "Filter"
Option to add objects based on their names
* Collection Manager operators
The existing buttons are placeholders
* Collection Manager drawing
The editor main region is empty
* Collection Override
* Per-Collection engine settings
This will come as a separate commit, as part of the clay-engine branch
Dev Commit Log
--------------
* New DNA file (DNA_layer_types.h) with the new structs
We are replacing Base by a new extended Base while keeping it backward
compatible with some legacy settings (i.e., lay, flag_legacy).
Renamed all Base to BaseLegacy to make it clear the areas of code that
still need to be converted
Note: manual changes were required on - deg_builder_nodes.h, rna_object.c, KX_Light.cpp
* Unittesting for main syncronization requirements
- read, write, add/copy/remove objects, copy scene, collection
link/unlinking, context)
* New Editor: Collection Manager
Based on patch by Julian Eisel
This is extracted from the layer-manager branch. With the following changes:
- Renamed references of layer manager to collections manager
- I doesn't include the editors/space_collections/ draw and util files
- The drawing code itself will be implemented separately by Julian
* Base / Object:
A little note about them. Original Blender code would try to keep them
in sync through the code, juggling flags back and forth. This will now
be handled by Depsgraph, keeping Object and Bases more separated
throughout the non-rendering code.
Scene.base is being cleared in doversion, and the old viewport drawing
code was poorly converted to use the new bases while the new viewport
code doesn't get merged and replace the old one.
Python API Changes
------------------
```
- scene.layers
+ # no longer exists
- scene.objects
+ scene.scene_layers.active.objects
- scene.objects.active
+ scene.render_layers.active.objects.active
- bpy.context.scene.objects.link()
+ bpy.context.scene_collection.objects.link()
- bpy_extras.object_utils.object_data_add(context, obdata, operator=None, use_active_layer=True, name=None)
+ bpy_extras.object_utils.object_data_add(context, obdata, operator=None, name=None)
- bpy.context.object.select
+ bpy.context.object.select = True
+ bpy.context.object.select = False
+ bpy.context.object.select_get()
+ bpy.context.object.select_set(action='SELECT')
+ bpy.context.object.select_set(action='DESELECT')
-AddObjectHelper.layers
+ # no longer exists
```
2017-02-07 10:18:38 +01:00
|
|
|
#include "BKE_collection.h"
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
#include "BKE_curve.h"
|
2017-11-08 12:16:49 -02:00
|
|
|
#include "BKE_layer.h"
|
2020-02-10 12:58:59 +01:00
|
|
|
#include "BKE_lib_id.h"
|
|
|
|
|
#include "BKE_lib_query.h"
|
|
|
|
|
#include "BKE_lib_remap.h"
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
#include "BKE_main.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BKE_material.h"
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
#include "BKE_mball.h"
|
2016-07-08 15:16:45 +02:00
|
|
|
#include "BKE_modifier.h"
|
|
|
|
|
#include "BKE_multires.h"
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
#include "BKE_node.h"
|
|
|
|
|
#include "BKE_object.h"
|
2020-02-10 15:55:43 +01:00
|
|
|
|
2017-04-06 16:11:50 +02:00
|
|
|
#include "DEG_depsgraph.h"
|
|
|
|
|
#include "DEG_depsgraph_build.h"
|
|
|
|
|
|
2020-02-11 11:51:12 +11:00
|
|
|
#include "lib_intern.h" /* own include */
|
|
|
|
|
|
2020-02-10 16:30:41 +01:00
|
|
|
static CLG_LogRef LOG = {.identifier = "bke.lib_remap"};
|
2019-02-01 12:44:19 +11:00
|
|
|
|
2020-02-10 15:55:43 +01:00
|
|
|
BKE_library_free_notifier_reference_cb free_notifier_reference_cb = NULL;
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
|
|
|
|
|
void BKE_library_callback_free_notifier_reference_set(BKE_library_free_notifier_reference_cb func)
|
|
|
|
|
{
|
|
|
|
|
free_notifier_reference_cb = func;
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-10 15:55:43 +01:00
|
|
|
BKE_library_remap_editor_id_reference_cb remap_editor_id_reference_cb = NULL;
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
|
|
|
|
|
void BKE_library_callback_remap_editor_id_reference_set(
|
|
|
|
|
BKE_library_remap_editor_id_reference_cb func)
|
|
|
|
|
{
|
|
|
|
|
remap_editor_id_reference_cb = func;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
typedef struct IDRemap {
|
2022-02-11 14:53:08 +01:00
|
|
|
eIDRemapType type;
|
2016-09-22 14:57:16 +02:00
|
|
|
Main *bmain; /* Only used to trigger depsgraph updates in the right bmain. */
|
2022-02-11 14:53:08 +01:00
|
|
|
|
|
|
|
|
struct IDRemapper *id_remapper;
|
|
|
|
|
|
2019-04-21 13:44:06 +10:00
|
|
|
/** The ID in which we are replacing old_id by new_id usages. */
|
2020-03-11 12:37:25 +01:00
|
|
|
ID *id_owner;
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
short flag;
|
|
|
|
|
} IDRemap;
|
|
|
|
|
|
2020-02-10 12:58:59 +01:00
|
|
|
/* IDRemap->flag enums defined in BKE_lib.h */
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
|
2022-02-03 17:57:40 +01:00
|
|
|
static void foreach_libblock_remap_callback_skip(const ID *UNUSED(id_owner),
|
2022-02-11 14:53:08 +01:00
|
|
|
ID **id_ptr,
|
2022-01-14 15:48:57 +01:00
|
|
|
const int cb_flag,
|
|
|
|
|
const bool is_indirect,
|
|
|
|
|
const bool is_reference,
|
2022-02-09 11:44:14 +01:00
|
|
|
const bool violates_never_null,
|
2022-02-03 17:57:40 +01:00
|
|
|
const bool UNUSED(is_obj),
|
2022-01-14 15:48:57 +01:00
|
|
|
const bool is_obj_editmode)
|
|
|
|
|
{
|
2022-02-11 14:53:08 +01:00
|
|
|
ID *id = *id_ptr;
|
|
|
|
|
BLI_assert(id != NULL);
|
2022-05-17 15:08:18 +02:00
|
|
|
|
2022-01-14 15:48:57 +01:00
|
|
|
if (is_indirect) {
|
2022-02-11 14:53:08 +01:00
|
|
|
id->runtime.remap.skipped_indirect++;
|
2022-01-14 15:48:57 +01:00
|
|
|
}
|
2022-02-09 11:44:14 +01:00
|
|
|
else if (violates_never_null || is_obj_editmode || is_reference) {
|
2022-02-11 14:53:08 +01:00
|
|
|
id->runtime.remap.skipped_direct++;
|
2022-01-14 15:48:57 +01:00
|
|
|
}
|
|
|
|
|
else {
|
2022-05-17 15:08:18 +02:00
|
|
|
BLI_assert_unreachable();
|
2022-01-14 15:48:57 +01:00
|
|
|
}
|
2022-05-17 15:08:18 +02:00
|
|
|
|
2022-01-14 15:48:57 +01:00
|
|
|
if (cb_flag & IDWALK_CB_USER) {
|
2022-02-11 14:53:08 +01:00
|
|
|
id->runtime.remap.skipped_refcounted++;
|
2022-01-14 15:48:57 +01:00
|
|
|
}
|
|
|
|
|
else if (cb_flag & IDWALK_CB_USER_ONE) {
|
|
|
|
|
/* No need to count number of times this happens, just a flag is enough. */
|
2022-02-11 14:53:08 +01:00
|
|
|
id->runtime.remap.status |= ID_REMAP_IS_USER_ONE_SKIPPED;
|
2022-01-14 15:48:57 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void foreach_libblock_remap_callback_apply(ID *id_owner,
|
|
|
|
|
ID *id_self,
|
|
|
|
|
ID **id_ptr,
|
|
|
|
|
IDRemap *id_remap_data,
|
2022-02-11 14:53:08 +01:00
|
|
|
const struct IDRemapper *mappings,
|
|
|
|
|
const IDRemapperApplyOptions id_remapper_options,
|
2022-01-14 15:48:57 +01:00
|
|
|
const int cb_flag,
|
|
|
|
|
const bool is_indirect,
|
2022-02-09 11:44:14 +01:00
|
|
|
const bool violates_never_null,
|
2022-02-03 17:57:40 +01:00
|
|
|
const bool force_user_refcount)
|
2022-01-14 15:48:57 +01:00
|
|
|
{
|
2022-02-11 14:53:08 +01:00
|
|
|
ID *old_id = *id_ptr;
|
2022-02-09 11:44:14 +01:00
|
|
|
if (!violates_never_null) {
|
2022-02-11 14:53:08 +01:00
|
|
|
BKE_id_remapper_apply_ex(mappings, id_ptr, id_remapper_options, id_self);
|
2022-01-14 15:48:57 +01:00
|
|
|
DEG_id_tag_update_ex(id_remap_data->bmain,
|
|
|
|
|
id_self,
|
|
|
|
|
ID_RECALC_COPY_ON_WRITE | ID_RECALC_TRANSFORM | ID_RECALC_GEOMETRY);
|
|
|
|
|
if (id_self != id_owner) {
|
|
|
|
|
DEG_id_tag_update_ex(id_remap_data->bmain,
|
|
|
|
|
id_owner,
|
|
|
|
|
ID_RECALC_COPY_ON_WRITE | ID_RECALC_TRANSFORM | ID_RECALC_GEOMETRY);
|
|
|
|
|
}
|
|
|
|
|
}
|
2022-02-11 14:53:08 +01:00
|
|
|
/* Get the new_id pointer. When the mapping is violating never null we should use a NULL
|
|
|
|
|
* pointer otherwise the incorrect users are decreased and increased on the same instance. */
|
|
|
|
|
ID *new_id = violates_never_null ? NULL : *id_ptr;
|
|
|
|
|
|
2022-01-14 15:48:57 +01:00
|
|
|
if (cb_flag & IDWALK_CB_USER) {
|
|
|
|
|
/* NOTE: by default we don't user-count IDs which are not in the main database.
|
|
|
|
|
* This is because in certain conditions we can have data-blocks in
|
|
|
|
|
* the main which are referencing data-blocks outside of it.
|
|
|
|
|
* For example, BKE_mesh_new_from_object() called on an evaluated
|
|
|
|
|
* object will cause such situation.
|
|
|
|
|
*/
|
|
|
|
|
if (force_user_refcount || (old_id->tag & LIB_TAG_NO_MAIN) == 0) {
|
|
|
|
|
id_us_min(old_id);
|
|
|
|
|
}
|
|
|
|
|
if (new_id != NULL && (force_user_refcount || (new_id->tag & LIB_TAG_NO_MAIN) == 0)) {
|
2022-04-29 16:33:48 +02:00
|
|
|
/* Do not handle LIB_TAG_INDIRECT/LIB_TAG_EXTERN here. */
|
|
|
|
|
id_us_plus_no_lib(new_id);
|
2022-01-14 15:48:57 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (cb_flag & IDWALK_CB_USER_ONE) {
|
|
|
|
|
id_us_ensure_real(new_id);
|
|
|
|
|
/* We cannot affect old_id->us directly, LIB_TAG_EXTRAUSER(_SET)
|
|
|
|
|
* are assumed to be set as needed, that extra user is processed in final handling. */
|
|
|
|
|
}
|
2022-02-11 14:53:08 +01:00
|
|
|
if (!is_indirect && new_id) {
|
|
|
|
|
new_id->runtime.remap.status |= ID_REMAP_IS_LINKED_DIRECT;
|
2022-01-14 15:48:57 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-13 12:56:10 +01:00
|
|
|
static int foreach_libblock_remap_callback(LibraryIDLinkCallbackData *cb_data)
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
{
|
2020-02-13 12:56:10 +01:00
|
|
|
const int cb_flag = cb_data->cb_flag;
|
|
|
|
|
|
2020-03-11 12:47:25 +01:00
|
|
|
if (cb_flag & IDWALK_CB_EMBEDDED) {
|
2017-01-30 21:34:23 +01:00
|
|
|
return IDWALK_RET_NOP;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-03-11 12:37:25 +01:00
|
|
|
ID *id_owner = cb_data->id_owner;
|
2020-02-13 12:56:10 +01:00
|
|
|
ID *id_self = cb_data->id_self;
|
|
|
|
|
ID **id_p = cb_data->id_pointer;
|
|
|
|
|
IDRemap *id_remap_data = cb_data->user_data;
|
2020-03-11 12:37:25 +01:00
|
|
|
|
2020-03-11 17:29:20 +01:00
|
|
|
/* Those asserts ensure the general sanity of ID tags regarding 'embedded' ID data (root
|
|
|
|
|
* nodetrees and co). */
|
2020-03-11 12:37:25 +01:00
|
|
|
BLI_assert(id_owner == id_remap_data->id_owner);
|
2020-03-11 12:47:25 +01:00
|
|
|
BLI_assert(id_self == id_owner || (id_self->flag & LIB_EMBEDDED_DATA) != 0);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-02-11 14:53:08 +01:00
|
|
|
/* Early exit when id pointer isn't set. */
|
|
|
|
|
if (*id_p == NULL) {
|
|
|
|
|
return IDWALK_RET_NOP;
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-02-11 14:53:08 +01:00
|
|
|
struct IDRemapper *id_remapper = id_remap_data->id_remapper;
|
|
|
|
|
IDRemapperApplyOptions id_remapper_options = ID_REMAP_APPLY_DEFAULT;
|
|
|
|
|
|
|
|
|
|
/* Used to cleanup all IDs used by a specific one. */
|
|
|
|
|
if (id_remap_data->type == ID_REMAP_TYPE_CLEANUP) {
|
|
|
|
|
/* Clearing existing instance to reduce potential lookup times for IDs referencing many other
|
|
|
|
|
* IDs. This makes sure that there will only be a single rule in the id_remapper. */
|
|
|
|
|
BKE_id_remapper_clear(id_remapper);
|
|
|
|
|
BKE_id_remapper_add(id_remapper, *id_p, NULL);
|
2022-01-14 09:55:35 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-01-14 09:55:35 +01:00
|
|
|
/* Better remap to NULL than not remapping at all,
|
|
|
|
|
* then we can handle it as a regular remap-to-NULL case. */
|
2022-02-11 14:53:08 +01:00
|
|
|
if ((cb_flag & IDWALK_CB_NEVER_SELF)) {
|
|
|
|
|
id_remapper_options |= ID_REMAP_APPLY_UNMAP_WHEN_REMAPPING_TO_SELF;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const IDRemapperApplyResult expected_mapping_result = BKE_id_remapper_get_mapping_result(
|
|
|
|
|
id_remapper, *id_p, id_remapper_options, id_self);
|
|
|
|
|
/* Exit, when no modifications will be done; ensuring id->runtime counters won't changed. */
|
|
|
|
|
if (ELEM(expected_mapping_result,
|
|
|
|
|
ID_REMAP_RESULT_SOURCE_UNAVAILABLE,
|
|
|
|
|
ID_REMAP_RESULT_SOURCE_NOT_MAPPABLE)) {
|
|
|
|
|
BLI_assert_msg(id_remap_data->type == ID_REMAP_TYPE_REMAP,
|
|
|
|
|
"Cleanup should always do unassign.");
|
|
|
|
|
return IDWALK_RET_NOP;
|
2022-01-14 09:55:35 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const bool is_reference = (cb_flag & IDWALK_CB_OVERRIDE_LIBRARY_REFERENCE) != 0;
|
|
|
|
|
const bool is_indirect = (cb_flag & IDWALK_CB_INDIRECT_USAGE) != 0;
|
|
|
|
|
const bool skip_indirect = (id_remap_data->flag & ID_REMAP_SKIP_INDIRECT_USAGE) != 0;
|
|
|
|
|
const bool is_obj = (GS(id_owner->name) == ID_OB);
|
2022-02-03 17:57:40 +01:00
|
|
|
/* NOTE: Edit Mode is a 'skip direct' case, unless specifically requested, obdata should not be
|
|
|
|
|
* remapped in this situation. */
|
2022-01-14 09:55:35 +01:00
|
|
|
const bool is_obj_editmode = (is_obj && BKE_object_is_in_editmode((Object *)id_owner) &&
|
|
|
|
|
(id_remap_data->flag & ID_REMAP_FORCE_OBDATA_IN_EDITMODE) == 0);
|
2022-02-11 14:53:08 +01:00
|
|
|
const bool violates_never_null = ((cb_flag & IDWALK_CB_NEVER_NULL) &&
|
|
|
|
|
(expected_mapping_result ==
|
|
|
|
|
ID_REMAP_RESULT_SOURCE_UNASSIGNED) &&
|
2022-02-09 11:44:14 +01:00
|
|
|
(id_remap_data->flag & ID_REMAP_FORCE_NEVER_NULL_USAGE) == 0);
|
2022-01-14 09:55:35 +01:00
|
|
|
const bool skip_reference = (id_remap_data->flag & ID_REMAP_SKIP_OVERRIDE_LIBRARY) != 0;
|
|
|
|
|
const bool skip_never_null = (id_remap_data->flag & ID_REMAP_SKIP_NEVER_NULL_USAGE) != 0;
|
|
|
|
|
const bool force_user_refcount = (id_remap_data->flag & ID_REMAP_FORCE_USER_REFCOUNT) != 0;
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
|
"Fix" crash when deleting linked object which has indirect usages.
This is in fact very hairy situation here... Objects are only refcounted by scenes,
any other usage is 'free', which means once all object instanciations are gone Blender
considers it can delete it.
There is a trap here though: indirect usages. Typically, we should never modify linked data
(because it is essencially useless, changes would be ignored and ost on next reload or
even undo/redo). This means indirect usages are not affected by default 'safe' remapping/unlinking.
For unlinking preceeding deletion however, this is not acceptable - we are likely to end with
a zero-user ID (aka deletable one) which is still actually used by other linked data.
Solution choosen here is double:
I) From 'user-space' (i.e. outliner, operators...), we check for cases where deleting datablocks
should not be allowed (indirect data or indirectly used data), and abort (with report) if needed.
II) From 'lower' level (BKE_library_remap and RNA), we also unlink from linked data,
which makes actual deletion possible and safe.
Note that with previous behavior (2.77 one), linked object would be deleted, including from linked data -
but then, once file is saved and reloaded, indirect usage would link back the deleted object,
without any instanciation in scene, which made it somehow virtual and unreachable...
With new behavior, this is no more possible, but on the other hand it means that in situations of dependency cycles
(two linked objects using each other), linked objects become impossible to delete (from user space).
Not sure what's best here, behavior with those corner cases of library linking is very poorly defined... :(
2016-07-01 17:51:08 +02:00
|
|
|
#ifdef DEBUG_PRINT
|
2022-01-14 09:55:35 +01:00
|
|
|
printf(
|
2022-02-11 14:53:08 +01:00
|
|
|
"In %s (lib %p): Remapping %s (%p) remap operation: %s "
|
2022-01-14 09:55:35 +01:00
|
|
|
"(is_indirect: %d, skip_indirect: %d, is_reference: %d, skip_reference: %d)\n",
|
2022-02-11 14:53:08 +01:00
|
|
|
id_owner->name,
|
|
|
|
|
id_owner->lib,
|
|
|
|
|
(*id_p)->name,
|
|
|
|
|
*id_p,
|
|
|
|
|
BKE_id_remapper_result_string(expected_mapping_result),
|
2022-01-14 09:55:35 +01:00
|
|
|
is_indirect,
|
|
|
|
|
skip_indirect,
|
|
|
|
|
is_reference,
|
|
|
|
|
skip_reference);
|
"Fix" crash when deleting linked object which has indirect usages.
This is in fact very hairy situation here... Objects are only refcounted by scenes,
any other usage is 'free', which means once all object instanciations are gone Blender
considers it can delete it.
There is a trap here though: indirect usages. Typically, we should never modify linked data
(because it is essencially useless, changes would be ignored and ost on next reload or
even undo/redo). This means indirect usages are not affected by default 'safe' remapping/unlinking.
For unlinking preceeding deletion however, this is not acceptable - we are likely to end with
a zero-user ID (aka deletable one) which is still actually used by other linked data.
Solution choosen here is double:
I) From 'user-space' (i.e. outliner, operators...), we check for cases where deleting datablocks
should not be allowed (indirect data or indirectly used data), and abort (with report) if needed.
II) From 'lower' level (BKE_library_remap and RNA), we also unlink from linked data,
which makes actual deletion possible and safe.
Note that with previous behavior (2.77 one), linked object would be deleted, including from linked data -
but then, once file is saved and reloaded, indirect usage would link back the deleted object,
without any instanciation in scene, which made it somehow virtual and unreachable...
With new behavior, this is no more possible, but on the other hand it means that in situations of dependency cycles
(two linked objects using each other), linked objects become impossible to delete (from user space).
Not sure what's best here, behavior with those corner cases of library linking is very poorly defined... :(
2016-07-01 17:51:08 +02:00
|
|
|
#endif
|
|
|
|
|
|
2022-01-14 09:55:35 +01:00
|
|
|
if ((id_remap_data->flag & ID_REMAP_FLAG_NEVER_NULL_USAGE) && (cb_flag & IDWALK_CB_NEVER_NULL)) {
|
|
|
|
|
id_owner->tag |= LIB_TAG_DOIT;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-01-14 09:55:35 +01:00
|
|
|
/* Special hack in case it's Object->data and we are in edit mode, and new_id is not NULL
|
|
|
|
|
* (otherwise, we follow common NEVER_NULL flags).
|
|
|
|
|
* (skipped_indirect too). */
|
2022-02-09 11:44:14 +01:00
|
|
|
if ((violates_never_null && skip_never_null) ||
|
2022-02-11 14:53:08 +01:00
|
|
|
(is_obj_editmode && (((Object *)id_owner)->data == *id_p) &&
|
|
|
|
|
(expected_mapping_result == ID_REMAP_RESULT_SOURCE_REMAPPED)) ||
|
2022-01-14 09:55:35 +01:00
|
|
|
(skip_indirect && is_indirect) || (is_reference && skip_reference)) {
|
2022-01-14 15:48:57 +01:00
|
|
|
foreach_libblock_remap_callback_skip(id_owner,
|
|
|
|
|
id_p,
|
|
|
|
|
cb_flag,
|
|
|
|
|
is_indirect,
|
|
|
|
|
is_reference,
|
2022-02-09 11:44:14 +01:00
|
|
|
violates_never_null,
|
2022-01-14 15:48:57 +01:00
|
|
|
is_obj,
|
|
|
|
|
is_obj_editmode);
|
2022-01-14 09:55:35 +01:00
|
|
|
}
|
|
|
|
|
else {
|
2022-01-14 15:48:57 +01:00
|
|
|
foreach_libblock_remap_callback_apply(id_owner,
|
|
|
|
|
id_self,
|
|
|
|
|
id_p,
|
|
|
|
|
id_remap_data,
|
2022-02-11 14:53:08 +01:00
|
|
|
id_remapper,
|
|
|
|
|
id_remapper_options,
|
2022-01-14 15:48:57 +01:00
|
|
|
cb_flag,
|
|
|
|
|
is_indirect,
|
2022-02-09 11:44:14 +01:00
|
|
|
violates_never_null,
|
2022-02-03 17:57:40 +01:00
|
|
|
force_user_refcount);
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
return IDWALK_RET_NOP;
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-11 14:53:08 +01:00
|
|
|
static void libblock_remap_data_preprocess_ob(Object *ob,
|
|
|
|
|
eIDRemapType remap_type,
|
|
|
|
|
const struct IDRemapper *id_remapper)
|
|
|
|
|
{
|
|
|
|
|
if (ob->type != OB_ARMATURE) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (ob->pose == NULL) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const bool is_cleanup_type = remap_type == ID_REMAP_TYPE_CLEANUP;
|
|
|
|
|
/* Early exit when mapping, but no armature mappings present. */
|
|
|
|
|
if (!is_cleanup_type && !BKE_id_remapper_has_mapping_for(id_remapper, FILTER_ID_AR)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Object's pose holds reference to armature bones. sic */
|
|
|
|
|
/* Note that in theory, we should have to bother about linked/non-linked/never-null/etc.
|
|
|
|
|
* flags/states.
|
|
|
|
|
* Fortunately, this is just a tag, so we can accept to 'over-tag' a bit for pose recalc,
|
|
|
|
|
* and avoid another complex and risky condition nightmare like the one we have in
|
|
|
|
|
* foreach_libblock_remap_callback(). */
|
|
|
|
|
const IDRemapperApplyResult expected_mapping_result = BKE_id_remapper_get_mapping_result(
|
|
|
|
|
id_remapper, ob->data, ID_REMAP_APPLY_DEFAULT, NULL);
|
|
|
|
|
if (is_cleanup_type || expected_mapping_result == ID_REMAP_RESULT_SOURCE_REMAPPED) {
|
|
|
|
|
ob->pose->flag |= POSE_RECALC;
|
|
|
|
|
/* We need to clear pose bone pointers immediately, some code may access those before
|
|
|
|
|
* pose is actually recomputed, which can lead to segfault. */
|
|
|
|
|
BKE_pose_clear_pointers(ob->pose);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void libblock_remap_data_preprocess(ID *id_owner,
|
|
|
|
|
eIDRemapType remap_type,
|
|
|
|
|
const struct IDRemapper *id_remapper)
|
2016-07-08 13:22:54 +02:00
|
|
|
{
|
2022-02-11 14:53:08 +01:00
|
|
|
switch (GS(id_owner->name)) {
|
2016-07-08 13:22:54 +02:00
|
|
|
case ID_OB: {
|
2022-02-11 14:53:08 +01:00
|
|
|
Object *ob = (Object *)id_owner;
|
|
|
|
|
libblock_remap_data_preprocess_ob(ob, remap_type, id_remapper);
|
2016-07-08 13:22:54 +02:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-27 12:07:07 +10:00
|
|
|
/**
|
|
|
|
|
* Can be called with both old_ob and new_ob being NULL,
|
|
|
|
|
* this means we have to check whole Main database then.
|
|
|
|
|
*/
|
2017-08-10 12:32:50 +02:00
|
|
|
static void libblock_remap_data_postprocess_object_update(Main *bmain,
|
|
|
|
|
Object *old_ob,
|
2022-04-12 18:16:46 +02:00
|
|
|
Object *new_ob,
|
|
|
|
|
const bool do_sync_collection)
|
2016-07-08 13:22:54 +02:00
|
|
|
{
|
Collections and groups unification
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383
https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
|
|
|
if (new_ob == NULL) {
|
2018-10-21 17:20:17 +02:00
|
|
|
/* In case we unlinked old_ob (new_ob is NULL), the object has already
|
|
|
|
|
* been removed from the scenes and their collections. We still have
|
|
|
|
|
* to remove the NULL children from collections not used in any scene. */
|
Collections and groups unification
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383
https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
|
|
|
BKE_collections_object_remove_nulls(bmain);
|
2016-07-08 13:22:54 +02:00
|
|
|
}
|
2021-12-22 16:57:07 +01:00
|
|
|
else {
|
|
|
|
|
/* Remapping may have created duplicates of CollectionObject pointing to the same object within
|
|
|
|
|
* the same collection. */
|
|
|
|
|
BKE_collections_object_remove_duplicates(bmain);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-04-12 18:16:46 +02:00
|
|
|
if (do_sync_collection) {
|
|
|
|
|
BKE_main_collection_sync_remap(bmain);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-10-21 17:20:17 +02:00
|
|
|
if (old_ob == NULL) {
|
2019-03-08 09:29:17 +11:00
|
|
|
for (Object *ob = bmain->objects.first; ob != NULL; ob = ob->id.next) {
|
2018-10-21 17:20:17 +02:00
|
|
|
if (ob->type == OB_MBALL && BKE_mball_is_basis(ob)) {
|
2018-12-06 17:52:37 +01:00
|
|
|
DEG_id_tag_update(&ob->id, ID_RECALC_GEOMETRY);
|
2018-10-21 17:20:17 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
2019-03-08 09:29:17 +11:00
|
|
|
for (Object *ob = bmain->objects.first; ob != NULL; ob = ob->id.next) {
|
2017-08-10 12:32:50 +02:00
|
|
|
if (ob->type == OB_MBALL && BKE_mball_is_basis_for(ob, old_ob)) {
|
2018-12-06 17:52:37 +01:00
|
|
|
DEG_id_tag_update(&ob->id, ID_RECALC_GEOMETRY);
|
2018-10-21 17:20:17 +02:00
|
|
|
break; /* There is only one basis... */
|
2017-08-10 12:32:50 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-07-08 13:22:54 +02:00
|
|
|
}
|
|
|
|
|
|
2018-10-21 17:20:17 +02:00
|
|
|
/* Can be called with both old_collection and new_collection being NULL,
|
|
|
|
|
* this means we have to check whole Main database then. */
|
|
|
|
|
static void libblock_remap_data_postprocess_collection_update(Main *bmain,
|
2021-04-23 12:28:54 +02:00
|
|
|
Collection *owner_collection,
|
2018-11-10 16:22:41 +01:00
|
|
|
Collection *UNUSED(old_collection),
|
|
|
|
|
Collection *new_collection)
|
2016-07-08 13:22:54 +02:00
|
|
|
{
|
Collections and groups unification
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383
https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
|
|
|
if (new_collection == NULL) {
|
2018-11-10 16:22:41 +01:00
|
|
|
/* XXX Complex cases can lead to NULL pointers in other collections than old_collection,
|
2019-04-27 12:07:07 +10:00
|
|
|
* and BKE_main_collection_sync_remap() does not tolerate any of those, so for now always check
|
|
|
|
|
* whole existing collections for NULL pointers.
|
2021-07-03 23:08:40 +10:00
|
|
|
* I'd consider optimizing that whole collection remapping process a TODO: for later. */
|
2021-04-23 12:28:54 +02:00
|
|
|
BKE_collections_child_remove_nulls(bmain, owner_collection, NULL /*old_collection*/);
|
Collections and groups unification
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383
https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
|
|
|
}
|
2019-05-22 22:57:16 +02:00
|
|
|
else {
|
|
|
|
|
/* Temp safe fix, but a "tad" brute force... We should probably be able to use parents from
|
|
|
|
|
* old_collection instead? */
|
2021-12-22 16:57:07 +01:00
|
|
|
/* NOTE: Also takes care of duplicated child collections that remapping may have created. */
|
2019-05-22 22:57:16 +02:00
|
|
|
BKE_main_collections_parent_relations_rebuild(bmain);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-09-10 16:06:58 +02:00
|
|
|
BKE_main_collection_sync_remap(bmain);
|
2016-07-08 13:22:54 +02:00
|
|
|
}
|
|
|
|
|
|
2018-05-29 15:49:21 +02:00
|
|
|
static void libblock_remap_data_postprocess_obdata_relink(Main *bmain, Object *ob, ID *new_id)
|
2016-07-08 15:16:45 +02:00
|
|
|
{
|
|
|
|
|
if (ob->data == new_id) {
|
|
|
|
|
switch (GS(new_id->name)) {
|
|
|
|
|
case ID_ME:
|
2019-09-17 17:24:44 +02:00
|
|
|
multires_force_sculpt_rebuild(ob);
|
2016-07-08 15:16:45 +02:00
|
|
|
break;
|
2022-02-18 09:50:29 -06:00
|
|
|
case ID_CU_LEGACY:
|
2016-07-08 15:16:45 +02:00
|
|
|
BKE_curve_type_test(ob);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
2020-05-08 10:14:02 +02:00
|
|
|
BKE_modifiers_test_object(ob);
|
2020-02-05 11:23:58 +01:00
|
|
|
BKE_object_materials_test(bmain, ob, new_id);
|
2016-07-08 15:16:45 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-19 12:20:29 +01:00
|
|
|
static void libblock_remap_data_postprocess_nodetree_update(Main *bmain, ID *new_id)
|
|
|
|
|
{
|
2019-04-20 20:25:22 +02:00
|
|
|
/* Update all group nodes using a node group. */
|
2021-12-21 15:18:56 +01:00
|
|
|
ntreeUpdateAllUsers(bmain, new_id);
|
2016-11-19 12:20:29 +01:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 14:53:08 +01:00
|
|
|
static void libblock_remap_data_update_tags(ID *old_id, ID *new_id, void *user_data)
|
|
|
|
|
{
|
|
|
|
|
IDRemap *id_remap_data = user_data;
|
|
|
|
|
const int remap_flags = id_remap_data->flag;
|
|
|
|
|
if ((remap_flags & ID_REMAP_SKIP_USER_CLEAR) == 0) {
|
|
|
|
|
/* XXX We may not want to always 'transfer' fake-user from old to new id...
|
|
|
|
|
* Think for now it's desired behavior though,
|
|
|
|
|
* we can always add an option (flag) to control this later if needed. */
|
2022-05-02 15:54:15 +02:00
|
|
|
if (old_id != NULL && (old_id->flag & LIB_FAKEUSER) && new_id != NULL) {
|
2022-02-11 14:53:08 +01:00
|
|
|
id_fake_user_clear(old_id);
|
|
|
|
|
id_fake_user_set(new_id);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
id_us_clear_real(old_id);
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-02 15:54:15 +02:00
|
|
|
if (new_id != NULL && (new_id->tag & LIB_TAG_INDIRECT) &&
|
2022-02-11 14:53:08 +01:00
|
|
|
(new_id->runtime.remap.status & ID_REMAP_IS_LINKED_DIRECT)) {
|
|
|
|
|
new_id->tag &= ~LIB_TAG_INDIRECT;
|
|
|
|
|
new_id->flag &= ~LIB_INDIRECT_WEAK_LINK;
|
|
|
|
|
new_id->tag |= LIB_TAG_EXTERN;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void libblock_remap_reset_remapping_status_callback(ID *old_id,
|
|
|
|
|
ID *UNUSED(new_id),
|
|
|
|
|
void *UNUSED(user_data))
|
|
|
|
|
{
|
|
|
|
|
BKE_libblock_runtime_reset_remapping_status(old_id);
|
|
|
|
|
}
|
|
|
|
|
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
/**
|
2019-06-12 09:04:10 +10:00
|
|
|
* Execute the 'data' part of the remapping (that is, all ID pointers from other ID data-blocks).
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
*
|
|
|
|
|
* Behavior differs depending on whether given \a id is NULL or not:
|
|
|
|
|
* - \a id NULL: \a old_id must be non-NULL, \a new_id may be NULL (unlinking \a old_id) or not
|
2019-04-27 12:07:07 +10:00
|
|
|
* (remapping \a old_id to \a new_id).
|
|
|
|
|
* The whole \a bmain database is checked, and all pointers to \a old_id
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
* are remapped to \a new_id.
|
|
|
|
|
* - \a id is non-NULL:
|
2019-04-27 12:07:07 +10:00
|
|
|
* + If \a old_id is NULL, \a new_id must also be NULL,
|
|
|
|
|
* and all ID pointers from \a id are cleared
|
2019-06-12 09:04:10 +10:00
|
|
|
* (i.e. \a id does not references any other data-block anymore).
|
2016-09-22 14:57:16 +02:00
|
|
|
* + If \a old_id is non-NULL, behavior is as with a NULL \a id, but only within given \a id.
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
*
|
2016-09-22 14:57:16 +02:00
|
|
|
* \param bmain: the Main data storage to operate on (must never be NULL).
|
2019-06-12 09:04:10 +10:00
|
|
|
* \param id: the data-block to operate on
|
2019-04-27 12:07:07 +10:00
|
|
|
* (can be NULL, in which case we operate over all IDs from given bmain).
|
2019-06-12 09:04:10 +10:00
|
|
|
* \param old_id: the data-block to dereference (may be NULL if \a id is non-NULL).
|
|
|
|
|
* \param new_id: the new data-block to replace \a old_id references with (may be NULL).
|
2019-04-27 12:07:07 +10:00
|
|
|
* \param r_id_remap_data: if non-NULL, the IDRemap struct to use
|
2022-06-07 14:53:20 +10:00
|
|
|
* (useful to retrieve info about remapping process).
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
*/
|
2016-09-22 14:57:16 +02:00
|
|
|
ATTR_NONNULL(1)
|
2022-02-11 14:53:08 +01:00
|
|
|
static void libblock_remap_data(Main *bmain,
|
|
|
|
|
ID *id,
|
|
|
|
|
eIDRemapType remap_type,
|
|
|
|
|
struct IDRemapper *id_remapper,
|
|
|
|
|
const short remap_flags)
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
{
|
2022-02-11 14:53:08 +01:00
|
|
|
IDRemap id_remap_data = {0};
|
2022-02-03 17:57:40 +01:00
|
|
|
const int foreach_id_flags = ((remap_flags & ID_REMAP_FORCE_INTERNAL_RUNTIME_POINTERS) != 0 ?
|
2021-03-12 09:41:00 +01:00
|
|
|
IDWALK_DO_INTERNAL_RUNTIME_POINTERS :
|
|
|
|
|
IDWALK_NOP);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-02-11 14:53:08 +01:00
|
|
|
id_remap_data.id_remapper = id_remapper;
|
|
|
|
|
id_remap_data.type = remap_type;
|
|
|
|
|
id_remap_data.bmain = bmain;
|
|
|
|
|
id_remap_data.id_owner = NULL;
|
|
|
|
|
id_remap_data.flag = remap_flags;
|
|
|
|
|
|
|
|
|
|
BKE_id_remapper_iter(id_remapper, libblock_remap_reset_remapping_status_callback, NULL);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
if (id) {
|
|
|
|
|
#ifdef DEBUG_PRINT
|
|
|
|
|
printf("\tchecking id %s (%p, %p)\n", id->name, id, id->lib);
|
|
|
|
|
#endif
|
2022-02-11 14:53:08 +01:00
|
|
|
id_remap_data.id_owner = id;
|
|
|
|
|
libblock_remap_data_preprocess(id_remap_data.id_owner, remap_type, id_remapper);
|
2017-06-26 18:55:30 +02:00
|
|
|
BKE_library_foreach_ID_link(
|
2022-02-11 14:53:08 +01:00
|
|
|
NULL, id, foreach_libblock_remap_callback, &id_remap_data, foreach_id_flags);
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
}
|
|
|
|
|
else {
|
2019-04-27 12:07:07 +10:00
|
|
|
/* Note that this is a very 'brute force' approach,
|
|
|
|
|
* maybe we could use some depsgraph to only process objects actually using given old_id...
|
|
|
|
|
* sounds rather unlikely currently, though, so this will do for now. */
|
2019-02-18 16:15:14 +01:00
|
|
|
ID *id_curr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-21 04:40:16 +10:00
|
|
|
FOREACH_MAIN_ID_BEGIN (bmain, id_curr) {
|
2022-02-11 14:53:08 +01:00
|
|
|
const uint64_t can_use_filter_id = BKE_library_id_can_use_filter_id(id_curr);
|
|
|
|
|
const bool has_mapping = BKE_id_remapper_has_mapping_for(id_remapper, can_use_filter_id);
|
|
|
|
|
|
|
|
|
|
/* Continue when id_remapper doesn't have any mappings that can be used by id_curr. */
|
|
|
|
|
if (!has_mapping) {
|
|
|
|
|
continue;
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-02-11 14:53:08 +01:00
|
|
|
/* Note that we cannot skip indirect usages of old_id
|
|
|
|
|
* here (if requested), we still need to check it for the
|
|
|
|
|
* user count handling...
|
|
|
|
|
* XXX No more true (except for debug usage of those
|
|
|
|
|
* skipping counters). */
|
|
|
|
|
id_remap_data.id_owner = id_curr;
|
|
|
|
|
libblock_remap_data_preprocess(id_remap_data.id_owner, remap_type, id_remapper);
|
|
|
|
|
BKE_library_foreach_ID_link(
|
|
|
|
|
NULL, id_curr, foreach_libblock_remap_callback, &id_remap_data, foreach_id_flags);
|
2021-03-12 00:34:23 +11:00
|
|
|
}
|
2022-02-11 14:53:08 +01:00
|
|
|
FOREACH_MAIN_ID_END;
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 14:53:08 +01:00
|
|
|
BKE_id_remapper_iter(id_remapper, libblock_remap_data_update_tags, &id_remap_data);
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
}
|
|
|
|
|
|
2022-01-25 14:51:35 +01:00
|
|
|
typedef struct LibblockRemapMultipleUserData {
|
|
|
|
|
Main *bmain;
|
|
|
|
|
short remap_flags;
|
|
|
|
|
} LibBlockRemapMultipleUserData;
|
|
|
|
|
|
|
|
|
|
static void libblock_remap_foreach_idpair_cb(ID *old_id, ID *new_id, void *user_data)
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
{
|
2022-01-25 14:51:35 +01:00
|
|
|
LibBlockRemapMultipleUserData *data = user_data;
|
|
|
|
|
Main *bmain = data->bmain;
|
|
|
|
|
const short remap_flags = data->remap_flags;
|
|
|
|
|
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
BLI_assert(old_id != NULL);
|
|
|
|
|
BLI_assert((new_id == NULL) || GS(old_id->name) == GS(new_id->name));
|
|
|
|
|
BLI_assert(old_id != new_id);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
if (free_notifier_reference_cb) {
|
|
|
|
|
free_notifier_reference_cb(old_id);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-03-12 00:34:23 +11:00
|
|
|
if ((remap_flags & ID_REMAP_SKIP_USER_CLEAR) == 0) {
|
|
|
|
|
/* If old_id was used by some ugly 'user_one' stuff (like Image or Clip editors...), and user
|
|
|
|
|
* count has actually been incremented for that, we have to decrease once more its user
|
|
|
|
|
* count... unless we had to skip some 'user_one' cases. */
|
|
|
|
|
if ((old_id->tag & LIB_TAG_EXTRAUSER_SET) &&
|
2022-02-11 14:53:08 +01:00
|
|
|
!(old_id->runtime.remap.status & ID_REMAP_IS_USER_ONE_SKIPPED)) {
|
2021-03-12 00:34:23 +11:00
|
|
|
id_us_clear_real(old_id);
|
|
|
|
|
}
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-02-11 14:53:08 +01:00
|
|
|
const int skipped_refcounted = old_id->runtime.remap.skipped_refcounted;
|
2017-05-04 15:07:21 +02:00
|
|
|
if (old_id->us - skipped_refcounted < 0) {
|
2019-02-01 12:44:19 +11:00
|
|
|
CLOG_ERROR(&LOG,
|
|
|
|
|
"Error in remapping process from '%s' (%p) to '%s' (%p): "
|
|
|
|
|
"wrong user count in old ID after process (summing up to %d)",
|
|
|
|
|
old_id->name,
|
|
|
|
|
old_id,
|
|
|
|
|
new_id ? new_id->name : "<NULL>",
|
|
|
|
|
new_id,
|
|
|
|
|
old_id->us - skipped_refcounted);
|
2017-05-04 15:07:21 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-02-11 14:53:08 +01:00
|
|
|
const int skipped_direct = old_id->runtime.remap.skipped_direct;
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
if (skipped_direct == 0) {
|
|
|
|
|
/* old_id is assumed to not be used directly anymore... */
|
|
|
|
|
if (old_id->lib && (old_id->tag & LIB_TAG_EXTERN)) {
|
|
|
|
|
old_id->tag &= ~LIB_TAG_EXTERN;
|
|
|
|
|
old_id->tag |= LIB_TAG_INDIRECT;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
/* Some after-process updates.
|
2019-04-27 12:07:07 +10:00
|
|
|
* This is a bit ugly, but cannot see a way to avoid it.
|
|
|
|
|
* Maybe we should do a per-ID callback for this instead? */
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
switch (GS(old_id->name)) {
|
|
|
|
|
case ID_OB:
|
2022-04-12 18:16:46 +02:00
|
|
|
libblock_remap_data_postprocess_object_update(
|
|
|
|
|
bmain, (Object *)old_id, (Object *)new_id, true);
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
break;
|
|
|
|
|
case ID_GR:
|
Collections and groups unification
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383
https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
|
|
|
libblock_remap_data_postprocess_collection_update(
|
2021-04-23 12:28:54 +02:00
|
|
|
bmain, NULL, (Collection *)old_id, (Collection *)new_id);
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
break;
|
2016-07-08 15:16:45 +02:00
|
|
|
case ID_ME:
|
2022-02-18 09:50:29 -06:00
|
|
|
case ID_CU_LEGACY:
|
2016-07-08 15:16:45 +02:00
|
|
|
case ID_MB:
|
Curves: Rename "Hair" types, variables, and functions to "Curves"
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
2022-02-07 11:55:54 -06:00
|
|
|
case ID_CV:
|
2020-03-17 14:41:48 +01:00
|
|
|
case ID_PT:
|
|
|
|
|
case ID_VO:
|
2016-07-08 15:16:45 +02:00
|
|
|
if (new_id) { /* Only affects us in case obdata was relinked (changed). */
|
2019-03-08 09:29:17 +11:00
|
|
|
for (Object *ob = bmain->objects.first; ob; ob = ob->id.next) {
|
2016-07-08 15:16:45 +02:00
|
|
|
libblock_remap_data_postprocess_obdata_relink(bmain, ob, new_id);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2016-07-08 15:16:45 +02:00
|
|
|
break;
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-11-19 12:20:29 +01:00
|
|
|
/* Node trees may virtually use any kind of data-block... */
|
2017-01-09 10:43:23 +01:00
|
|
|
/* XXX Yuck!!!! nodetree update can do pretty much any thing when talking about py nodes,
|
|
|
|
|
* including creating new data-blocks (see T50385), so we need to unlock main here. :(
|
|
|
|
|
* Why can't we have re-entrent locks? */
|
|
|
|
|
BKE_main_unlock(bmain);
|
2016-11-19 12:20:29 +01:00
|
|
|
libblock_remap_data_postprocess_nodetree_update(bmain, new_id);
|
2017-01-09 10:43:23 +01:00
|
|
|
BKE_main_lock(bmain);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-08-10 16:04:01 +02:00
|
|
|
/* Full rebuild of DEG! */
|
2017-04-06 16:11:50 +02:00
|
|
|
DEG_relations_tag_update(bmain);
|
2022-02-11 14:53:08 +01:00
|
|
|
|
|
|
|
|
BKE_libblock_runtime_reset_remapping_status(old_id);
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
}
|
|
|
|
|
|
2022-01-25 14:51:35 +01:00
|
|
|
void BKE_libblock_remap_multiple_locked(Main *bmain,
|
2022-02-11 14:53:08 +01:00
|
|
|
struct IDRemapper *mappings,
|
2022-01-25 14:51:35 +01:00
|
|
|
const short remap_flags)
|
|
|
|
|
{
|
|
|
|
|
if (BKE_id_remapper_is_empty(mappings)) {
|
|
|
|
|
/* Early exit nothing to do. */
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-11 14:53:08 +01:00
|
|
|
libblock_remap_data(bmain, NULL, ID_REMAP_TYPE_REMAP, mappings, remap_flags);
|
|
|
|
|
|
|
|
|
|
LibBlockRemapMultipleUserData user_data = {0};
|
2022-01-25 14:51:35 +01:00
|
|
|
user_data.bmain = bmain;
|
|
|
|
|
user_data.remap_flags = remap_flags;
|
2022-02-11 14:53:08 +01:00
|
|
|
|
2022-01-25 14:51:35 +01:00
|
|
|
BKE_id_remapper_iter(mappings, libblock_remap_foreach_idpair_cb, &user_data);
|
|
|
|
|
|
|
|
|
|
/* We assume editors do not hold references to their IDs... This is false in some cases
|
|
|
|
|
* (Image is especially tricky here),
|
|
|
|
|
* editors' code is to handle refcount (id->us) itself then. */
|
|
|
|
|
if (remap_editor_id_reference_cb) {
|
|
|
|
|
remap_editor_id_reference_cb(mappings);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Full rebuild of DEG! */
|
|
|
|
|
DEG_relations_tag_update(bmain);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void BKE_libblock_remap_locked(Main *bmain, void *old_idv, void *new_idv, const short remap_flags)
|
|
|
|
|
{
|
|
|
|
|
struct IDRemapper *remapper = BKE_id_remapper_create();
|
|
|
|
|
ID *old_id = old_idv;
|
|
|
|
|
ID *new_id = new_idv;
|
|
|
|
|
BKE_id_remapper_add(remapper, old_id, new_id);
|
|
|
|
|
BKE_libblock_remap_multiple_locked(bmain, remapper, remap_flags);
|
|
|
|
|
BKE_id_remapper_free(remapper);
|
|
|
|
|
}
|
|
|
|
|
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
void BKE_libblock_remap(Main *bmain, void *old_idv, void *new_idv, const short remap_flags)
|
|
|
|
|
{
|
|
|
|
|
BKE_main_lock(bmain);
|
|
|
|
|
|
|
|
|
|
BKE_libblock_remap_locked(bmain, old_idv, new_idv, remap_flags);
|
|
|
|
|
|
|
|
|
|
BKE_main_unlock(bmain);
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-11 14:53:08 +01:00
|
|
|
void BKE_libblock_remap_multiple(Main *bmain, struct IDRemapper *mappings, const short remap_flags)
|
2022-01-25 14:51:35 +01:00
|
|
|
{
|
|
|
|
|
BKE_main_lock(bmain);
|
|
|
|
|
|
|
|
|
|
BKE_libblock_remap_multiple_locked(bmain, mappings, remap_flags);
|
|
|
|
|
|
|
|
|
|
BKE_main_unlock(bmain);
|
|
|
|
|
}
|
|
|
|
|
|
"Fix" crash when deleting linked object which has indirect usages.
This is in fact very hairy situation here... Objects are only refcounted by scenes,
any other usage is 'free', which means once all object instanciations are gone Blender
considers it can delete it.
There is a trap here though: indirect usages. Typically, we should never modify linked data
(because it is essencially useless, changes would be ignored and ost on next reload or
even undo/redo). This means indirect usages are not affected by default 'safe' remapping/unlinking.
For unlinking preceeding deletion however, this is not acceptable - we are likely to end with
a zero-user ID (aka deletable one) which is still actually used by other linked data.
Solution choosen here is double:
I) From 'user-space' (i.e. outliner, operators...), we check for cases where deleting datablocks
should not be allowed (indirect data or indirectly used data), and abort (with report) if needed.
II) From 'lower' level (BKE_library_remap and RNA), we also unlink from linked data,
which makes actual deletion possible and safe.
Note that with previous behavior (2.77 one), linked object would be deleted, including from linked data -
but then, once file is saved and reloaded, indirect usage would link back the deleted object,
without any instanciation in scene, which made it somehow virtual and unreachable...
With new behavior, this is no more possible, but on the other hand it means that in situations of dependency cycles
(two linked objects using each other), linked objects become impossible to delete (from user space).
Not sure what's best here, behavior with those corner cases of library linking is very poorly defined... :(
2016-07-01 17:51:08 +02:00
|
|
|
void BKE_libblock_unlink(Main *bmain,
|
|
|
|
|
void *idv,
|
|
|
|
|
const bool do_flag_never_null,
|
|
|
|
|
const bool do_skip_indirect)
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
{
|
"Fix" crash when deleting linked object which has indirect usages.
This is in fact very hairy situation here... Objects are only refcounted by scenes,
any other usage is 'free', which means once all object instanciations are gone Blender
considers it can delete it.
There is a trap here though: indirect usages. Typically, we should never modify linked data
(because it is essencially useless, changes would be ignored and ost on next reload or
even undo/redo). This means indirect usages are not affected by default 'safe' remapping/unlinking.
For unlinking preceeding deletion however, this is not acceptable - we are likely to end with
a zero-user ID (aka deletable one) which is still actually used by other linked data.
Solution choosen here is double:
I) From 'user-space' (i.e. outliner, operators...), we check for cases where deleting datablocks
should not be allowed (indirect data or indirectly used data), and abort (with report) if needed.
II) From 'lower' level (BKE_library_remap and RNA), we also unlink from linked data,
which makes actual deletion possible and safe.
Note that with previous behavior (2.77 one), linked object would be deleted, including from linked data -
but then, once file is saved and reloaded, indirect usage would link back the deleted object,
without any instanciation in scene, which made it somehow virtual and unreachable...
With new behavior, this is no more possible, but on the other hand it means that in situations of dependency cycles
(two linked objects using each other), linked objects become impossible to delete (from user space).
Not sure what's best here, behavior with those corner cases of library linking is very poorly defined... :(
2016-07-01 17:51:08 +02:00
|
|
|
const short remap_flags = (do_skip_indirect ? ID_REMAP_SKIP_INDIRECT_USAGE : 0) |
|
|
|
|
|
(do_flag_never_null ? ID_REMAP_FLAG_NEVER_NULL_USAGE : 0);
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
|
|
|
|
|
BKE_main_lock(bmain);
|
|
|
|
|
|
|
|
|
|
BKE_libblock_remap_locked(bmain, idv, NULL, remap_flags);
|
|
|
|
|
|
|
|
|
|
BKE_main_unlock(bmain);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* XXX Arg! Naming... :(
|
|
|
|
|
* _relink? avoids confusion with _remap, but is confusing with _unlink
|
|
|
|
|
* _remap_used_ids?
|
|
|
|
|
* _remap_datablocks?
|
|
|
|
|
* BKE_id_remap maybe?
|
|
|
|
|
* ... sigh
|
|
|
|
|
*/
|
2021-12-07 17:19:15 +11:00
|
|
|
|
2022-03-16 17:52:16 +01:00
|
|
|
typedef struct LibblockRelinkMultipleUserData {
|
|
|
|
|
Main *bmain;
|
|
|
|
|
LinkNode *ids;
|
|
|
|
|
} LibBlockRelinkMultipleUserData;
|
|
|
|
|
|
|
|
|
|
static void libblock_relink_foreach_idpair_cb(ID *old_id, ID *new_id, void *user_data)
|
|
|
|
|
{
|
|
|
|
|
LibBlockRelinkMultipleUserData *data = user_data;
|
|
|
|
|
Main *bmain = data->bmain;
|
|
|
|
|
LinkNode *ids = data->ids;
|
|
|
|
|
|
|
|
|
|
BLI_assert(old_id != NULL);
|
|
|
|
|
BLI_assert((new_id == NULL) || GS(old_id->name) == GS(new_id->name));
|
|
|
|
|
BLI_assert(old_id != new_id);
|
|
|
|
|
|
|
|
|
|
bool is_object_update_processed = false;
|
|
|
|
|
for (LinkNode *ln_iter = ids; ln_iter != NULL; ln_iter = ln_iter->next) {
|
|
|
|
|
ID *id_iter = ln_iter->link;
|
|
|
|
|
|
|
|
|
|
/* Some after-process updates.
|
|
|
|
|
* This is a bit ugly, but cannot see a way to avoid it.
|
|
|
|
|
* Maybe we should do a per-ID callback for this instead?
|
|
|
|
|
*/
|
|
|
|
|
switch (GS(id_iter->name)) {
|
|
|
|
|
case ID_SCE:
|
|
|
|
|
case ID_GR: {
|
|
|
|
|
/* NOTE: here we know which collection we have affected, so at lest for NULL children
|
|
|
|
|
* detection we can only process that one.
|
|
|
|
|
* This is also a required fix in case `id` would not be in Main anymore, which can happen
|
|
|
|
|
* e.g. when called from `id_delete`. */
|
|
|
|
|
Collection *owner_collection = (GS(id_iter->name) == ID_GR) ?
|
|
|
|
|
(Collection *)id_iter :
|
|
|
|
|
((Scene *)id_iter)->master_collection;
|
|
|
|
|
switch (GS(old_id->name)) {
|
|
|
|
|
case ID_OB:
|
|
|
|
|
if (!is_object_update_processed) {
|
|
|
|
|
libblock_remap_data_postprocess_object_update(
|
2022-04-12 18:16:46 +02:00
|
|
|
bmain, (Object *)old_id, (Object *)new_id, true);
|
2022-03-16 17:52:16 +01:00
|
|
|
is_object_update_processed = true;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case ID_GR:
|
|
|
|
|
libblock_remap_data_postprocess_collection_update(
|
|
|
|
|
bmain, owner_collection, (Collection *)old_id, (Collection *)new_id);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case ID_OB:
|
|
|
|
|
if (new_id != NULL) { /* Only affects us in case obdata was relinked (changed). */
|
|
|
|
|
libblock_remap_data_postprocess_obdata_relink(bmain, (Object *)id_iter, new_id);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void BKE_libblock_relink_multiple(Main *bmain,
|
|
|
|
|
LinkNode *ids,
|
|
|
|
|
const eIDRemapType remap_type,
|
|
|
|
|
struct IDRemapper *id_remapper,
|
|
|
|
|
const short remap_flags)
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(remap_type == ID_REMAP_TYPE_REMAP || BKE_id_remapper_is_empty(id_remapper));
|
|
|
|
|
|
|
|
|
|
for (LinkNode *ln_iter = ids; ln_iter != NULL; ln_iter = ln_iter->next) {
|
|
|
|
|
ID *id_iter = ln_iter->link;
|
|
|
|
|
libblock_remap_data(bmain, id_iter, remap_type, id_remapper, remap_flags);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (remap_type) {
|
|
|
|
|
case ID_REMAP_TYPE_REMAP: {
|
|
|
|
|
LibBlockRelinkMultipleUserData user_data = {0};
|
|
|
|
|
user_data.bmain = bmain;
|
|
|
|
|
user_data.ids = ids;
|
|
|
|
|
|
|
|
|
|
BKE_id_remapper_iter(id_remapper, libblock_relink_foreach_idpair_cb, &user_data);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case ID_REMAP_TYPE_CLEANUP: {
|
|
|
|
|
bool is_object_update_processed = false;
|
|
|
|
|
for (LinkNode *ln_iter = ids; ln_iter != NULL; ln_iter = ln_iter->next) {
|
|
|
|
|
ID *id_iter = ln_iter->link;
|
|
|
|
|
|
|
|
|
|
switch (GS(id_iter->name)) {
|
|
|
|
|
case ID_SCE:
|
|
|
|
|
case ID_GR: {
|
|
|
|
|
/* NOTE: here we know which collection we have affected, so at lest for NULL children
|
|
|
|
|
* detection we can only process that one.
|
|
|
|
|
* This is also a required fix in case `id` would not be in Main anymore, which can
|
|
|
|
|
* happen e.g. when called from `id_delete`. */
|
|
|
|
|
Collection *owner_collection = (GS(id_iter->name) == ID_GR) ?
|
|
|
|
|
(Collection *)id_iter :
|
|
|
|
|
((Scene *)id_iter)->master_collection;
|
|
|
|
|
/* No choice but to check whole objects once, and all children collections. */
|
|
|
|
|
if (!is_object_update_processed) {
|
2022-04-12 18:16:46 +02:00
|
|
|
/* We only want to affect Object pointers here, not Collection ones, LayerCollections
|
|
|
|
|
* will be resynced as part of the call to
|
|
|
|
|
* `libblock_remap_data_postprocess_collection_update` below. */
|
|
|
|
|
libblock_remap_data_postprocess_object_update(bmain, NULL, NULL, false);
|
2022-03-16 17:52:16 +01:00
|
|
|
is_object_update_processed = true;
|
|
|
|
|
}
|
2022-04-12 18:16:46 +02:00
|
|
|
libblock_remap_data_postprocess_collection_update(bmain, owner_collection, NULL, NULL);
|
2022-03-16 17:52:16 +01:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
default:
|
|
|
|
|
BLI_assert_unreachable();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
DEG_relations_tag_update(bmain);
|
|
|
|
|
}
|
|
|
|
|
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
void BKE_libblock_relink_ex(
|
2019-08-29 16:34:17 +02:00
|
|
|
Main *bmain, void *idv, void *old_idv, void *new_idv, const short remap_flags)
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
{
|
2021-12-07 17:19:15 +11:00
|
|
|
|
|
|
|
|
/* Should be able to replace all _relink() funcs (constraints, rigidbody, etc.) ? */
|
|
|
|
|
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
ID *id = idv;
|
|
|
|
|
ID *old_id = old_idv;
|
|
|
|
|
ID *new_id = new_idv;
|
2022-03-16 17:52:16 +01:00
|
|
|
LinkNode ids = {.next = NULL, .link = idv};
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-07-08 13:22:54 +02:00
|
|
|
/* No need to lock here, we are only affecting given ID, not bmain database. */
|
2022-02-11 14:53:08 +01:00
|
|
|
struct IDRemapper *id_remapper = BKE_id_remapper_create();
|
|
|
|
|
eIDRemapType remap_type = ID_REMAP_TYPE_REMAP;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-03-16 17:52:16 +01:00
|
|
|
BLI_assert(id != NULL);
|
|
|
|
|
UNUSED_VARS_NDEBUG(id);
|
|
|
|
|
if (old_id != NULL) {
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
BLI_assert((new_id == NULL) || GS(old_id->name) == GS(new_id->name));
|
|
|
|
|
BLI_assert(old_id != new_id);
|
2022-02-11 14:53:08 +01:00
|
|
|
BKE_id_remapper_add(id_remapper, old_id, new_id);
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
BLI_assert(new_id == NULL);
|
2022-02-11 14:53:08 +01:00
|
|
|
remap_type = ID_REMAP_TYPE_CLEANUP;
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-03-16 17:52:16 +01:00
|
|
|
BKE_libblock_relink_multiple(bmain, &ids, remap_type, id_remapper, remap_flags);
|
2019-11-07 16:09:58 +01:00
|
|
|
|
2022-03-16 17:52:16 +01:00
|
|
|
BKE_id_remapper_free(id_remapper);
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
}
|
|
|
|
|
|
2022-03-17 15:08:43 +01:00
|
|
|
typedef struct RelinkToNewIDData {
|
|
|
|
|
LinkNode *ids;
|
|
|
|
|
struct IDRemapper *id_remapper;
|
|
|
|
|
} RelinkToNewIDData;
|
|
|
|
|
|
|
|
|
|
static void libblock_relink_to_newid_prepare_data(Main *bmain,
|
|
|
|
|
ID *id,
|
|
|
|
|
RelinkToNewIDData *relink_data);
|
2020-02-13 12:56:10 +01:00
|
|
|
static int id_relink_to_newid_looper(LibraryIDLinkCallbackData *cb_data)
|
2021-09-14 17:43:41 +02:00
|
|
|
{
|
|
|
|
|
const int cb_flag = cb_data->cb_flag;
|
2021-10-06 11:38:11 +02:00
|
|
|
if (cb_flag & (IDWALK_CB_EMBEDDED | IDWALK_CB_OVERRIDE_LIBRARY_REFERENCE)) {
|
2021-09-14 17:43:41 +02:00
|
|
|
return IDWALK_RET_NOP;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Main *bmain = cb_data->bmain;
|
|
|
|
|
ID **id_pointer = cb_data->id_pointer;
|
|
|
|
|
ID *id = *id_pointer;
|
2022-03-17 15:08:43 +01:00
|
|
|
RelinkToNewIDData *relink_data = (RelinkToNewIDData *)cb_data->user_data;
|
|
|
|
|
|
2021-09-14 17:43:41 +02:00
|
|
|
if (id) {
|
|
|
|
|
/* See: NEW_ID macro */
|
|
|
|
|
if (id->newid != NULL) {
|
2022-03-17 15:08:43 +01:00
|
|
|
BKE_id_remapper_add(relink_data->id_remapper, id, id->newid);
|
2021-09-14 17:43:41 +02:00
|
|
|
id = id->newid;
|
|
|
|
|
}
|
|
|
|
|
if (id->tag & LIB_TAG_NEW) {
|
2022-03-17 15:08:43 +01:00
|
|
|
libblock_relink_to_newid_prepare_data(bmain, id, relink_data);
|
2021-09-14 17:43:41 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return IDWALK_RET_NOP;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-17 15:08:43 +01:00
|
|
|
static void libblock_relink_to_newid_prepare_data(Main *bmain,
|
|
|
|
|
ID *id,
|
|
|
|
|
RelinkToNewIDData *relink_data)
|
2021-10-28 11:57:20 +02:00
|
|
|
{
|
|
|
|
|
if (ID_IS_LINKED(id)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
id->tag &= ~LIB_TAG_NEW;
|
2022-03-17 15:08:43 +01:00
|
|
|
BLI_linklist_prepend(&relink_data->ids, id);
|
|
|
|
|
BKE_library_foreach_ID_link(bmain, id, id_relink_to_newid_looper, relink_data, 0);
|
2021-10-28 11:57:20 +02:00
|
|
|
}
|
|
|
|
|
|
2021-11-01 15:19:17 +01:00
|
|
|
void BKE_libblock_relink_to_newid(Main *bmain, ID *id, const int remap_flag)
|
2021-09-14 17:43:41 +02:00
|
|
|
{
|
|
|
|
|
if (ID_IS_LINKED(id)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
/* We do not want to have those cached relationship data here. */
|
|
|
|
|
BLI_assert(bmain->relations == NULL);
|
|
|
|
|
|
2022-03-17 15:08:43 +01:00
|
|
|
RelinkToNewIDData relink_data = {.ids = NULL, .id_remapper = BKE_id_remapper_create()};
|
|
|
|
|
|
|
|
|
|
libblock_relink_to_newid_prepare_data(bmain, id, &relink_data);
|
|
|
|
|
|
|
|
|
|
const short remap_flag_final = remap_flag | ID_REMAP_SKIP_INDIRECT_USAGE |
|
|
|
|
|
ID_REMAP_SKIP_OVERRIDE_LIBRARY;
|
|
|
|
|
BKE_libblock_relink_multiple(
|
|
|
|
|
bmain, relink_data.ids, ID_REMAP_TYPE_REMAP, relink_data.id_remapper, remap_flag_final);
|
|
|
|
|
|
|
|
|
|
BKE_id_remapper_free(relink_data.id_remapper);
|
|
|
|
|
BLI_linklist_free(relink_data.ids, NULL);
|
2021-09-14 17:43:41 +02:00
|
|
|
}
|