2014-03-26 16:55:20 +06:00
|
|
|
/*
|
|
|
|
* ***** BEGIN GPL LICENSE BLOCK *****
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2014 by Blender Foundation.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Contributor(s): Sergey Sharybin.
|
|
|
|
*
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
|
|
|
*/
|
|
|
|
|
|
|
|
/** \file blender/blenkernel/intern/library_query.c
|
|
|
|
* \ingroup bke
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stdlib.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 "MEM_guardedalloc.h"
|
2014-03-26 16:55:20 +06:00
|
|
|
|
2015-10-08 15:04:09 +02:00
|
|
|
#include "DNA_actuator_types.h"
|
2014-03-26 16:55:20 +06:00
|
|
|
#include "DNA_anim_types.h"
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
#include "DNA_armature_types.h"
|
2014-03-26 16:55:20 +06:00
|
|
|
#include "DNA_brush_types.h"
|
|
|
|
#include "DNA_camera_types.h"
|
|
|
|
#include "DNA_constraint_types.h"
|
2015-10-08 15:04:09 +02:00
|
|
|
#include "DNA_controller_types.h"
|
2014-03-26 16:55:20 +06:00
|
|
|
#include "DNA_group_types.h"
|
|
|
|
#include "DNA_gpencil_types.h"
|
|
|
|
#include "DNA_key_types.h"
|
|
|
|
#include "DNA_lamp_types.h"
|
|
|
|
#include "DNA_lattice_types.h"
|
2014-05-03 18:51:53 +09:00
|
|
|
#include "DNA_linestyle_types.h"
|
2014-03-26 16:55:20 +06:00
|
|
|
#include "DNA_material_types.h"
|
|
|
|
#include "DNA_mesh_types.h"
|
2016-07-08 17:28:28 +02:00
|
|
|
#include "DNA_meshdata_types.h"
|
2014-03-26 16:55:20 +06:00
|
|
|
#include "DNA_meta_types.h"
|
|
|
|
#include "DNA_movieclip_types.h"
|
|
|
|
#include "DNA_mask_types.h"
|
|
|
|
#include "DNA_node_types.h"
|
|
|
|
#include "DNA_object_force.h"
|
2015-10-08 18:08:57 +11:00
|
|
|
#include "DNA_rigidbody_types.h"
|
2014-06-06 12:44:48 +09:00
|
|
|
#include "DNA_scene_types.h"
|
2015-10-08 15:04:09 +02:00
|
|
|
#include "DNA_sensor_types.h"
|
2014-03-26 16:55:20 +06:00
|
|
|
#include "DNA_sequence_types.h"
|
|
|
|
#include "DNA_screen_types.h"
|
|
|
|
#include "DNA_speaker_types.h"
|
|
|
|
#include "DNA_sound_types.h"
|
2014-06-06 16:07:58 +06:00
|
|
|
#include "DNA_text_types.h"
|
2014-03-26 16:55:20 +06:00
|
|
|
#include "DNA_vfont_types.h"
|
|
|
|
#include "DNA_world_types.h"
|
|
|
|
|
|
|
|
#include "BLI_utildefines.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_listbase.h"
|
2016-03-24 12:28:41 +01:00
|
|
|
#include "BLI_ghash.h"
|
|
|
|
#include "BLI_linklist_stack.h"
|
2014-03-26 16:55:20 +06:00
|
|
|
|
|
|
|
#include "BKE_animsys.h"
|
|
|
|
#include "BKE_constraint.h"
|
|
|
|
#include "BKE_fcurve.h"
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
#include "BKE_idprop.h"
|
2015-10-08 20:29:49 +11:00
|
|
|
#include "BKE_library.h"
|
2014-03-26 16:55:20 +06:00
|
|
|
#include "BKE_library_query.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"
|
2014-03-26 16:55:20 +06:00
|
|
|
#include "BKE_modifier.h"
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
#include "BKE_node.h"
|
2014-03-26 16:55:20 +06:00
|
|
|
#include "BKE_particle.h"
|
2015-10-08 14:59:24 +02:00
|
|
|
#include "BKE_rigidbody.h"
|
2015-10-08 15:04:09 +02:00
|
|
|
#include "BKE_sca.h"
|
2014-03-26 16:55:20 +06:00
|
|
|
#include "BKE_sequencer.h"
|
|
|
|
#include "BKE_tracking.h"
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
#define FOREACH_FINALIZE _finalize
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
#define FOREACH_FINALIZE_VOID \
|
|
|
|
if (0) { goto FOREACH_FINALIZE; } \
|
|
|
|
FOREACH_FINALIZE: ((void)0)
|
2016-03-24 12:28:41 +01:00
|
|
|
|
2017-01-31 10:41:25 +01:00
|
|
|
#define FOREACH_CALLBACK_INVOKE_ID_PP(_data, id_pp, _cb_flag) \
|
2017-01-30 21:34:23 +01:00
|
|
|
CHECK_TYPE(id_pp, ID **); \
|
2016-03-24 12:28:41 +01:00
|
|
|
if (!((_data)->status & IDWALK_STOP)) { \
|
|
|
|
const int _flag = (_data)->flag; \
|
|
|
|
ID *old_id = *(id_pp); \
|
2017-01-31 10:41:25 +01:00
|
|
|
const int callback_return = (_data)->callback((_data)->user_data, (_data)->self_id, id_pp, _cb_flag | (_data)->cb_flag); \
|
2016-03-24 12:28:41 +01:00
|
|
|
if (_flag & IDWALK_READONLY) { \
|
|
|
|
BLI_assert(*(id_pp) == old_id); \
|
2014-03-26 16:55:20 +06:00
|
|
|
} \
|
2016-03-30 21:36:09 +02:00
|
|
|
if (old_id && (_flag & IDWALK_RECURSE)) { \
|
2016-03-24 12:28:41 +01:00
|
|
|
if (!BLI_gset_haskey((_data)->ids_handled, old_id)) { \
|
|
|
|
BLI_gset_add((_data)->ids_handled, old_id); \
|
|
|
|
if (!(callback_return & IDWALK_RET_STOP_RECURSION)) { \
|
|
|
|
BLI_LINKSTACK_PUSH((_data)->ids_todo, old_id); \
|
|
|
|
} \
|
|
|
|
} \
|
2014-03-26 16:55:20 +06:00
|
|
|
} \
|
2016-03-24 12:28:41 +01:00
|
|
|
if (callback_return & IDWALK_RET_STOP_ITER) { \
|
|
|
|
(_data)->status |= IDWALK_STOP; \
|
|
|
|
goto FOREACH_FINALIZE; \
|
|
|
|
} \
|
|
|
|
} \
|
|
|
|
else { \
|
|
|
|
goto FOREACH_FINALIZE; \
|
2015-10-08 19:18:30 +11:00
|
|
|
} ((void)0)
|
2014-03-26 16:55:20 +06:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
#define FOREACH_CALLBACK_INVOKE_ID(_data, id, cb_flag) \
|
2015-10-08 19:18:30 +11:00
|
|
|
{ \
|
|
|
|
CHECK_TYPE_ANY(id, ID *, void *); \
|
2016-03-24 12:28:41 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE_ID_PP(_data, (ID **)&(id), cb_flag); \
|
2015-10-08 19:18:30 +11:00
|
|
|
} ((void)0)
|
2014-03-26 16:55:20 +06:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
#define FOREACH_CALLBACK_INVOKE(_data, id_super, cb_flag) \
|
2014-03-26 16:55:20 +06:00
|
|
|
{ \
|
|
|
|
CHECK_TYPE(&((id_super)->id), ID *); \
|
2016-03-24 12:28:41 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE_ID_PP(_data, (ID **)&(id_super), cb_flag); \
|
2015-10-08 19:18:30 +11:00
|
|
|
} ((void)0)
|
2014-03-26 16:55:20 +06:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
/* status */
|
|
|
|
enum {
|
|
|
|
IDWALK_STOP = 1 << 0,
|
|
|
|
};
|
|
|
|
|
2014-03-26 16:55:20 +06:00
|
|
|
typedef struct LibraryForeachIDData {
|
|
|
|
ID *self_id;
|
|
|
|
int flag;
|
2017-01-31 10:41:25 +01:00
|
|
|
int cb_flag;
|
2014-03-26 16:55:20 +06:00
|
|
|
LibraryIDLinkCallback callback;
|
|
|
|
void *user_data;
|
2016-03-24 12:28:41 +01:00
|
|
|
int status;
|
|
|
|
|
|
|
|
/* To handle recursion. */
|
|
|
|
GSet *ids_handled; /* All IDs that are either already done, or still in ids_todo stack. */
|
|
|
|
BLI_LINKSTACK_DECLARE(ids_todo, ID *);
|
2014-03-26 16:55:20 +06:00
|
|
|
} LibraryForeachIDData;
|
|
|
|
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
static void library_foreach_idproperty_ID_link(LibraryForeachIDData *data, IDProperty *prop, int flag)
|
|
|
|
{
|
|
|
|
if (!prop)
|
|
|
|
return;
|
|
|
|
|
|
|
|
switch (prop->type) {
|
|
|
|
case IDP_GROUP:
|
|
|
|
{
|
|
|
|
for (IDProperty *loop = prop->data.group.first; loop; loop = loop->next) {
|
|
|
|
library_foreach_idproperty_ID_link(data, loop, flag);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case IDP_IDPARRAY:
|
|
|
|
{
|
|
|
|
IDProperty *loop = IDP_Array(prop);
|
|
|
|
for (int i = 0; i < prop->len; i++) {
|
|
|
|
library_foreach_idproperty_ID_link(data, &loop[i], flag);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case IDP_ID:
|
|
|
|
FOREACH_CALLBACK_INVOKE_ID(data, prop->data.pointer, flag);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break; /* Nothing to do here with other types of IDProperties... */
|
|
|
|
}
|
|
|
|
|
|
|
|
FOREACH_FINALIZE_VOID;
|
|
|
|
}
|
|
|
|
|
2015-10-08 14:59:24 +02:00
|
|
|
static void library_foreach_rigidbodyworldSceneLooper(
|
2017-01-31 10:41:25 +01:00
|
|
|
struct RigidBodyWorld *UNUSED(rbw), ID **id_pointer, void *user_data, int cb_flag)
|
2015-10-08 14:59:24 +02:00
|
|
|
{
|
|
|
|
LibraryForeachIDData *data = (LibraryForeachIDData *) user_data;
|
2017-01-31 10:41:25 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE_ID_PP(data, id_pointer, cb_flag);
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
FOREACH_FINALIZE_VOID;
|
2015-10-08 14:59:24 +02:00
|
|
|
}
|
|
|
|
|
2015-10-08 14:21:11 +02:00
|
|
|
static void library_foreach_modifiersForeachIDLink(
|
2017-01-31 10:41:25 +01:00
|
|
|
void *user_data, Object *UNUSED(object), ID **id_pointer, int cb_flag)
|
2014-03-26 16:55:20 +06:00
|
|
|
{
|
|
|
|
LibraryForeachIDData *data = (LibraryForeachIDData *) user_data;
|
2017-01-31 10:41:25 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE_ID_PP(data, id_pointer, cb_flag);
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
FOREACH_FINALIZE_VOID;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
|
|
|
static void library_foreach_constraintObjectLooper(bConstraint *UNUSED(con), ID **id_pointer,
|
2015-11-26 12:07:02 +01:00
|
|
|
bool is_reference, void *user_data)
|
2014-03-26 16:55:20 +06:00
|
|
|
{
|
|
|
|
LibraryForeachIDData *data = (LibraryForeachIDData *) user_data;
|
2017-01-31 10:41:25 +01:00
|
|
|
const int cb_flag = is_reference ? IDWALK_CB_USER : IDWALK_CB_NOP;
|
|
|
|
FOREACH_CALLBACK_INVOKE_ID_PP(data, id_pointer, cb_flag);
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
FOREACH_FINALIZE_VOID;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2015-10-08 14:56:20 +02:00
|
|
|
static void library_foreach_particlesystemsObjectLooper(
|
2017-01-31 10:41:25 +01:00
|
|
|
ParticleSystem *UNUSED(psys), ID **id_pointer, void *user_data, int cb_flag)
|
2015-10-08 14:56:20 +02:00
|
|
|
{
|
|
|
|
LibraryForeachIDData *data = (LibraryForeachIDData *) user_data;
|
2017-01-31 10:41:25 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE_ID_PP(data, id_pointer, cb_flag);
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
FOREACH_FINALIZE_VOID;
|
2015-10-08 14:56:20 +02:00
|
|
|
}
|
|
|
|
|
2015-10-08 15:04:09 +02:00
|
|
|
static void library_foreach_sensorsObjectLooper(
|
2017-01-31 10:41:25 +01:00
|
|
|
bSensor *UNUSED(sensor), ID **id_pointer, void *user_data, int cb_flag)
|
2015-10-08 15:04:09 +02:00
|
|
|
{
|
|
|
|
LibraryForeachIDData *data = (LibraryForeachIDData *) user_data;
|
2017-01-31 10:41:25 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE_ID_PP(data, id_pointer, cb_flag);
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
FOREACH_FINALIZE_VOID;
|
2015-10-08 15:04:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void library_foreach_controllersObjectLooper(
|
2017-01-31 10:41:25 +01:00
|
|
|
bController *UNUSED(controller), ID **id_pointer, void *user_data, int cb_flag)
|
2015-10-08 15:04:09 +02:00
|
|
|
{
|
|
|
|
LibraryForeachIDData *data = (LibraryForeachIDData *) user_data;
|
2017-01-31 10:41:25 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE_ID_PP(data, id_pointer, cb_flag);
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
FOREACH_FINALIZE_VOID;
|
2015-10-08 15:04:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void library_foreach_actuatorsObjectLooper(
|
2017-01-31 10:41:25 +01:00
|
|
|
bActuator *UNUSED(actuator), ID **id_pointer, void *user_data, int cb_flag)
|
2015-10-08 15:04:09 +02:00
|
|
|
{
|
|
|
|
LibraryForeachIDData *data = (LibraryForeachIDData *) user_data;
|
2017-01-31 10:41:25 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE_ID_PP(data, id_pointer, cb_flag);
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
FOREACH_FINALIZE_VOID;
|
2015-10-08 15:04:09 +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
|
|
|
static void library_foreach_nla_strip(LibraryForeachIDData *data, NlaStrip *strip)
|
|
|
|
{
|
|
|
|
NlaStrip *substrip;
|
|
|
|
|
2017-01-31 09:47:59 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE(data, strip->act, IDWALK_CB_USER);
|
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
|
|
|
|
|
|
|
for (substrip = strip->strips.first; substrip; substrip = substrip->next) {
|
|
|
|
library_foreach_nla_strip(data, substrip);
|
|
|
|
}
|
|
|
|
|
|
|
|
FOREACH_FINALIZE_VOID;
|
|
|
|
}
|
|
|
|
|
2014-03-26 16:55:20 +06:00
|
|
|
static void library_foreach_animationData(LibraryForeachIDData *data, AnimData *adt)
|
|
|
|
{
|
|
|
|
FCurve *fcu;
|
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
|
|
|
NlaTrack *nla_track;
|
|
|
|
NlaStrip *nla_strip;
|
2014-03-26 16:55:20 +06:00
|
|
|
|
|
|
|
for (fcu = adt->drivers.first; fcu; fcu = fcu->next) {
|
|
|
|
ChannelDriver *driver = fcu->driver;
|
|
|
|
DriverVar *dvar;
|
|
|
|
|
|
|
|
for (dvar = driver->variables.first; dvar; dvar = dvar->next) {
|
|
|
|
/* only used targets */
|
|
|
|
DRIVER_TARGETS_USED_LOOPER(dvar)
|
|
|
|
{
|
2017-01-31 09:47:59 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE_ID(data, dtar->id, IDWALK_CB_NOP);
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
DRIVER_TARGETS_LOOPER_END
|
|
|
|
}
|
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
|
2017-01-31 09:47:59 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE(data, adt->action, IDWALK_CB_USER);
|
|
|
|
FOREACH_CALLBACK_INVOKE(data, adt->tmpact, IDWALK_CB_USER);
|
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
|
|
|
|
|
|
|
for (nla_track = adt->nla_tracks.first; nla_track; nla_track = nla_track->next) {
|
|
|
|
for (nla_strip = nla_track->strips.first; nla_strip; nla_strip = nla_strip->next) {
|
|
|
|
library_foreach_nla_strip(data, nla_strip);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
FOREACH_FINALIZE_VOID;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
|
|
|
static void library_foreach_mtex(LibraryForeachIDData *data, MTex *mtex)
|
|
|
|
{
|
2017-01-31 09:47:59 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE(data, mtex->object, IDWALK_CB_NOP);
|
|
|
|
FOREACH_CALLBACK_INVOKE(data, mtex->tex, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
FOREACH_FINALIZE_VOID;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2016-06-16 21:09:01 +02:00
|
|
|
static void library_foreach_paint(LibraryForeachIDData *data, Paint *paint)
|
|
|
|
{
|
2017-01-31 09:47:59 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE(data, paint->brush, IDWALK_CB_USER);
|
|
|
|
FOREACH_CALLBACK_INVOKE(data, paint->palette, IDWALK_CB_USER);
|
2016-06-16 21:09:01 +02:00
|
|
|
|
|
|
|
FOREACH_FINALIZE_VOID;
|
|
|
|
}
|
|
|
|
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
static void library_foreach_bone(LibraryForeachIDData *data, Bone *bone)
|
|
|
|
{
|
|
|
|
library_foreach_idproperty_ID_link(data, bone->prop, IDWALK_CB_USER);
|
|
|
|
|
|
|
|
for (Bone *curbone = bone->childbase.first; curbone; curbone = curbone->next) {
|
|
|
|
library_foreach_bone(data, curbone);
|
|
|
|
}
|
|
|
|
|
|
|
|
FOREACH_FINALIZE_VOID;
|
|
|
|
}
|
|
|
|
|
2016-10-04 15:03:34 +02:00
|
|
|
static void library_foreach_ID_as_subdata_link(
|
2017-01-30 21:34:23 +01:00
|
|
|
ID **id_pp, LibraryIDLinkCallback callback, void *user_data, int flag, LibraryForeachIDData *data)
|
2016-10-04 15:03:34 +02:00
|
|
|
{
|
2017-01-30 21:34:23 +01:00
|
|
|
/* Needed e.g. for callbacks handling relationships... This call shall be absolutely readonly. */
|
|
|
|
ID *id = *id_pp;
|
2017-01-31 09:47:59 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE_ID_PP(data, id_pp, IDWALK_CB_PRIVATE);
|
2017-01-30 21:34:23 +01:00
|
|
|
BLI_assert(id == *id_pp);
|
|
|
|
|
2016-10-04 15:03:34 +02:00
|
|
|
if (flag & IDWALK_RECURSE) {
|
|
|
|
/* Defer handling into main loop, recursively calling BKE_library_foreach_ID_link in IDWALK_RECURSE case is
|
|
|
|
* troublesome, see T49553. */
|
|
|
|
if (!BLI_gset_haskey(data->ids_handled, id)) {
|
|
|
|
BLI_gset_add(data->ids_handled, id);
|
|
|
|
BLI_LINKSTACK_PUSH(data->ids_todo, id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else {
|
2017-01-30 21:41:44 +01:00
|
|
|
BKE_library_foreach_ID_link(NULL, id, callback, user_data, flag);
|
2016-10-04 15:03:34 +02:00
|
|
|
}
|
2017-01-30 21:34:23 +01:00
|
|
|
|
|
|
|
FOREACH_FINALIZE_VOID;
|
2016-10-04 15:03:34 +02:00
|
|
|
}
|
2014-03-26 16:55:20 +06:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Loop over all of the ID's this datablock links to.
|
|
|
|
*
|
|
|
|
* \note: May be extended to be recursive in the future.
|
|
|
|
*/
|
2017-01-30 21:41:44 +01:00
|
|
|
void BKE_library_foreach_ID_link(Main *bmain, ID *id, LibraryIDLinkCallback callback, void *user_data, int flag)
|
2014-03-26 16:55:20 +06:00
|
|
|
{
|
|
|
|
LibraryForeachIDData data;
|
|
|
|
int i;
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
if (flag & IDWALK_RECURSE) {
|
|
|
|
/* For now, recusion implies read-only. */
|
|
|
|
flag |= IDWALK_READONLY;
|
|
|
|
|
|
|
|
data.ids_handled = BLI_gset_new(BLI_ghashutil_ptrhash, BLI_ghashutil_ptrcmp, __func__);
|
|
|
|
BLI_LINKSTACK_INIT(data.ids_todo);
|
2016-10-04 15:03:34 +02:00
|
|
|
|
|
|
|
BLI_gset_add(data.ids_handled, id);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
data.ids_handled = NULL;
|
|
|
|
}
|
2014-03-26 16:55:20 +06:00
|
|
|
data.flag = flag;
|
2016-03-26 16:07:57 +01:00
|
|
|
data.status = 0;
|
2014-03-26 16:55:20 +06:00
|
|
|
data.callback = callback;
|
|
|
|
data.user_data = user_data;
|
|
|
|
|
|
|
|
#define CALLBACK_INVOKE_ID(check_id, cb_flag) \
|
2016-03-24 12:28:41 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE_ID(&data, check_id, cb_flag)
|
2014-03-26 16:55:20 +06:00
|
|
|
|
|
|
|
#define CALLBACK_INVOKE(check_id_super, cb_flag) \
|
2016-03-24 12:28:41 +01:00
|
|
|
FOREACH_CALLBACK_INVOKE(&data, check_id_super, cb_flag)
|
|
|
|
|
2017-01-30 21:41:44 +01:00
|
|
|
for (; id != NULL; id = (flag & IDWALK_RECURSE) ? BLI_LINKSTACK_POP(data.ids_todo) : NULL) {
|
2016-03-24 12:28:41 +01:00
|
|
|
data.self_id = id;
|
2017-01-31 10:41:25 +01:00
|
|
|
data.cb_flag = ID_IS_LINKED_DATABLOCK(id) ? IDWALK_CB_INDIRECT_USAGE : 0;
|
2016-03-24 12:28:41 +01:00
|
|
|
|
2017-01-30 21:41:44 +01:00
|
|
|
if (bmain != NULL && bmain->relations != NULL && (flag & IDWALK_READONLY)) {
|
|
|
|
/* Note that this is minor optimization, even in worst cases (like id being an object with lots of
|
|
|
|
* drivers and constraints and modifiers, or material etc. with huge node tree),
|
2017-11-05 14:33:18 +11:00
|
|
|
* but we might as well use it (Main->relations is always assumed valid, it's responsibility of code
|
2017-01-30 21:41:44 +01:00
|
|
|
* creating it to free it, especially if/when it starts modifying Main database). */
|
|
|
|
MainIDRelationsEntry *entry = BLI_ghash_lookup(bmain->relations->id_user_to_used, id);
|
|
|
|
for (; entry != NULL; entry = entry->next) {
|
|
|
|
FOREACH_CALLBACK_INVOKE_ID_PP(&data, entry->id_pointer, entry->usage_flag);
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
library_foreach_idproperty_ID_link(&data, id->properties, IDWALK_CB_USER);
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
AnimData *adt = BKE_animdata_from_id(id);
|
|
|
|
if (adt) {
|
|
|
|
library_foreach_animationData(&data, adt);
|
|
|
|
}
|
|
|
|
|
2016-08-05 16:12:44 +02:00
|
|
|
switch ((ID_Type)GS(id->name)) {
|
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
|
|
|
case ID_LI:
|
|
|
|
{
|
|
|
|
Library *lib = (Library *) id;
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(lib->parent, IDWALK_CB_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
|
|
|
break;
|
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_SCE:
|
|
|
|
{
|
|
|
|
Scene *scene = (Scene *) id;
|
|
|
|
ToolSettings *toolsett = scene->toolsettings;
|
|
|
|
SceneRenderLayer *srl;
|
|
|
|
Base *base;
|
|
|
|
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(scene->camera, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(scene->world, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(scene->set, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(scene->clip, IDWALK_CB_USER);
|
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 (scene->nodetree) {
|
|
|
|
/* nodetree **are owned by IDs**, treat them as mere sub-data and not real ID! */
|
2017-01-30 21:34:23 +01:00
|
|
|
library_foreach_ID_as_subdata_link((ID **)&scene->nodetree, callback, user_data, flag, &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
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
/* DO NOT handle scene->basact here, it's doubling with the loop over whole scene->base later,
|
|
|
|
* since basact is just a pointer to one of those items. */
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(scene->obedit, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
for (srl = scene->r.layers.first; srl; srl = srl->next) {
|
|
|
|
FreestyleModuleConfig *fmc;
|
|
|
|
FreestyleLineSet *fls;
|
|
|
|
|
|
|
|
if (srl->mat_override) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(srl->mat_override, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
if (srl->light_override) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(srl->light_override, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
for (fmc = srl->freestyleConfig.modules.first; fmc; fmc = fmc->next) {
|
|
|
|
if (fmc->script) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(fmc->script, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
for (fls = srl->freestyleConfig.linesets.first; fls; fls = fls->next) {
|
|
|
|
if (fls->group) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(fls->group, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
if (fls->linestyle) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(fls->linestyle, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
}
|
2014-06-06 12:51:14 +09:00
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
if (scene->ed) {
|
|
|
|
Sequence *seq;
|
|
|
|
SEQP_BEGIN(scene->ed, seq)
|
|
|
|
{
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(seq->scene, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(seq->scene_camera, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(seq->clip, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(seq->mask, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(seq->sound, IDWALK_CB_USER);
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
library_foreach_idproperty_ID_link(&data, seq->prop, IDWALK_CB_USER);
|
2016-06-16 21:09:01 +02:00
|
|
|
for (SequenceModifierData *smd = seq->modifiers.first; smd; smd = smd->next) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(smd->mask_id, IDWALK_CB_USER);
|
2016-06-16 21:09:01 +02:00
|
|
|
}
|
2014-06-06 12:44:48 +09:00
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
SEQ_END
|
2014-06-06 12:44:48 +09:00
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(scene->gpd, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
for (base = scene->base.first; base; base = base->next) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(base->object, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
|
2016-09-30 10:11:29 +02:00
|
|
|
for (TimeMarker *marker = scene->markers.first; marker; marker = marker->next) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(marker->camera, IDWALK_CB_NOP);
|
2016-09-30 10:11:29 +02:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
if (toolsett) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(toolsett->skgen_template, IDWALK_CB_NOP);
|
2016-06-16 21:09:01 +02:00
|
|
|
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(toolsett->particle.scene, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(toolsett->particle.object, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(toolsett->particle.shape_object, IDWALK_CB_NOP);
|
2016-06-16 21:09:01 +02:00
|
|
|
|
|
|
|
library_foreach_paint(&data, &toolsett->imapaint.paint);
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(toolsett->imapaint.stencil, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(toolsett->imapaint.clone, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(toolsett->imapaint.canvas, IDWALK_CB_USER);
|
2016-06-16 21:09:01 +02:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
if (toolsett->vpaint) {
|
2016-06-16 21:09:01 +02:00
|
|
|
library_foreach_paint(&data, &toolsett->vpaint->paint);
|
2014-06-06 12:44:48 +09:00
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
if (toolsett->wpaint) {
|
2016-06-16 21:09:01 +02:00
|
|
|
library_foreach_paint(&data, &toolsett->wpaint->paint);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
if (toolsett->sculpt) {
|
2016-06-16 21:09:01 +02:00
|
|
|
library_foreach_paint(&data, &toolsett->sculpt->paint);
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(toolsett->sculpt->gravity_object, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
if (toolsett->uvsculpt) {
|
2016-06-16 21:09:01 +02:00
|
|
|
library_foreach_paint(&data, &toolsett->uvsculpt->paint);
|
2014-06-06 12:44:48 +09:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
if (scene->rigidbody_world) {
|
|
|
|
BKE_rigidbody_world_id_loop(scene->rigidbody_world, library_foreach_rigidbodyworldSceneLooper, &data);
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(scene->gm.dome.warptext, IDWALK_CB_NOP);
|
2014-03-26 16:55:20 +06:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
2015-10-08 14:38:48 +02:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_OB:
|
|
|
|
{
|
|
|
|
Object *object = (Object *) id;
|
|
|
|
ParticleSystem *psys;
|
|
|
|
|
2016-07-08 19:33:22 +02:00
|
|
|
/* Object is special, proxies make things hard... */
|
2017-01-31 10:41:25 +01:00
|
|
|
const int data_cb_flag = data.cb_flag;
|
2017-06-26 18:55:30 +02:00
|
|
|
const int proxy_cb_flag = ((data.flag & IDWALK_NO_INDIRECT_PROXY_DATA_USAGE) == 0 && (object->proxy || object->proxy_group)) ?
|
|
|
|
IDWALK_CB_INDIRECT_USAGE : 0;
|
2016-07-08 19:33:22 +02:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
/* object data special case */
|
2017-01-31 10:41:25 +01:00
|
|
|
data.cb_flag |= proxy_cb_flag;
|
2016-03-24 12:28:41 +01:00
|
|
|
if (object->type == OB_EMPTY) {
|
|
|
|
/* empty can have NULL or Image */
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE_ID(object->data, IDWALK_CB_USER);
|
2015-10-08 14:38:48 +02:00
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
else {
|
|
|
|
/* when set, this can't be NULL */
|
|
|
|
if (object->data) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE_ID(object->data, IDWALK_CB_USER | IDWALK_CB_NEVER_NULL);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
2015-10-08 14:38:48 +02:00
|
|
|
}
|
2017-01-31 10:41:25 +01:00
|
|
|
data.cb_flag = data_cb_flag;
|
2016-03-24 12:28:41 +01:00
|
|
|
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(object->parent, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(object->track, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
/* object->proxy is refcounted, but not object->proxy_group... *sigh* */
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(object->proxy, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(object->proxy_group, IDWALK_CB_NOP);
|
2016-07-21 23:02:37 +02:00
|
|
|
|
|
|
|
/* Special case!
|
|
|
|
* Since this field is set/owned by 'user' of this ID (and not ID itself), it is only indirect usage
|
|
|
|
* if proxy object is linked... Twisted. */
|
|
|
|
if (object->proxy_from) {
|
2017-01-31 10:41:25 +01:00
|
|
|
data.cb_flag = ID_IS_LINKED_DATABLOCK(object->proxy_from) ? IDWALK_CB_INDIRECT_USAGE : 0;
|
2016-07-21 23:02:37 +02:00
|
|
|
}
|
2017-05-05 16:13:01 +02:00
|
|
|
CALLBACK_INVOKE(object->proxy_from, IDWALK_CB_LOOPBACK);
|
2017-01-31 10:41:25 +01:00
|
|
|
data.cb_flag = data_cb_flag;
|
2016-07-21 23:02:37 +02:00
|
|
|
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(object->poselib, IDWALK_CB_USER);
|
2016-07-08 19:33:22 +02:00
|
|
|
|
2017-01-31 10:41:25 +01:00
|
|
|
data.cb_flag |= proxy_cb_flag;
|
2016-03-24 12:28:41 +01:00
|
|
|
for (i = 0; i < object->totcol; i++) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(object->mat[i], IDWALK_CB_USER);
|
2015-10-08 14:38:48 +02:00
|
|
|
}
|
2017-01-31 10:41:25 +01:00
|
|
|
data.cb_flag = data_cb_flag;
|
2016-07-08 19:33:22 +02:00
|
|
|
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(object->gpd, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(object->dup_group, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
if (object->pd) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(object->pd->tex, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(object->pd->f_source, IDWALK_CB_NOP);
|
2015-10-08 14:38:48 +02:00
|
|
|
}
|
2016-06-16 21:09:01 +02:00
|
|
|
/* Note that ob->effect is deprecated, so no need to handle it here. */
|
2015-10-08 14:38:48 +02:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
if (object->pose) {
|
|
|
|
bPoseChannel *pchan;
|
2016-07-08 19:33:22 +02:00
|
|
|
|
2017-01-31 10:41:25 +01:00
|
|
|
data.cb_flag |= proxy_cb_flag;
|
2016-03-24 12:28:41 +01:00
|
|
|
for (pchan = object->pose->chanbase.first; pchan; pchan = pchan->next) {
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
library_foreach_idproperty_ID_link(&data, pchan->prop, IDWALK_CB_USER);
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(pchan->custom, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
BKE_constraints_id_loop(&pchan->constraints, library_foreach_constraintObjectLooper, &data);
|
|
|
|
}
|
2017-01-31 10:41:25 +01:00
|
|
|
data.cb_flag = data_cb_flag;
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
2015-10-08 14:59:24 +02:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
if (object->rigidbody_constraint) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(object->rigidbody_constraint->ob1, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(object->rigidbody_constraint->ob2, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
2016-01-16 12:46:04 +01:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
if (object->lodlevels.first) {
|
|
|
|
LodLevel *level;
|
|
|
|
for (level = object->lodlevels.first; level; level = level->next) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(level->source, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
}
|
2014-03-26 16:55:20 +06:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
modifiers_foreachIDLink(object, library_foreach_modifiersForeachIDLink, &data);
|
|
|
|
BKE_constraints_id_loop(&object->constraints, library_foreach_constraintObjectLooper, &data);
|
2015-10-08 19:18:30 +11:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
for (psys = object->particlesystem.first; psys; psys = psys->next) {
|
|
|
|
BKE_particlesystem_id_loop(psys, library_foreach_particlesystemsObjectLooper, &data);
|
2015-10-08 19:18:30 +11:00
|
|
|
}
|
|
|
|
|
2016-07-31 18:56:44 +10:00
|
|
|
if (object->soft) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(object->soft->collision_group, IDWALK_CB_NOP);
|
2016-07-31 18:56:44 +10:00
|
|
|
|
|
|
|
if (object->soft->effector_weights) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(object->soft->effector_weights->group, IDWALK_CB_NOP);
|
2016-07-31 18:56:44 +10: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
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
BKE_sca_sensors_id_loop(&object->sensors, library_foreach_sensorsObjectLooper, &data);
|
|
|
|
BKE_sca_controllers_id_loop(&object->controllers, library_foreach_controllersObjectLooper, &data);
|
|
|
|
BKE_sca_actuators_id_loop(&object->actuators, library_foreach_actuatorsObjectLooper, &data);
|
|
|
|
break;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
2015-10-07 20:50:34 +02:00
|
|
|
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
case ID_AR:
|
|
|
|
{
|
|
|
|
bArmature *arm = (bArmature *)id;
|
|
|
|
|
|
|
|
for (Bone *bone = arm->bonebase.first; bone; bone = bone->next) {
|
|
|
|
library_foreach_bone(&data, bone);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_ME:
|
|
|
|
{
|
|
|
|
Mesh *mesh = (Mesh *) id;
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(mesh->texcomesh, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(mesh->key, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
for (i = 0; i < mesh->totcol; i++) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(mesh->mat[i], IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
2016-07-08 17:28:28 +02:00
|
|
|
|
|
|
|
/* XXX Really not happy with this - probably texface should rather use some kind of
|
|
|
|
* 'texture slots' and just set indices in each poly/face item - would also save some memory.
|
|
|
|
* Maybe a nice TODO for blender2.8? */
|
|
|
|
if (mesh->mtface || mesh->mtpoly) {
|
|
|
|
for (i = 0; i < mesh->pdata.totlayer; i++) {
|
|
|
|
if (mesh->pdata.layers[i].type == CD_MTEXPOLY) {
|
|
|
|
MTexPoly *txface = (MTexPoly *)mesh->pdata.layers[i].data;
|
|
|
|
|
|
|
|
for (int j = 0; j < mesh->totpoly; j++, txface++) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(txface->tpage, IDWALK_CB_USER_ONE);
|
2016-07-08 17:28:28 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < mesh->fdata.totlayer; i++) {
|
|
|
|
if (mesh->fdata.layers[i].type == CD_MTFACE) {
|
|
|
|
MTFace *tface = (MTFace *)mesh->fdata.layers[i].data;
|
|
|
|
|
|
|
|
for (int j = 0; j < mesh->totface; j++, tface++) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(tface->tpage, IDWALK_CB_USER_ONE);
|
2016-07-08 17:28:28 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2015-10-08 18:08:57 +11:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_CU:
|
|
|
|
{
|
|
|
|
Curve *curve = (Curve *) id;
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(curve->bevobj, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(curve->taperobj, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(curve->textoncurve, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(curve->key, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
for (i = 0; i < curve->totcol; i++) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(curve->mat[i], IDWALK_CB_USER);
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(curve->vfont, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(curve->vfontb, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(curve->vfonti, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(curve->vfontbi, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_MB:
|
|
|
|
{
|
|
|
|
MetaBall *metaball = (MetaBall *) id;
|
|
|
|
for (i = 0; i < metaball->totcol; i++) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(metaball->mat[i], IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
break;
|
2015-10-08 18:08:57 +11:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_MA:
|
|
|
|
{
|
|
|
|
Material *material = (Material *) id;
|
|
|
|
for (i = 0; i < MAX_MTEX; i++) {
|
|
|
|
if (material->mtex[i]) {
|
|
|
|
library_foreach_mtex(&data, material->mtex[i]);
|
|
|
|
}
|
2015-10-08 18:08:57 +11: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 (material->nodetree) {
|
|
|
|
/* nodetree **are owned by IDs**, treat them as mere sub-data and not real ID! */
|
2017-01-30 21:34:23 +01:00
|
|
|
library_foreach_ID_as_subdata_link((ID **)&material->nodetree, callback, user_data, flag, &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
|
|
|
}
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(material->group, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2015-10-08 18:08:57 +11:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_TE:
|
|
|
|
{
|
|
|
|
Tex *texture = (Tex *) 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
|
|
|
if (texture->nodetree) {
|
|
|
|
/* nodetree **are owned by IDs**, treat them as mere sub-data and not real ID! */
|
2017-01-30 21:34:23 +01:00
|
|
|
library_foreach_ID_as_subdata_link((ID **)&texture->nodetree, callback, user_data, flag, &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
|
|
|
}
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(texture->ima, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
if (texture->env) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(texture->env->object, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(texture->env->ima, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
if (texture->pd)
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(texture->pd->object, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
if (texture->vd)
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(texture->vd->object, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
if (texture->ot)
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(texture->ot->object, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2015-10-08 14:56:20 +02:00
|
|
|
}
|
2015-10-08 15:04:09 +02:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_LT:
|
|
|
|
{
|
|
|
|
Lattice *lattice = (Lattice *) id;
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(lattice->key, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_LA:
|
|
|
|
{
|
|
|
|
Lamp *lamp = (Lamp *) id;
|
|
|
|
for (i = 0; i < MAX_MTEX; i++) {
|
|
|
|
if (lamp->mtex[i]) {
|
|
|
|
library_foreach_mtex(&data, lamp->mtex[i]);
|
|
|
|
}
|
|
|
|
}
|
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 (lamp->nodetree) {
|
|
|
|
/* nodetree **are owned by IDs**, treat them as mere sub-data and not real ID! */
|
2017-01-30 21:34:23 +01:00
|
|
|
library_foreach_ID_as_subdata_link((ID **)&lamp->nodetree, callback, user_data, flag, &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
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_CA:
|
|
|
|
{
|
|
|
|
Camera *camera = (Camera *) id;
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(camera->dof_ob, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_KE:
|
|
|
|
{
|
|
|
|
Key *key = (Key *) id;
|
2017-05-05 16:13:01 +02:00
|
|
|
CALLBACK_INVOKE_ID(key->from, IDWALK_CB_LOOPBACK);
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_SCR:
|
|
|
|
{
|
|
|
|
bScreen *screen = (bScreen *) id;
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(screen->scene, IDWALK_CB_USER_ONE);
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2015-10-08 14:38:48 +02:00
|
|
|
}
|
2014-03-26 16:55:20 +06:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_WO:
|
|
|
|
{
|
|
|
|
World *world = (World *) id;
|
|
|
|
for (i = 0; i < MAX_MTEX; i++) {
|
|
|
|
if (world->mtex[i]) {
|
|
|
|
library_foreach_mtex(&data, world->mtex[i]);
|
|
|
|
}
|
2014-03-26 16:55:20 +06: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 (world->nodetree) {
|
|
|
|
/* nodetree **are owned by IDs**, treat them as mere sub-data and not real ID! */
|
2017-01-30 21:34:23 +01:00
|
|
|
library_foreach_ID_as_subdata_link((ID **)&world->nodetree, callback, user_data, flag, &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
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_SPK:
|
|
|
|
{
|
|
|
|
Speaker *speaker = (Speaker *) id;
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(speaker->sound, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
|
|
|
}
|
2014-03-26 16:55:20 +06:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_GR:
|
|
|
|
{
|
|
|
|
Group *group = (Group *) id;
|
|
|
|
GroupObject *gob;
|
|
|
|
for (gob = group->gobject.first; gob; gob = gob->next) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(gob->ob, IDWALK_CB_USER_ONE);
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_NT:
|
|
|
|
{
|
|
|
|
bNodeTree *ntree = (bNodeTree *) id;
|
|
|
|
bNode *node;
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
bNodeSocket *sock;
|
|
|
|
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(ntree->gpd, IDWALK_CB_USER);
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
for (node = ntree->nodes.first; node; node = node->next) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE_ID(node->id, IDWALK_CB_USER);
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
|
|
|
|
library_foreach_idproperty_ID_link(&data, node->prop, IDWALK_CB_USER);
|
|
|
|
for (sock = node->inputs.first; sock; sock = sock->next) {
|
|
|
|
library_foreach_idproperty_ID_link(&data, sock->prop, IDWALK_CB_USER);
|
|
|
|
}
|
|
|
|
for (sock = node->outputs.first; sock; sock = sock->next) {
|
|
|
|
library_foreach_idproperty_ID_link(&data, sock->prop, IDWALK_CB_USER);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (sock = ntree->inputs.first; sock; sock = sock->next) {
|
|
|
|
library_foreach_idproperty_ID_link(&data, sock->prop, IDWALK_CB_USER);
|
|
|
|
}
|
|
|
|
for (sock = ntree->outputs.first; sock; sock = sock->next) {
|
|
|
|
library_foreach_idproperty_ID_link(&data, sock->prop, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
break;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_BR:
|
|
|
|
{
|
|
|
|
Brush *brush = (Brush *) id;
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(brush->toggle_brush, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(brush->clone.image, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(brush->paint_curve, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
library_foreach_mtex(&data, &brush->mtex);
|
|
|
|
library_foreach_mtex(&data, &brush->mask_mtex);
|
|
|
|
break;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_PA:
|
|
|
|
{
|
|
|
|
ParticleSettings *psett = (ParticleSettings *) id;
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(psett->dup_group, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(psett->dup_ob, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(psett->bb_ob, IDWALK_CB_NOP);
|
|
|
|
CALLBACK_INVOKE(psett->collision_group, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
for (i = 0; i < MAX_MTEX; i++) {
|
|
|
|
if (psett->mtex[i]) {
|
|
|
|
library_foreach_mtex(&data, psett->mtex[i]);
|
|
|
|
}
|
2015-10-08 14:38:48 +02:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
if (psett->effector_weights) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(psett->effector_weights->group, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
2015-10-08 14:38:48 +02:00
|
|
|
|
2016-06-16 21:09:01 +02:00
|
|
|
if (psett->pd) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(psett->pd->tex, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(psett->pd->f_source, IDWALK_CB_NOP);
|
2016-06-16 21:09:01 +02:00
|
|
|
}
|
|
|
|
if (psett->pd2) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(psett->pd2->tex, IDWALK_CB_USER);
|
|
|
|
CALLBACK_INVOKE(psett->pd2->f_source, IDWALK_CB_NOP);
|
2016-06-16 21:09:01 +02:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
if (psett->boids) {
|
|
|
|
BoidState *state;
|
|
|
|
BoidRule *rule;
|
|
|
|
|
|
|
|
for (state = psett->boids->states.first; state; state = state->next) {
|
|
|
|
for (rule = state->rules.first; rule; rule = rule->next) {
|
|
|
|
if (rule->type == eBoidRuleType_Avoid) {
|
|
|
|
BoidRuleGoalAvoid *gabr = (BoidRuleGoalAvoid *)rule;
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(gabr->ob, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
|
|
|
else if (rule->type == eBoidRuleType_FollowLeader) {
|
|
|
|
BoidRuleFollowLeader *flbr = (BoidRuleFollowLeader *)rule;
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(flbr->ob, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
2015-10-08 14:38:48 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
|
|
|
}
|
2014-03-26 16:55:20 +06:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_MC:
|
|
|
|
{
|
|
|
|
MovieClip *clip = (MovieClip *) id;
|
|
|
|
MovieTracking *tracking = &clip->tracking;
|
|
|
|
MovieTrackingObject *object;
|
2016-06-16 21:09:01 +02:00
|
|
|
MovieTrackingTrack *track;
|
|
|
|
MovieTrackingPlaneTrack *plane_track;
|
2015-10-07 20:50:34 +02:00
|
|
|
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(clip->gpd, IDWALK_CB_USER);
|
2015-10-07 20:50:34 +02:00
|
|
|
|
2016-06-16 21:09:01 +02:00
|
|
|
for (track = tracking->tracks.first; track; track = track->next) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(track->gpd, IDWALK_CB_USER);
|
2016-06-16 21:09:01 +02:00
|
|
|
}
|
|
|
|
for (object = tracking->objects.first; object; object = object->next) {
|
|
|
|
for (track = object->tracks.first; track; track = track->next) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(track->gpd, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
2016-06-16 21:09:01 +02:00
|
|
|
|
|
|
|
for (plane_track = tracking->plane_tracks.first; plane_track; plane_track = plane_track->next) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(plane_track->image, IDWALK_CB_USER);
|
2016-06-16 21:09:01 +02:00
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_MSK:
|
|
|
|
{
|
|
|
|
Mask *mask = (Mask *) id;
|
|
|
|
MaskLayer *mask_layer;
|
|
|
|
for (mask_layer = mask->masklayers.first; mask_layer; mask_layer = mask_layer->next) {
|
|
|
|
MaskSpline *mask_spline;
|
|
|
|
|
|
|
|
for (mask_spline = mask_layer->splines.first; mask_spline; mask_spline = mask_spline->next) {
|
|
|
|
for (i = 0; i < mask_spline->tot_point; i++) {
|
|
|
|
MaskSplinePoint *point = &mask_spline->points[i];
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE_ID(point->parent.id, IDWALK_CB_USER);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
2014-05-03 18:51:53 +09:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
case ID_LS:
|
|
|
|
{
|
|
|
|
FreestyleLineStyle *linestyle = (FreestyleLineStyle *) id;
|
|
|
|
LineStyleModifier *lsm;
|
|
|
|
for (i = 0; i < MAX_MTEX; i++) {
|
|
|
|
if (linestyle->mtex[i]) {
|
|
|
|
library_foreach_mtex(&data, linestyle->mtex[i]);
|
|
|
|
}
|
2014-05-03 18:51:53 +09: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 (linestyle->nodetree) {
|
|
|
|
/* nodetree **are owned by IDs**, treat them as mere sub-data and not real ID! */
|
2017-01-30 21:34:23 +01:00
|
|
|
library_foreach_ID_as_subdata_link((ID **)&linestyle->nodetree, callback, user_data, flag, &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
|
|
|
}
|
2014-06-06 12:44:48 +09:00
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
for (lsm = linestyle->color_modifiers.first; lsm; lsm = lsm->next) {
|
|
|
|
if (lsm->type == LS_MODIFIER_DISTANCE_FROM_OBJECT) {
|
|
|
|
LineStyleColorModifier_DistanceFromObject *p = (LineStyleColorModifier_DistanceFromObject *)lsm;
|
|
|
|
if (p->target) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(p->target, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
2014-06-06 12:44:48 +09:00
|
|
|
}
|
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
for (lsm = linestyle->alpha_modifiers.first; lsm; lsm = lsm->next) {
|
|
|
|
if (lsm->type == LS_MODIFIER_DISTANCE_FROM_OBJECT) {
|
|
|
|
LineStyleAlphaModifier_DistanceFromObject *p = (LineStyleAlphaModifier_DistanceFromObject *)lsm;
|
|
|
|
if (p->target) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(p->target, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
2014-06-06 12:44:48 +09:00
|
|
|
}
|
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
for (lsm = linestyle->thickness_modifiers.first; lsm; lsm = lsm->next) {
|
|
|
|
if (lsm->type == LS_MODIFIER_DISTANCE_FROM_OBJECT) {
|
|
|
|
LineStyleThicknessModifier_DistanceFromObject *p = (LineStyleThicknessModifier_DistanceFromObject *)lsm;
|
|
|
|
if (p->target) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(p->target, IDWALK_CB_NOP);
|
2016-03-24 12:28:41 +01:00
|
|
|
}
|
2014-06-06 12:44:48 +09:00
|
|
|
}
|
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
break;
|
2014-06-06 12:44:48 +09:00
|
|
|
}
|
2016-09-30 10:11:29 +02:00
|
|
|
case ID_AC:
|
|
|
|
{
|
|
|
|
bAction *act = (bAction *) id;
|
|
|
|
|
|
|
|
for (TimeMarker *marker = act->markers.first; marker; marker = marker->next) {
|
2017-01-31 09:47:59 +01:00
|
|
|
CALLBACK_INVOKE(marker->camera, IDWALK_CB_NOP);
|
2016-09-30 10:11:29 +02:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2017-04-19 21:47:01 +02:00
|
|
|
case ID_GD:
|
|
|
|
{
|
|
|
|
bGPdata *gpencil = (bGPdata *) id;
|
|
|
|
|
|
|
|
for (bGPDlayer *gp_layer = gpencil->layers.first; gp_layer; gp_layer = gp_layer->next) {
|
|
|
|
CALLBACK_INVOKE(gp_layer->parent, IDWALK_CB_NOP);
|
|
|
|
}
|
2017-04-24 21:58:28 +10:00
|
|
|
break;
|
2017-04-19 21:47:01 +02:00
|
|
|
}
|
2016-08-05 16:12:44 +02:00
|
|
|
|
|
|
|
/* Nothing needed for those... */
|
|
|
|
case ID_IM:
|
|
|
|
case ID_VF:
|
|
|
|
case ID_TXT:
|
|
|
|
case ID_SO:
|
|
|
|
case ID_WM:
|
|
|
|
case ID_PAL:
|
|
|
|
case ID_PC:
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
case ID_CF:
|
2016-08-05 16:12:44 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
/* Deprecated. */
|
|
|
|
case ID_IP:
|
|
|
|
break;
|
|
|
|
|
2014-05-03 18:51:53 +09:00
|
|
|
}
|
2017-01-30 21:41:44 +01:00
|
|
|
}
|
2016-03-24 12:28:41 +01:00
|
|
|
|
|
|
|
FOREACH_FINALIZE:
|
|
|
|
if (data.ids_handled) {
|
|
|
|
BLI_gset_free(data.ids_handled, NULL);
|
|
|
|
BLI_LINKSTACK_FREE(data.ids_todo);
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
2014-03-31 05:44:32 +11:00
|
|
|
#undef CALLBACK_INVOKE_ID
|
|
|
|
#undef CALLBACK_INVOKE
|
2014-03-26 16:55:20 +06:00
|
|
|
}
|
|
|
|
|
|
|
|
#undef FOREACH_CALLBACK_INVOKE_ID
|
|
|
|
#undef FOREACH_CALLBACK_INVOKE
|
2015-10-08 20:29:49 +11:00
|
|
|
|
|
|
|
/**
|
|
|
|
* re-usable function, use when replacing ID's
|
|
|
|
*/
|
2017-01-31 10:41:25 +01:00
|
|
|
void BKE_library_update_ID_link_user(ID *id_dst, ID *id_src, const int cb_flag)
|
2015-10-08 20:29:49 +11:00
|
|
|
{
|
2017-01-31 10:41:25 +01:00
|
|
|
if (cb_flag & IDWALK_CB_USER) {
|
2015-10-08 20:29:49 +11:00
|
|
|
id_us_min(id_src);
|
|
|
|
id_us_plus(id_dst);
|
|
|
|
}
|
2017-01-31 10:41:25 +01:00
|
|
|
else if (cb_flag & IDWALK_CB_USER_ONE) {
|
2015-11-09 21:15:11 +01:00
|
|
|
id_us_ensure_real(id_dst);
|
2015-10-08 20:29:49 +11:00
|
|
|
}
|
2015-10-08 14:38:48 +02:00
|
|
|
}
|
2016-01-06 19:34:42 +01:00
|
|
|
|
2016-07-07 20:51:21 +02:00
|
|
|
/**
|
|
|
|
* Say whether given \a id_type_owner can use (in any way) a datablock of \a id_type_used.
|
2016-07-19 10:23:26 +10:00
|
|
|
*
|
|
|
|
* This is a 'simplified' abstract version of #BKE_library_foreach_ID_link() above, quite useful to reduce
|
|
|
|
* useless iterations in some cases.
|
2016-07-07 20:51:21 +02:00
|
|
|
*/
|
2016-09-22 16:11:16 +02:00
|
|
|
/* XXX This has to be fully rethink, basing check on ID type is not really working anymore (and even worth once
|
|
|
|
* IDProps will support ID pointers), we'll have to do some quick checks on IDs themselves... */
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
bool BKE_library_id_can_use_idtype(ID *id_owner, const short id_type_used)
|
2016-07-07 20:51:21 +02:00
|
|
|
{
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
/* any type of ID can be used in custom props. */
|
|
|
|
if (id_owner->properties) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
const short id_type_owner = GS(id_owner->name);
|
|
|
|
|
|
|
|
/* IDProps of armature bones and nodes, and bNode->id can use virtually any type of ID. */
|
|
|
|
if (ELEM(id_type_owner, ID_NT, ID_AR)) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ntreeFromID(id_owner)) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (BKE_animdata_from_id(id_owner)) {
|
2016-09-22 16:11:16 +02:00
|
|
|
return true; /* AnimationData can use virtually any kind of datablocks, through drivers especially. */
|
2016-07-07 20:51:21 +02:00
|
|
|
}
|
|
|
|
|
2016-08-06 12:56:15 +02:00
|
|
|
switch ((ID_Type)id_type_owner) {
|
2016-07-07 20:51:21 +02:00
|
|
|
case ID_LI:
|
|
|
|
return ELEM(id_type_used, ID_LI);
|
|
|
|
case ID_SCE:
|
|
|
|
return (ELEM(id_type_used, ID_OB, ID_WO, ID_SCE, ID_MC, ID_MA, ID_GR, ID_TXT,
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
ID_LS, ID_MSK, ID_SO, ID_GD, ID_BR, ID_PAL, ID_IM, ID_NT));
|
2016-07-07 20:51:21 +02:00
|
|
|
case ID_OB:
|
|
|
|
/* Could be the following, but simpler to just always say 'yes' here. */
|
|
|
|
#if 0
|
|
|
|
return ELEM(id_type_used, ID_ME, ID_CU, ID_MB, ID_LT, ID_SPK, ID_AR, ID_LA, ID_CA, /* obdata */
|
|
|
|
ID_OB, ID_MA, ID_GD, ID_GR, ID_TE, ID_PA, ID_TXT, ID_SO, ID_MC, ID_IM, ID_AC
|
|
|
|
/* + constraints, modifiers and game logic ID types... */);
|
|
|
|
#else
|
|
|
|
return true;
|
|
|
|
#endif
|
|
|
|
case ID_ME:
|
|
|
|
return ELEM(id_type_used, ID_ME, ID_KE, ID_MA);
|
|
|
|
case ID_CU:
|
|
|
|
return ELEM(id_type_used, ID_OB, ID_KE, ID_MA, ID_VF);
|
|
|
|
case ID_MB:
|
|
|
|
return ELEM(id_type_used, ID_MA);
|
|
|
|
case ID_MA:
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
return (ELEM(id_type_used, ID_TE, ID_GR));
|
2016-07-07 20:51:21 +02:00
|
|
|
case ID_TE:
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
return (ELEM(id_type_used, ID_IM, ID_OB));
|
2016-07-07 20:51:21 +02:00
|
|
|
case ID_LT:
|
|
|
|
return ELEM(id_type_used, ID_KE);
|
|
|
|
case ID_LA:
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
return (ELEM(id_type_used, ID_TE));
|
2016-07-07 20:51:21 +02:00
|
|
|
case ID_CA:
|
|
|
|
return ELEM(id_type_used, ID_OB);
|
|
|
|
case ID_KE:
|
|
|
|
return ELEM(id_type_used, ID_ME, ID_CU, ID_LT); /* Warning! key->from, could be more types in future? */
|
|
|
|
case ID_SCR:
|
|
|
|
return ELEM(id_type_used, ID_SCE);
|
|
|
|
case ID_WO:
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
return (ELEM(id_type_used, ID_TE));
|
2016-07-07 20:51:21 +02:00
|
|
|
case ID_SPK:
|
|
|
|
return ELEM(id_type_used, ID_SO);
|
|
|
|
case ID_GR:
|
|
|
|
return ELEM(id_type_used, ID_OB);
|
|
|
|
case ID_NT:
|
|
|
|
/* Could be the following, but node.id has no type restriction... */
|
|
|
|
#if 0
|
|
|
|
return ELEM(id_type_used, ID_GD /* + node.id types... */);
|
|
|
|
#else
|
|
|
|
return true;
|
|
|
|
#endif
|
|
|
|
case ID_BR:
|
|
|
|
return ELEM(id_type_used, ID_BR, ID_IM, ID_PC, ID_TE);
|
|
|
|
case ID_PA:
|
|
|
|
return ELEM(id_type_used, ID_OB, ID_GR, ID_TE);
|
|
|
|
case ID_MC:
|
|
|
|
return ELEM(id_type_used, ID_GD, ID_IM);
|
|
|
|
case ID_MSK:
|
|
|
|
return ELEM(id_type_used, ID_MC); /* WARNING! mask->parent.id, not typed. */
|
|
|
|
case ID_LS:
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
return (ELEM(id_type_used, ID_TE, ID_OB));
|
2016-08-06 12:56:15 +02:00
|
|
|
case ID_IM:
|
|
|
|
case ID_VF:
|
|
|
|
case ID_TXT:
|
|
|
|
case ID_SO:
|
|
|
|
case ID_AR:
|
|
|
|
case ID_AC:
|
|
|
|
case ID_GD:
|
|
|
|
case ID_WM:
|
|
|
|
case ID_PAL:
|
|
|
|
case ID_PC:
|
|
|
|
case ID_CF:
|
|
|
|
/* Those types never use/reference other IDs... */
|
|
|
|
return false;
|
|
|
|
case ID_IP:
|
|
|
|
/* Deprecated... */
|
2016-07-07 20:51:21 +02:00
|
|
|
return false;
|
|
|
|
}
|
2016-08-06 12:56:15 +02:00
|
|
|
return false;
|
2016-07-07 20:51:21 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-01-06 19:34:42 +01:00
|
|
|
/* ***** ID users iterator. ***** */
|
|
|
|
typedef struct IDUsersIter {
|
|
|
|
ID *id;
|
|
|
|
|
|
|
|
ListBase *lb_array[MAX_LIBARRAY];
|
|
|
|
int lb_idx;
|
|
|
|
|
|
|
|
ID *curr_id;
|
2016-07-08 19:33:22 +02:00
|
|
|
int count_direct, count_indirect; /* Set by callback. */
|
2016-01-06 19:34:42 +01:00
|
|
|
} IDUsersIter;
|
|
|
|
|
2017-05-05 16:13:01 +02:00
|
|
|
static int foreach_libblock_id_users_callback(void *user_data, ID *UNUSED(self_id), ID **id_p, int cb_flag)
|
2016-01-06 19:34:42 +01:00
|
|
|
{
|
|
|
|
IDUsersIter *iter = user_data;
|
|
|
|
|
2016-10-19 14:29:43 +02:00
|
|
|
if (*id_p) {
|
2017-05-05 16:13:01 +02:00
|
|
|
/* 'Loopback' ID pointers (the ugly 'from' ones, Object->proxy_from and Key->from).
|
|
|
|
* Those are not actually ID usage, we can ignore them here.
|
2016-10-19 14:29:43 +02:00
|
|
|
*/
|
2017-05-05 16:13:01 +02:00
|
|
|
if (cb_flag & IDWALK_CB_LOOPBACK) {
|
2016-10-19 14:29:43 +02:00
|
|
|
return IDWALK_RET_NOP;
|
|
|
|
}
|
Fix T48971: Append creates linked image textures if object has shape keys.
Hating all those not-so-real ID types... Here there were two causes for the issue:
1) Linked shapekey ID was made local twice (once from mesh's make local, once by itself).
Solved by not explicitely making shapekeys (nor any other non-linkable datatype) local.
2) Key->from 'back pointer' to its owner was messing 'still in used' detection of linked data
after localization. Fixed with a hack for now, thinking correct solution might actually
be to not consider this pointer at all in libquery ID looper, since it's nothing like
and actual usage of mesh/lattice/curve.
Again, shapekeys as ID is a joke, those should be mere struct, they have absolutely nothing to do in Main, period. :(
Point 2) still demonstrates the need for better handling of IDs dependencies though,
so far we only hit corner cases, but think there could also be valid cases generating those
'dependency cycles' between IDs (ID a using ID b which uses ID a), this will have to be addressed some day...
2016-07-29 17:00:29 +02:00
|
|
|
|
2016-10-19 14:29:43 +02:00
|
|
|
if (*id_p == iter->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
|
|
|
#if 0
|
2016-10-19 14:29:43 +02:00
|
|
|
printf("%s uses %s (refcounted: %d, userone: %d, used_one: %d, used_one_active: %d, indirect_usage: %d)\n",
|
|
|
|
iter->curr_id->name, iter->id->name, (cb_flag & IDWALK_USER) ? 1 : 0, (cb_flag & IDWALK_USER_ONE) ? 1 : 0,
|
|
|
|
(iter->id->tag & LIB_TAG_EXTRAUSER) ? 1 : 0, (iter->id->tag & LIB_TAG_EXTRAUSER_SET) ? 1 : 0,
|
|
|
|
(cb_flag & IDWALK_INDIRECT_USAGE) ? 1 : 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
|
|
|
#endif
|
2017-01-31 09:47:59 +01:00
|
|
|
if (cb_flag & IDWALK_CB_INDIRECT_USAGE) {
|
2016-10-19 14:29:43 +02:00
|
|
|
iter->count_indirect++;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
iter->count_direct++;
|
|
|
|
}
|
2016-07-08 19:33:22 +02:00
|
|
|
}
|
2016-01-06 19:34:42 +01:00
|
|
|
}
|
|
|
|
|
2016-03-24 12:28:41 +01:00
|
|
|
return IDWALK_RET_NOP;
|
2016-01-06 19:34:42 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Return the number of times given \a id_user uses/references \a id_used.
|
|
|
|
*
|
|
|
|
* \note This only checks for pointer references of an ID, shallow usages (like e.g. by RNA paths, as done
|
|
|
|
* for FCurves) are not detected at all.
|
|
|
|
*
|
|
|
|
* \param id_user the ID which is supposed to use (reference) \a id_used.
|
|
|
|
* \param id_used the ID which is supposed to be used (referenced) by \a id_user.
|
|
|
|
* \return the number of direct usages/references of \a id_used by \a id_user.
|
|
|
|
*/
|
|
|
|
int BKE_library_ID_use_ID(ID *id_user, ID *id_used)
|
|
|
|
{
|
|
|
|
IDUsersIter iter;
|
|
|
|
|
|
|
|
/* We do not care about iter.lb_array/lb_idx here... */
|
|
|
|
iter.id = id_used;
|
|
|
|
iter.curr_id = id_user;
|
2016-07-08 19:33:22 +02:00
|
|
|
iter.count_direct = iter.count_indirect = 0;
|
2016-01-06 19:34:42 +01:00
|
|
|
|
2017-01-30 21:41:44 +01:00
|
|
|
BKE_library_foreach_ID_link(NULL, iter.curr_id, foreach_libblock_id_users_callback, (void *)&iter, IDWALK_READONLY);
|
2016-01-06 19:34:42 +01:00
|
|
|
|
2016-07-08 19:33:22 +02:00
|
|
|
return iter.count_direct + iter.count_indirect;
|
"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
|
|
|
}
|
|
|
|
|
2016-07-07 19:39:14 +02:00
|
|
|
static bool library_ID_is_used(Main *bmain, void *idv, const bool check_linked)
|
"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
|
|
|
{
|
|
|
|
IDUsersIter iter;
|
|
|
|
ListBase *lb_array[MAX_LIBARRAY];
|
2016-07-07 21:18:04 +02:00
|
|
|
ID *id = idv;
|
"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
|
|
|
int i = set_listbasepointers(bmain, lb_array);
|
2016-07-07 19:39:14 +02:00
|
|
|
bool is_defined = false;
|
"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
|
|
|
|
2016-07-07 21:18:04 +02:00
|
|
|
iter.id = id;
|
2016-07-08 19:33:22 +02:00
|
|
|
iter.count_direct = iter.count_indirect = 0;
|
2016-07-07 19:39:14 +02:00
|
|
|
while (i-- && !is_defined) {
|
"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
|
|
|
ID *id_curr = lb_array[i]->first;
|
|
|
|
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
if (!id_curr || !BKE_library_id_can_use_idtype(id_curr, GS(id->name))) {
|
2016-07-07 21:18:04 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2016-07-07 19:39:14 +02:00
|
|
|
for (; id_curr && !is_defined; id_curr = id_curr->next) {
|
2016-07-26 15:12:43 +02:00
|
|
|
if (id_curr == id) {
|
|
|
|
/* We are not interested in self-usages (mostly from drivers or bone constraints...). */
|
|
|
|
continue;
|
|
|
|
}
|
"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
|
|
|
iter.curr_id = id_curr;
|
|
|
|
BKE_library_foreach_ID_link(
|
2017-01-30 21:41:44 +01:00
|
|
|
bmain, id_curr, foreach_libblock_id_users_callback, &iter, IDWALK_READONLY);
|
"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
|
|
|
|
2016-07-08 19:33:22 +02:00
|
|
|
is_defined = ((check_linked ? iter.count_indirect : iter.count_direct) != 0);
|
"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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-07 19:39:14 +02:00
|
|
|
return is_defined;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2016-07-07 20:51:21 +02:00
|
|
|
* Check whether given ID is used locally (i.e. by another non-linked ID).
|
2016-07-07 19:39:14 +02:00
|
|
|
*/
|
|
|
|
bool BKE_library_ID_is_locally_used(Main *bmain, void *idv)
|
|
|
|
{
|
|
|
|
return library_ID_is_used(bmain, idv, false);
|
"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
|
|
|
}
|
|
|
|
|
2016-07-07 19:39:14 +02:00
|
|
|
/**
|
2016-07-07 20:51:21 +02:00
|
|
|
* Check whether given ID is used indirectly (i.e. by another linked ID).
|
2016-07-07 19:39:14 +02:00
|
|
|
*/
|
|
|
|
bool BKE_library_ID_is_indirectly_used(Main *bmain, void *idv)
|
|
|
|
{
|
|
|
|
return library_ID_is_used(bmain, idv, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Combine \a BKE_library_ID_is_locally_used() and \a BKE_library_ID_is_indirectly_used() in a single call.
|
|
|
|
*/
|
|
|
|
void BKE_library_ID_test_usages(Main *bmain, void *idv, bool *is_used_local, bool *is_used_linked)
|
|
|
|
{
|
2016-07-08 19:33:22 +02:00
|
|
|
IDUsersIter iter;
|
2016-07-07 19:39:14 +02:00
|
|
|
ListBase *lb_array[MAX_LIBARRAY];
|
2016-07-07 21:18:04 +02:00
|
|
|
ID *id = idv;
|
2016-07-07 19:39:14 +02:00
|
|
|
int i = set_listbasepointers(bmain, lb_array);
|
|
|
|
bool is_defined = false;
|
|
|
|
|
2016-07-08 19:33:22 +02:00
|
|
|
iter.id = id;
|
|
|
|
iter.count_direct = iter.count_indirect = 0;
|
2016-07-07 19:39:14 +02:00
|
|
|
while (i-- && !is_defined) {
|
|
|
|
ID *id_curr = lb_array[i]->first;
|
|
|
|
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
if (!id_curr || !BKE_library_id_can_use_idtype(id_curr, GS(id->name))) {
|
2016-07-07 21:18:04 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2016-07-07 19:39:14 +02:00
|
|
|
for (; id_curr && !is_defined; id_curr = id_curr->next) {
|
2016-07-26 15:12:43 +02:00
|
|
|
if (id_curr == id) {
|
|
|
|
/* We are not interested in self-usages (mostly from drivers or bone constraints...). */
|
|
|
|
continue;
|
|
|
|
}
|
2016-07-08 19:33:22 +02:00
|
|
|
iter.curr_id = id_curr;
|
2017-01-30 21:41:44 +01:00
|
|
|
BKE_library_foreach_ID_link(bmain, id_curr, foreach_libblock_id_users_callback, &iter, IDWALK_READONLY);
|
2016-07-07 19:39:14 +02:00
|
|
|
|
2016-07-08 19:33:22 +02:00
|
|
|
is_defined = (iter.count_direct != 0 && iter.count_indirect != 0);
|
2016-07-07 19:39:14 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-08 19:33:22 +02:00
|
|
|
*is_used_local = (iter.count_direct != 0);
|
|
|
|
*is_used_linked = (iter.count_indirect != 0);
|
2016-07-07 19:39:14 +02:00
|
|
|
}
|
2016-10-19 14:29:43 +02:00
|
|
|
|
2016-11-11 22:29:54 +01:00
|
|
|
/* ***** IDs usages.checking/tagging. ***** */
|
|
|
|
static int foreach_libblock_used_linked_data_tag_clear_cb(
|
|
|
|
void *user_data, ID *self_id, ID **id_p, int UNUSED(cb_flag))
|
2016-10-19 14:29:43 +02:00
|
|
|
{
|
|
|
|
bool *is_changed = user_data;
|
|
|
|
|
|
|
|
if (*id_p) {
|
|
|
|
/* XXX This is actually some kind of hack...
|
|
|
|
* Issue is, shapekeys' 'from' ID pointer is not actually ID usage.
|
|
|
|
* Maybe we should even nuke it from BKE_library_foreach_ID_link, not 100% sure yet...
|
|
|
|
*/
|
|
|
|
if ((GS(self_id->name) == ID_KE) && (((Key *)self_id)->from == *id_p)) {
|
|
|
|
return IDWALK_RET_NOP;
|
|
|
|
}
|
|
|
|
/* XXX another hack, for similar reasons as above one. */
|
|
|
|
if ((GS(self_id->name) == ID_OB) && (((Object *)self_id)->proxy_from == (Object *)*id_p)) {
|
|
|
|
return IDWALK_RET_NOP;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If checked id is used by an assumed used ID, then it is also used and not part of any linked archipelago. */
|
|
|
|
if (!(self_id->tag & LIB_TAG_DOIT) && ((*id_p)->tag & LIB_TAG_DOIT)) {
|
|
|
|
(*id_p)->tag &= ~LIB_TAG_DOIT;
|
|
|
|
*is_changed = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return IDWALK_RET_NOP;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Detect orphaned linked data blocks (i.e. linked data not used (directly or indirectly) in any way by any local data),
|
|
|
|
* including complex cases like 'linked archipelagoes', i.e. linked datablocks that use each other in loops,
|
|
|
|
* which prevents their deletion by 'basic' usage checks...
|
|
|
|
*
|
|
|
|
* \param do_init_tag if \a true, all linked data are checked, if \a false, only linked datablocks already tagged with
|
|
|
|
* LIB_TAG_DOIT are checked.
|
|
|
|
*/
|
2016-11-11 22:56:47 +01:00
|
|
|
void BKE_library_unused_linked_data_set_tag(Main *bmain, const bool do_init_tag)
|
2016-10-19 14:29:43 +02:00
|
|
|
{
|
|
|
|
ListBase *lb_array[MAX_LIBARRAY];
|
|
|
|
|
|
|
|
if (do_init_tag) {
|
|
|
|
int i = set_listbasepointers(bmain, lb_array);
|
|
|
|
|
|
|
|
while (i--) {
|
|
|
|
for (ID *id = lb_array[i]->first; id; id = id->next) {
|
|
|
|
if (id->lib && (id->tag & LIB_TAG_INDIRECT) != 0) {
|
|
|
|
id->tag |= LIB_TAG_DOIT;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
id->tag &= ~LIB_TAG_DOIT;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool do_loop = true;
|
|
|
|
while (do_loop) {
|
|
|
|
int i = set_listbasepointers(bmain, lb_array);
|
|
|
|
do_loop = false;
|
|
|
|
|
|
|
|
while (i--) {
|
|
|
|
for (ID *id = lb_array[i]->first; id; id = id->next) {
|
2016-11-11 19:32:59 +01:00
|
|
|
if (id->tag & LIB_TAG_DOIT) {
|
|
|
|
/* Unused ID (so far), no need to check it further. */
|
|
|
|
continue;
|
|
|
|
}
|
2017-01-30 21:41:44 +01:00
|
|
|
BKE_library_foreach_ID_link(
|
|
|
|
bmain, id, foreach_libblock_used_linked_data_tag_clear_cb, &do_loop, IDWALK_READONLY);
|
2016-11-11 22:29:54 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Untag linked data blocks used by other untagged linked datablocks.
|
|
|
|
* Used to detect datablocks that we can forcefully make local (instead of copying them to later get rid of original):
|
|
|
|
* All datablocks we want to make local are tagged by caller, after this function has ran caller knows datablocks still
|
|
|
|
* tagged can directly be made local, since they are only used by other datablocks that will also be made fully local.
|
|
|
|
*/
|
|
|
|
void BKE_library_indirectly_used_data_tag_clear(Main *bmain)
|
|
|
|
{
|
|
|
|
ListBase *lb_array[MAX_LIBARRAY];
|
|
|
|
|
|
|
|
bool do_loop = true;
|
|
|
|
while (do_loop) {
|
|
|
|
int i = set_listbasepointers(bmain, lb_array);
|
|
|
|
do_loop = false;
|
|
|
|
|
|
|
|
while (i--) {
|
|
|
|
for (ID *id = lb_array[i]->first; id; id = id->next) {
|
|
|
|
if (id->lib == NULL || id->tag & LIB_TAG_DOIT) {
|
|
|
|
/* Local or non-indirectly-used ID (so far), no need to check it further. */
|
|
|
|
continue;
|
|
|
|
}
|
2017-01-30 21:41:44 +01:00
|
|
|
BKE_library_foreach_ID_link(
|
|
|
|
bmain, id, foreach_libblock_used_linked_data_tag_clear_cb, &do_loop, IDWALK_READONLY);
|
2016-10-19 14:29:43 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|