2022-02-11 09:07:11 +11:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
|
* Copyright 2001-2002 NaN Holding BV. All rights reserved. */
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup DNA
|
|
|
|
|
* \brief ID and Library types, which are fundamental for sdna.
|
2011-02-17 20:48:12 +00:00
|
|
|
*/
|
|
|
|
|
|
2012-02-17 18:59:41 +00:00
|
|
|
#pragma once
|
2011-12-30 07:25:49 +00:00
|
|
|
|
2021-02-09 09:42:58 +11:00
|
|
|
#include "DNA_ID_enums.h"
|
2020-05-08 18:16:39 +02:00
|
|
|
#include "DNA_defs.h"
|
2006-11-17 04:46:48 +00:00
|
|
|
#include "DNA_listBase.h"
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
extern "C" {
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
struct FileData;
|
2019-11-22 12:26:36 +01:00
|
|
|
struct GHash;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct GPUTexture;
|
2006-11-17 04:46:48 +00:00
|
|
|
struct ID;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct Library;
|
2012-12-27 15:07:19 +00:00
|
|
|
struct PackedFile;
|
2014-11-19 20:48:35 +01:00
|
|
|
|
2018-07-10 14:14:55 +02:00
|
|
|
/* Runtime display data */
|
|
|
|
|
struct DrawData;
|
|
|
|
|
typedef void (*DrawDataInitCb)(struct DrawData *engine_data);
|
|
|
|
|
typedef void (*DrawDataFreeCb)(struct DrawData *engine_data);
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
#
|
|
|
|
|
typedef struct DrawData {
|
|
|
|
|
struct DrawData *next, *prev;
|
|
|
|
|
struct DrawEngineType *engine_type;
|
|
|
|
|
/* Only nested data, NOT the engine data itself. */
|
|
|
|
|
DrawDataFreeCb free;
|
|
|
|
|
/* Accumulated recalc flags, which corresponds to ID->recalc flags. */
|
|
|
|
|
int recalc;
|
|
|
|
|
} DrawData;
|
|
|
|
|
|
|
|
|
|
typedef struct DrawDataList {
|
|
|
|
|
struct DrawData *first, *last;
|
|
|
|
|
} DrawDataList;
|
|
|
|
|
|
Refactor IDProperty UI data storage
The storage of IDProperty UI data (min, max, default value, etc) is
quite complicated. For every property, retrieving a single one of these
values involves three string lookups. First for the "_RNA_UI" group
property, then another for a group with the property's name, then for
the data value name. Not only is this inefficient, it's hard to reason
about, unintuitive, and not at all self-explanatory.
This commit replaces that system with a UI data struct directly in the
IDProperty. If it's not used, the only cost is of a NULL pointer. Beyond
storing the description, name, and RNA subtype, derived structs are used
to store type specific UI data like min and max.
Note that this means that addons using (abusing) the `_RNA_UI` custom
property will have to be changed. A few places in the addons repository
will be changed after this commit with D9919.
**Before**
Before, first the _RNA_UI subgroup is retrieved the _RNA_UI group,
then the subgroup for the original property, then specific UI data
is accessed like any other IDProperty.
```
prop = rna_idprop_ui_prop_get(idproperties_owner, "prop_name", create=True)
prop["min"] = 1.0
```
**After**
After, the `id_properties_ui` function for RNA structs returns a python
object specifically for managing an IDProperty's UI data.
```
ui_data = idproperties_owner.id_properties_ui("prop_name")
ui_data.update(min=1.0)
```
In addition to `update`, there are now other functions:
- `as_dict`: Returns a dictionary of the property's UI data.
- `clear`: Removes the property's UI data.
- `update_from`: Copy UI data between properties,
even if they have different owners.
Differential Revision: https://developer.blender.org/D9697
2021-08-27 08:27:24 -05:00
|
|
|
typedef struct IDPropertyUIData {
|
|
|
|
|
/** Tooltip / property description pointer. Owned by the IDProperty. */
|
|
|
|
|
char *description;
|
|
|
|
|
/** RNA subtype, used for every type except string properties (PropertySubType). */
|
|
|
|
|
int rna_subtype;
|
|
|
|
|
|
|
|
|
|
char _pad[4];
|
|
|
|
|
} IDPropertyUIData;
|
|
|
|
|
|
|
|
|
|
/* IDP_UI_DATA_TYPE_INT */
|
|
|
|
|
typedef struct IDPropertyUIDataInt {
|
|
|
|
|
IDPropertyUIData base;
|
|
|
|
|
int *default_array; /* Only for array properties. */
|
|
|
|
|
int default_array_len;
|
|
|
|
|
char _pad[4];
|
|
|
|
|
|
|
|
|
|
int min;
|
|
|
|
|
int max;
|
|
|
|
|
int soft_min;
|
|
|
|
|
int soft_max;
|
|
|
|
|
int step;
|
|
|
|
|
int default_value;
|
|
|
|
|
} IDPropertyUIDataInt;
|
|
|
|
|
|
|
|
|
|
/* IDP_UI_DATA_TYPE_FLOAT */
|
|
|
|
|
typedef struct IDPropertyUIDataFloat {
|
|
|
|
|
IDPropertyUIData base;
|
|
|
|
|
double *default_array; /* Only for array properties. */
|
|
|
|
|
int default_array_len;
|
|
|
|
|
char _pad[4];
|
|
|
|
|
|
|
|
|
|
float step;
|
|
|
|
|
int precision;
|
|
|
|
|
|
|
|
|
|
double min;
|
|
|
|
|
double max;
|
|
|
|
|
double soft_min;
|
|
|
|
|
double soft_max;
|
|
|
|
|
double default_value;
|
|
|
|
|
} IDPropertyUIDataFloat;
|
|
|
|
|
|
|
|
|
|
/* IDP_UI_DATA_TYPE_STRING */
|
|
|
|
|
typedef struct IDPropertyUIDataString {
|
|
|
|
|
IDPropertyUIData base;
|
|
|
|
|
char *default_value;
|
|
|
|
|
} IDPropertyUIDataString;
|
|
|
|
|
|
|
|
|
|
/* IDP_UI_DATA_TYPE_ID */
|
|
|
|
|
typedef struct IDPropertyUIDataID {
|
|
|
|
|
IDPropertyUIData base;
|
|
|
|
|
} IDPropertyUIDataID;
|
|
|
|
|
|
2006-11-17 04:46:48 +00:00
|
|
|
typedef struct IDPropertyData {
|
|
|
|
|
void *pointer;
|
|
|
|
|
ListBase group;
|
2021-07-03 23:08:40 +10:00
|
|
|
/** NOTE: we actually fit a double into these two 32bit integers. */
|
2019-01-07 22:19:13 +11:00
|
|
|
int val, val2;
|
2006-11-17 04:46:48 +00:00
|
|
|
} IDPropertyData;
|
|
|
|
|
|
|
|
|
|
typedef struct IDProperty {
|
|
|
|
|
struct IDProperty *next, *prev;
|
|
|
|
|
char type, subtype;
|
|
|
|
|
short flag;
|
2019-01-07 22:19:13 +11:00
|
|
|
/** MAX_IDPROP_NAME. */
|
|
|
|
|
char name[64];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-11-19 20:48:35 +01:00
|
|
|
/* saved is used to indicate if this struct has been saved yet.
|
2019-02-27 15:07:50 +11:00
|
|
|
* seemed like a good idea as a '_pad' var was needed anyway :) */
|
2014-11-19 20:48:35 +01:00
|
|
|
int saved;
|
2021-07-03 23:08:40 +10:00
|
|
|
/** NOTE: alignment for 64 bits. */
|
2019-01-07 22:19:13 +11:00
|
|
|
IDPropertyData data;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-06-24 15:56:58 +10:00
|
|
|
/* Array length, also (this is important!) string length + 1.
|
|
|
|
|
* the idea is to be able to reuse array realloc functions on strings. */
|
2014-11-19 20:48:35 +01:00
|
|
|
int len;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-11-19 20:48:35 +01:00
|
|
|
/* Strings and arrays are both buffered, though the buffer isn't saved. */
|
2011-11-11 13:09:14 +00:00
|
|
|
/* totallen is total length of allocated array/string, including a buffer.
|
2014-11-19 20:48:35 +01:00
|
|
|
* Note that the buffering is mild; the code comes from python's list implementation. */
|
|
|
|
|
int totallen;
|
Refactor IDProperty UI data storage
The storage of IDProperty UI data (min, max, default value, etc) is
quite complicated. For every property, retrieving a single one of these
values involves three string lookups. First for the "_RNA_UI" group
property, then another for a group with the property's name, then for
the data value name. Not only is this inefficient, it's hard to reason
about, unintuitive, and not at all self-explanatory.
This commit replaces that system with a UI data struct directly in the
IDProperty. If it's not used, the only cost is of a NULL pointer. Beyond
storing the description, name, and RNA subtype, derived structs are used
to store type specific UI data like min and max.
Note that this means that addons using (abusing) the `_RNA_UI` custom
property will have to be changed. A few places in the addons repository
will be changed after this commit with D9919.
**Before**
Before, first the _RNA_UI subgroup is retrieved the _RNA_UI group,
then the subgroup for the original property, then specific UI data
is accessed like any other IDProperty.
```
prop = rna_idprop_ui_prop_get(idproperties_owner, "prop_name", create=True)
prop["min"] = 1.0
```
**After**
After, the `id_properties_ui` function for RNA structs returns a python
object specifically for managing an IDProperty's UI data.
```
ui_data = idproperties_owner.id_properties_ui("prop_name")
ui_data.update(min=1.0)
```
In addition to `update`, there are now other functions:
- `as_dict`: Returns a dictionary of the property's UI data.
- `clear`: Removes the property's UI data.
- `update_from`: Copy UI data between properties,
even if they have different owners.
Differential Revision: https://developer.blender.org/D9697
2021-08-27 08:27:24 -05:00
|
|
|
|
|
|
|
|
IDPropertyUIData *ui_data;
|
2006-11-17 04:46:48 +00:00
|
|
|
} IDProperty;
|
|
|
|
|
|
2014-11-19 20:48:35 +01:00
|
|
|
#define MAX_IDPROP_NAME 64
|
|
|
|
|
#define DEFAULT_ALLOC_FOR_NULL_STRINGS 64
|
2006-11-17 04:46:48 +00:00
|
|
|
|
|
|
|
|
/*->type*/
|
AssetsBrowser: Add ID Properties to Asset Indexer
Object/collection asset workflow would need the bounding box for snapping.
The bounding box is stored using ID properties in the scene. Currently ID properties
aren't stored in the asset index, what would break object snapping. For this reason
Asset Indexing is turned off in mater. This patch will introduce the indexing of ID
properties what will allow the indexing to be turned on again.
## Data Mapping ##
For data mapping we store the internal structure of IDProperty to the indexer (including meta-data) to be able to deserialize it back.
```
[
{
"name": ..,
"value": ..,
"type": ..,
/* `subtype` and `length` are only available for IDP_ARRAYs. */
"subtype": ..,
},
]
```
| **DNA** | **Serialize type** | **Note** |
| IDProperty.name | StringValue| |
| IDProperty.type | StringValue| "IDP_STRING", "IDP_INT", "IDP_FLOAT", "IDP_ARRAY", "IDP_GROUP", "IDP_DOUBLE"|
| IDProperty.subtype | StringValue| "IDP_INT", "IDP_FLOAT", "IDP_GROUP", "IDP_DOUBLE" |
| IDProperty.value | StringValue | When type is IDP_STRING |
| IDProperty.value | IntValue | When type is IDP_INT |
| IDProperty.value | DoubleValue | When type is IDP_FLOAT/IDP_DOUBLE |
| IDProperty.value | ArrayValue | When type is IDP_GROUP. Recursively uses the same structure as described in this section. |
| IDProperty.value | ArrayValue | When type is IDP_ARRAY. Each element holds a single element as described in this section. |
NOTE: IDP_ID and IDP_IDARRAY aren't supported. The entry will not be added.
Example
```
[
{
"name": "MyIntValue,
"type": "IDP_INT",
"value": 6,
},
{
"name": "myComplexArray",
"type": "IDP_ARRAY",
"subtype": "IDP_GROUP",
"value": [
[
{
"name": ..
....
}
]
]
}
]
```
## Considered alternatives ##
- Add conversion functions inside `asset_indexer`; makes generic code part of a specific solution.
- Add conversion functions inside `BLI_serialize`; would add data transformation responsibilities inside a unit that is currently only responsible for formatting.
- Use direct mapping between IDP properties and Values; leads to missing information and edge cases (empty primitive arrays) that could not be de-serialized.
Reviewed By: Severin, mont29, HooglyBoogly
Maniphest Tasks: T92306
Differential Revision: https://developer.blender.org/D12990
2022-01-18 11:12:02 +01:00
|
|
|
typedef enum eIDPropertyType {
|
2014-11-19 20:48:35 +01:00
|
|
|
IDP_STRING = 0,
|
|
|
|
|
IDP_INT = 1,
|
|
|
|
|
IDP_FLOAT = 2,
|
AssetsBrowser: Add ID Properties to Asset Indexer
Object/collection asset workflow would need the bounding box for snapping.
The bounding box is stored using ID properties in the scene. Currently ID properties
aren't stored in the asset index, what would break object snapping. For this reason
Asset Indexing is turned off in mater. This patch will introduce the indexing of ID
properties what will allow the indexing to be turned on again.
## Data Mapping ##
For data mapping we store the internal structure of IDProperty to the indexer (including meta-data) to be able to deserialize it back.
```
[
{
"name": ..,
"value": ..,
"type": ..,
/* `subtype` and `length` are only available for IDP_ARRAYs. */
"subtype": ..,
},
]
```
| **DNA** | **Serialize type** | **Note** |
| IDProperty.name | StringValue| |
| IDProperty.type | StringValue| "IDP_STRING", "IDP_INT", "IDP_FLOAT", "IDP_ARRAY", "IDP_GROUP", "IDP_DOUBLE"|
| IDProperty.subtype | StringValue| "IDP_INT", "IDP_FLOAT", "IDP_GROUP", "IDP_DOUBLE" |
| IDProperty.value | StringValue | When type is IDP_STRING |
| IDProperty.value | IntValue | When type is IDP_INT |
| IDProperty.value | DoubleValue | When type is IDP_FLOAT/IDP_DOUBLE |
| IDProperty.value | ArrayValue | When type is IDP_GROUP. Recursively uses the same structure as described in this section. |
| IDProperty.value | ArrayValue | When type is IDP_ARRAY. Each element holds a single element as described in this section. |
NOTE: IDP_ID and IDP_IDARRAY aren't supported. The entry will not be added.
Example
```
[
{
"name": "MyIntValue,
"type": "IDP_INT",
"value": 6,
},
{
"name": "myComplexArray",
"type": "IDP_ARRAY",
"subtype": "IDP_GROUP",
"value": [
[
{
"name": ..
....
}
]
]
}
]
```
## Considered alternatives ##
- Add conversion functions inside `asset_indexer`; makes generic code part of a specific solution.
- Add conversion functions inside `BLI_serialize`; would add data transformation responsibilities inside a unit that is currently only responsible for formatting.
- Use direct mapping between IDP properties and Values; leads to missing information and edge cases (empty primitive arrays) that could not be de-serialized.
Reviewed By: Severin, mont29, HooglyBoogly
Maniphest Tasks: T92306
Differential Revision: https://developer.blender.org/D12990
2022-01-18 11:12:02 +01:00
|
|
|
/** Array containing int, floats, doubles or groups. */
|
2014-11-19 20:48:35 +01:00
|
|
|
IDP_ARRAY = 5,
|
|
|
|
|
IDP_GROUP = 6,
|
|
|
|
|
IDP_ID = 7,
|
|
|
|
|
IDP_DOUBLE = 8,
|
|
|
|
|
IDP_IDPARRAY = 9,
|
AssetsBrowser: Add ID Properties to Asset Indexer
Object/collection asset workflow would need the bounding box for snapping.
The bounding box is stored using ID properties in the scene. Currently ID properties
aren't stored in the asset index, what would break object snapping. For this reason
Asset Indexing is turned off in mater. This patch will introduce the indexing of ID
properties what will allow the indexing to be turned on again.
## Data Mapping ##
For data mapping we store the internal structure of IDProperty to the indexer (including meta-data) to be able to deserialize it back.
```
[
{
"name": ..,
"value": ..,
"type": ..,
/* `subtype` and `length` are only available for IDP_ARRAYs. */
"subtype": ..,
},
]
```
| **DNA** | **Serialize type** | **Note** |
| IDProperty.name | StringValue| |
| IDProperty.type | StringValue| "IDP_STRING", "IDP_INT", "IDP_FLOAT", "IDP_ARRAY", "IDP_GROUP", "IDP_DOUBLE"|
| IDProperty.subtype | StringValue| "IDP_INT", "IDP_FLOAT", "IDP_GROUP", "IDP_DOUBLE" |
| IDProperty.value | StringValue | When type is IDP_STRING |
| IDProperty.value | IntValue | When type is IDP_INT |
| IDProperty.value | DoubleValue | When type is IDP_FLOAT/IDP_DOUBLE |
| IDProperty.value | ArrayValue | When type is IDP_GROUP. Recursively uses the same structure as described in this section. |
| IDProperty.value | ArrayValue | When type is IDP_ARRAY. Each element holds a single element as described in this section. |
NOTE: IDP_ID and IDP_IDARRAY aren't supported. The entry will not be added.
Example
```
[
{
"name": "MyIntValue,
"type": "IDP_INT",
"value": 6,
},
{
"name": "myComplexArray",
"type": "IDP_ARRAY",
"subtype": "IDP_GROUP",
"value": [
[
{
"name": ..
....
}
]
]
}
]
```
## Considered alternatives ##
- Add conversion functions inside `asset_indexer`; makes generic code part of a specific solution.
- Add conversion functions inside `BLI_serialize`; would add data transformation responsibilities inside a unit that is currently only responsible for formatting.
- Use direct mapping between IDP properties and Values; leads to missing information and edge cases (empty primitive arrays) that could not be de-serialized.
Reviewed By: Severin, mont29, HooglyBoogly
Maniphest Tasks: T92306
Differential Revision: https://developer.blender.org/D12990
2022-01-18 11:12:02 +01:00
|
|
|
} eIDPropertyType;
|
|
|
|
|
#define IDP_NUMTYPES 10
|
2006-11-17 04:46:48 +00:00
|
|
|
|
2020-04-25 20:58:55 +02:00
|
|
|
/** Used by some IDP utils, keep values in sync with type enum above. */
|
|
|
|
|
enum {
|
|
|
|
|
IDP_TYPE_FILTER_STRING = 1 << 0,
|
|
|
|
|
IDP_TYPE_FILTER_INT = 1 << 1,
|
|
|
|
|
IDP_TYPE_FILTER_FLOAT = 1 << 2,
|
|
|
|
|
IDP_TYPE_FILTER_ARRAY = 1 << 5,
|
|
|
|
|
IDP_TYPE_FILTER_GROUP = 1 << 6,
|
|
|
|
|
IDP_TYPE_FILTER_ID = 1 << 7,
|
|
|
|
|
IDP_TYPE_FILTER_DOUBLE = 1 << 8,
|
|
|
|
|
IDP_TYPE_FILTER_IDPARRAY = 1 << 9,
|
|
|
|
|
};
|
|
|
|
|
|
2011-11-15 09:12:10 +00:00
|
|
|
/*->subtype */
|
|
|
|
|
|
|
|
|
|
/* IDP_STRING */
|
2014-11-19 20:48:35 +01:00
|
|
|
enum {
|
|
|
|
|
IDP_STRING_SUB_UTF8 = 0, /* default */
|
|
|
|
|
IDP_STRING_SUB_BYTE = 1, /* arbitrary byte array, _not_ null terminated */
|
|
|
|
|
};
|
2011-11-15 09:12:10 +00:00
|
|
|
|
2014-11-19 20:48:35 +01:00
|
|
|
/*->flag*/
|
|
|
|
|
enum {
|
2019-01-15 23:14:35 +11:00
|
|
|
/** This IDProp may be statically overridden.
|
|
|
|
|
* Should only be used/be relevant for custom properties. */
|
2019-06-14 23:16:04 +02:00
|
|
|
IDP_FLAG_OVERRIDABLE_LIBRARY = 1 << 0,
|
2018-04-17 18:03:41 +02:00
|
|
|
|
2020-09-19 12:13:04 +02:00
|
|
|
/** This collection item IDProp has been inserted in a local override.
|
|
|
|
|
* This is used by internal code to distinguish between library-originated items and
|
2020-09-21 14:59:31 +10:00
|
|
|
* local-inserted ones, as many operations are not allowed on the former. */
|
2020-09-19 12:13:04 +02:00
|
|
|
IDP_FLAG_OVERRIDELIBRARY_LOCAL = 1 << 1,
|
|
|
|
|
|
2019-01-15 23:14:35 +11:00
|
|
|
/** This means the property is set but RNA will return false when checking
|
|
|
|
|
* 'RNA_property_is_set', currently this is a runtime flag */
|
|
|
|
|
IDP_FLAG_GHOST = 1 << 7,
|
2014-11-19 20:48:35 +01:00
|
|
|
};
|
2011-11-15 09:12:10 +00:00
|
|
|
|
2021-06-24 15:56:58 +10:00
|
|
|
/* add any future new id property types here. */
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2017-11-29 15:05:03 +01:00
|
|
|
/* Static ID override structs. */
|
|
|
|
|
|
2019-06-14 23:16:04 +02:00
|
|
|
typedef struct IDOverrideLibraryPropertyOperation {
|
|
|
|
|
struct IDOverrideLibraryPropertyOperation *next, *prev;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-11-29 15:05:03 +01:00
|
|
|
/* Type of override. */
|
|
|
|
|
short operation;
|
|
|
|
|
short flag;
|
2020-04-16 16:19:44 +02:00
|
|
|
|
|
|
|
|
/** Runtime, tags are common to both IDOverrideProperty and IDOverridePropertyOperation. */
|
|
|
|
|
short tag;
|
|
|
|
|
char _pad0[2];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-11-29 15:05:03 +01:00
|
|
|
/* Sub-item references, if needed (for arrays or collections only).
|
2021-11-19 09:33:52 +01:00
|
|
|
* We need both reference and local values to allow e.g. insertion into RNA collections
|
2019-04-22 01:42:45 +10:00
|
|
|
* (constraints, modifiers...).
|
2021-11-19 09:33:52 +01:00
|
|
|
* In RNA collection case, if names are defined, they are used in priority.
|
|
|
|
|
* Names are pointers (instead of char[64]) to save some space, NULL or empty string when unset.
|
|
|
|
|
* Indices are -1 when unset.
|
|
|
|
|
*
|
|
|
|
|
* NOTE: For insertion operations in RNA collections, reference may not actually exist in the
|
|
|
|
|
* linked reference data. It is used to identify the anchor of the insertion operation (i.e. the
|
|
|
|
|
* item after or before which the new local item should be inserted), in the local override. */
|
2017-11-29 15:05:03 +01:00
|
|
|
char *subitem_reference_name;
|
|
|
|
|
char *subitem_local_name;
|
|
|
|
|
int subitem_reference_index;
|
|
|
|
|
int subitem_local_index;
|
2019-06-14 23:16:04 +02:00
|
|
|
} IDOverrideLibraryPropertyOperation;
|
2017-11-29 15:05:03 +01:00
|
|
|
|
2021-03-01 12:34:25 +01:00
|
|
|
/* IDOverrideLibraryPropertyOperation->operation. */
|
2017-11-29 15:05:03 +01:00
|
|
|
enum {
|
|
|
|
|
/* Basic operations. */
|
2019-06-14 23:16:04 +02:00
|
|
|
IDOVERRIDE_LIBRARY_OP_NOOP = 0, /* Special value, forbids any overriding. */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-06-14 23:16:04 +02:00
|
|
|
IDOVERRIDE_LIBRARY_OP_REPLACE = 1, /* Fully replace local value by reference one. */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-11-29 15:05:03 +01:00
|
|
|
/* Numeric-only operations. */
|
2019-06-14 23:16:04 +02:00
|
|
|
IDOVERRIDE_LIBRARY_OP_ADD = 101, /* Add local value to reference one. */
|
2017-11-29 15:05:03 +01:00
|
|
|
/* Subtract local value from reference one (needed due to unsigned values etc.). */
|
2019-06-14 23:16:04 +02:00
|
|
|
IDOVERRIDE_LIBRARY_OP_SUBTRACT = 102,
|
2017-11-29 15:05:03 +01:00
|
|
|
/* Multiply reference value by local one (more useful than diff for scales and the like). */
|
2019-06-14 23:16:04 +02:00
|
|
|
IDOVERRIDE_LIBRARY_OP_MULTIPLY = 103,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-11-29 15:05:03 +01:00
|
|
|
/* Collection-only operations. */
|
2019-06-14 23:16:04 +02:00
|
|
|
IDOVERRIDE_LIBRARY_OP_INSERT_AFTER = 201, /* Insert after given reference's subitem. */
|
|
|
|
|
IDOVERRIDE_LIBRARY_OP_INSERT_BEFORE = 202, /* Insert before given reference's subitem. */
|
2017-11-29 15:05:03 +01:00
|
|
|
/* We can add more if needed (move, delete, ...). */
|
|
|
|
|
};
|
|
|
|
|
|
2021-03-01 12:34:25 +01:00
|
|
|
/* IDOverrideLibraryPropertyOperation->flag. */
|
2017-11-29 15:05:03 +01:00
|
|
|
enum {
|
2019-01-15 23:14:35 +11:00
|
|
|
/** User cannot remove that override operation. */
|
2019-06-14 23:16:04 +02:00
|
|
|
IDOVERRIDE_LIBRARY_FLAG_MANDATORY = 1 << 0,
|
2019-01-15 23:14:35 +11:00
|
|
|
/** User cannot change that override operation. */
|
2019-06-14 23:16:04 +02:00
|
|
|
IDOVERRIDE_LIBRARY_FLAG_LOCKED = 1 << 1,
|
2020-12-24 18:11:46 +01:00
|
|
|
|
|
|
|
|
/** For overrides of ID pointers: this override still matches (follows) the hierarchy of the
|
|
|
|
|
* reference linked data. */
|
|
|
|
|
IDOVERRIDE_LIBRARY_FLAG_IDPOINTER_MATCH_REFERENCE = 1 << 8,
|
2017-11-29 15:05:03 +01:00
|
|
|
};
|
|
|
|
|
|
2019-01-07 22:19:13 +11:00
|
|
|
/** A single overridden property, contain all operations on this one. */
|
2019-06-14 23:16:04 +02:00
|
|
|
typedef struct IDOverrideLibraryProperty {
|
|
|
|
|
struct IDOverrideLibraryProperty *next, *prev;
|
2017-11-29 15:05:03 +01:00
|
|
|
|
2019-01-07 22:19:13 +11:00
|
|
|
/**
|
|
|
|
|
* Path from ID to overridden property.
|
|
|
|
|
* *Does not* include indices/names for final arrays/collections items.
|
|
|
|
|
*/
|
2017-11-29 15:05:03 +01:00
|
|
|
char *rna_path;
|
|
|
|
|
|
2021-03-01 12:34:25 +01:00
|
|
|
/**
|
|
|
|
|
* List of overriding operations (IDOverrideLibraryPropertyOperation) applied to this property.
|
|
|
|
|
*/
|
2019-01-07 22:19:13 +11:00
|
|
|
ListBase operations;
|
2020-04-16 16:19:44 +02:00
|
|
|
|
2021-03-01 12:34:25 +01:00
|
|
|
/**
|
|
|
|
|
* Runtime, tags are common to both IDOverrideLibraryProperty and
|
|
|
|
|
* IDOverrideLibraryPropertyOperation. */
|
2020-04-16 16:19:44 +02:00
|
|
|
short tag;
|
2020-07-23 11:28:29 +02:00
|
|
|
char _pad[2];
|
|
|
|
|
|
|
|
|
|
/** The property type matching the rna_path. */
|
|
|
|
|
unsigned int rna_prop_type;
|
2019-06-14 23:16:04 +02:00
|
|
|
} IDOverrideLibraryProperty;
|
2017-11-29 15:05:03 +01:00
|
|
|
|
2021-03-01 12:34:25 +01:00
|
|
|
/* IDOverrideLibraryProperty->tag and IDOverrideLibraryPropertyOperation->tag. */
|
2020-04-16 16:19:44 +02:00
|
|
|
enum {
|
|
|
|
|
/** This override property (operation) is unused and should be removed by cleanup process. */
|
|
|
|
|
IDOVERRIDE_LIBRARY_TAG_UNUSED = 1 << 0,
|
|
|
|
|
};
|
|
|
|
|
|
2020-07-22 17:36:36 +02:00
|
|
|
#
|
|
|
|
|
#
|
|
|
|
|
typedef struct IDOverrideLibraryRuntime {
|
|
|
|
|
struct GHash *rna_path_to_override_properties;
|
|
|
|
|
uint tag;
|
|
|
|
|
} IDOverrideLibraryRuntime;
|
|
|
|
|
|
|
|
|
|
/* IDOverrideLibraryRuntime->tag. */
|
|
|
|
|
enum {
|
|
|
|
|
/** This override needs to be reloaded. */
|
|
|
|
|
IDOVERRIDE_LIBRARY_RUNTIME_TAG_NEEDS_RELOAD = 1 << 0,
|
|
|
|
|
};
|
2019-11-22 12:26:36 +01:00
|
|
|
|
2017-11-29 15:05:03 +01:00
|
|
|
/* Main container for all overriding data info of a data-block. */
|
2019-06-14 23:16:04 +02:00
|
|
|
typedef struct IDOverrideLibrary {
|
2019-01-07 22:19:13 +11:00
|
|
|
/** Reference linked ID which this one overrides. */
|
|
|
|
|
struct ID *reference;
|
2021-03-01 12:34:25 +01:00
|
|
|
/** List of IDOverrideLibraryProperty structs. */
|
2019-01-07 22:19:13 +11:00
|
|
|
ListBase properties;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-01-12 10:43:42 +01:00
|
|
|
/** Override hierarchy root ID. Usually the actual root of the hierarchy, but not always
|
|
|
|
|
* in degenerated cases.
|
|
|
|
|
*
|
|
|
|
|
* All liboverrides of a same hierarchy (e.g. a character collection) share the same root.
|
|
|
|
|
*/
|
|
|
|
|
struct ID *hierarchy_root;
|
|
|
|
|
|
2017-11-29 15:05:03 +01:00
|
|
|
/* Read/write data. */
|
|
|
|
|
/* Temp ID storing extra override data (used for differential operations only currently).
|
|
|
|
|
* Always NULL outside of read/write context. */
|
|
|
|
|
struct ID *storage;
|
2019-11-22 12:26:36 +01:00
|
|
|
|
|
|
|
|
IDOverrideLibraryRuntime *runtime;
|
2022-01-05 16:30:15 +01:00
|
|
|
|
|
|
|
|
unsigned int flag;
|
|
|
|
|
char _pad_1[4];
|
2019-06-14 23:16:04 +02:00
|
|
|
} IDOverrideLibrary;
|
2017-11-29 15:05:03 +01:00
|
|
|
|
2022-01-05 16:30:15 +01:00
|
|
|
/* IDOverrideLibrary->flag */
|
|
|
|
|
enum {
|
|
|
|
|
/**
|
|
|
|
|
* The override data-block should not be considered as part of an override hierarchy (generally
|
|
|
|
|
* because it was created as an single override, outside of any hierarchy consideration).
|
|
|
|
|
*/
|
|
|
|
|
IDOVERRIDE_LIBRARY_FLAG_NO_HIERARCHY = 1 << 0,
|
2022-02-22 17:20:18 +01:00
|
|
|
/**
|
|
|
|
|
* The override ID is required for the system to work (because of ID dependencies), but is not
|
|
|
|
|
* seen as editable by the user.
|
|
|
|
|
*/
|
|
|
|
|
IDOVERRIDE_LIBRARY_FLAG_SYSTEM_DEFINED = 1 << 1,
|
2022-01-05 16:30:15 +01:00
|
|
|
};
|
|
|
|
|
|
2003-04-27 11:55:33 +00:00
|
|
|
/* watch it: Sequence has identical beginning. */
|
2002-10-12 11:37:38 +00:00
|
|
|
/**
|
|
|
|
|
* ID is the first thing included in all serializable types. It
|
|
|
|
|
* provides a common handle to place all data in double-linked lists.
|
2021-01-20 15:15:38 +11:00
|
|
|
*/
|
2006-11-17 04:46:48 +00:00
|
|
|
|
2012-01-11 08:51:06 +00:00
|
|
|
/* 2 characters for ID code and 64 for actual name */
|
2014-11-19 20:48:35 +01:00
|
|
|
#define MAX_ID_NAME 66
|
2007-12-24 18:53:37 +00:00
|
|
|
|
2022-04-05 08:00:20 +10:00
|
|
|
/** #ID_Runtime_Remap.status */
|
2022-02-11 14:53:08 +01:00
|
|
|
enum {
|
|
|
|
|
/** new_id is directly linked in current .blend. */
|
|
|
|
|
ID_REMAP_IS_LINKED_DIRECT = 1 << 0,
|
|
|
|
|
/** There was some skipped 'user_one' usages of old_id. */
|
|
|
|
|
ID_REMAP_IS_USER_ONE_SKIPPED = 1 << 1,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/** Status used and counters created during id-remapping. */
|
|
|
|
|
typedef struct ID_Runtime_Remap {
|
|
|
|
|
/** Status during ID remapping. */
|
|
|
|
|
int status;
|
|
|
|
|
/** During ID remapping the number of skipped use cases that refcount the data-block. */
|
|
|
|
|
int skipped_refcounted;
|
2022-04-11 11:41:00 +10:00
|
|
|
/**
|
|
|
|
|
* During ID remapping the number of direct use cases that could be remapped
|
|
|
|
|
* (e.g. obdata when in edit mode).
|
|
|
|
|
*/
|
2022-02-11 14:53:08 +01:00
|
|
|
int skipped_direct;
|
|
|
|
|
/** During ID remapping, the number of indirect use cases that could not be remapped. */
|
|
|
|
|
int skipped_indirect;
|
|
|
|
|
} ID_Runtime_Remap;
|
|
|
|
|
|
|
|
|
|
typedef struct ID_Runtime {
|
|
|
|
|
ID_Runtime_Remap remap;
|
|
|
|
|
} ID_Runtime;
|
|
|
|
|
|
2013-03-18 11:44:56 +00:00
|
|
|
/* There's a nasty circular dependency here.... 'void *' to the rescue! I
|
2006-11-17 04:46:48 +00:00
|
|
|
* really wonder why this is needed. */
|
2002-10-12 11:37:38 +00:00
|
|
|
typedef struct ID {
|
|
|
|
|
void *next, *prev;
|
|
|
|
|
struct ID *newid;
|
2020-12-11 18:15:25 +01:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
struct Library *lib;
|
2020-12-11 18:15:25 +01:00
|
|
|
|
|
|
|
|
/** If the ID is an asset, this pointer is set. Owning pointer. */
|
|
|
|
|
struct AssetMetaData *asset_data;
|
|
|
|
|
|
2019-01-07 22:19:13 +11:00
|
|
|
/** MAX_ID_NAME. */
|
|
|
|
|
char name[66];
|
2002-10-12 11:37:38 +00:00
|
|
|
/**
|
2019-06-12 09:04:10 +10:00
|
|
|
* LIB_... flags report on status of the data-block this ID belongs to
|
2019-01-07 22:19:13 +11:00
|
|
|
* (persistent, saved to and read from .blend).
|
2002-10-12 11:37:38 +00:00
|
|
|
*/
|
|
|
|
|
short flag;
|
Split id->flag in two, persistent flags and runtime tags.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
2015-12-27 11:53:50 +01:00
|
|
|
/**
|
|
|
|
|
* LIB_TAG_... tags (runtime only, cleared at read time).
|
|
|
|
|
*/
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
int tag;
|
2013-12-08 13:34:37 +06:00
|
|
|
int us;
|
Split id->flag in two, persistent flags and runtime tags.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
2015-12-27 11:53:50 +01:00
|
|
|
int icon_id;
|
2017-12-14 15:12:05 +01:00
|
|
|
int recalc;
|
2020-03-17 12:09:06 +01:00
|
|
|
/**
|
2020-04-13 17:38:34 +02:00
|
|
|
* Used by undo code. recalc_after_undo_push contains the changes between the
|
|
|
|
|
* last undo push and the current state. This is accumulated as IDs are tagged
|
|
|
|
|
* for update in the depsgraph, and only cleared on undo push.
|
|
|
|
|
*
|
|
|
|
|
* recalc_up_to_undo_push is saved to undo memory, and is the value of
|
|
|
|
|
* recalc_after_undo_push at the time of the undo push. This means it can be
|
|
|
|
|
* used to find the changes between undo states.
|
2020-03-17 12:09:06 +01:00
|
|
|
*/
|
2020-04-13 17:38:34 +02:00
|
|
|
int recalc_up_to_undo_push;
|
|
|
|
|
int recalc_after_undo_push;
|
2020-03-05 16:17:14 +01:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* A session-wide unique identifier for a given ID, that remain the same across potential
|
|
|
|
|
* re-allocations (e.g. due to undo/redo steps).
|
|
|
|
|
*/
|
|
|
|
|
unsigned int session_uuid;
|
|
|
|
|
|
2006-11-17 04:46:48 +00:00
|
|
|
IDProperty *properties;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-07 22:19:13 +11:00
|
|
|
/** Reference linked ID which this one overrides. */
|
2019-06-14 23:16:04 +02:00
|
|
|
IDOverrideLibrary *override_library;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-07 22:19:13 +11:00
|
|
|
/**
|
2019-06-12 09:04:10 +10:00
|
|
|
* Only set for data-blocks which are coming from copy-on-write, points to
|
2018-01-16 14:57:02 +01:00
|
|
|
* the original version of it.
|
2020-11-03 11:39:36 +01:00
|
|
|
* Also used temporarily during memfile undo to keep a reference to old ID when found.
|
2018-01-16 14:57:02 +01:00
|
|
|
*/
|
2018-06-04 14:11:38 +02:00
|
|
|
struct ID *orig_id;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-07 21:32:43 +11:00
|
|
|
/**
|
|
|
|
|
* Holds the #PyObject reference to the ID (initialized on demand).
|
|
|
|
|
*
|
|
|
|
|
* This isn't essential, it could be removed however it gives some advantages:
|
|
|
|
|
*
|
|
|
|
|
* - Every time the #ID is accessed a #BPy_StructRNA doesn't have to be created & destroyed
|
|
|
|
|
* (consider all the polling and drawing functions that access ID's).
|
|
|
|
|
*
|
|
|
|
|
* - When this #ID is deleted, the #BPy_StructRNA can be invalidated
|
|
|
|
|
* so accessing it from Python raises an exception instead of crashing.
|
|
|
|
|
*
|
|
|
|
|
* This is of limited benefit though, as it doesn't apply to non #ID data
|
|
|
|
|
* that references this ID (the bones of an armature or the modifiers of an object for e.g.).
|
|
|
|
|
*/
|
2017-07-26 23:49:20 +10:00
|
|
|
void *py_instance;
|
2021-09-17 16:22:29 +02:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Weak reference to an ID in a given library file, used to allow re-using already appended data
|
|
|
|
|
* in some cases, instead of appending it again.
|
|
|
|
|
*
|
|
|
|
|
* May be NULL.
|
|
|
|
|
*/
|
|
|
|
|
struct LibraryWeakReference *library_weak_reference;
|
2022-02-11 14:53:08 +01:00
|
|
|
|
|
|
|
|
struct ID_Runtime runtime;
|
2002-10-12 11:37:38 +00:00
|
|
|
} ID;
|
|
|
|
|
|
|
|
|
|
/**
|
2003-04-27 11:55:33 +00:00
|
|
|
* For each library file used, a Library struct is added to Main
|
2006-12-01 10:12:41 +00:00
|
|
|
* WARNING: readfile.c, expand_doit() reads this struct without DNA check!
|
2002-10-12 11:37:38 +00:00
|
|
|
*/
|
|
|
|
|
typedef struct Library {
|
|
|
|
|
ID id;
|
|
|
|
|
struct FileData *filedata;
|
2019-01-07 22:19:13 +11:00
|
|
|
/** Path name used for reading, can be relative and edited in the outliner. */
|
2020-06-23 09:54:14 +10:00
|
|
|
char filepath[1024];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-07 22:19:13 +11:00
|
|
|
/**
|
2020-06-23 09:54:14 +10:00
|
|
|
* Run-time only, absolute file-path (set on read).
|
|
|
|
|
* This is only for convenience, `filepath` is the real path
|
|
|
|
|
* used on file read but in some cases its useful to access the absolute one.
|
|
|
|
|
*
|
|
|
|
|
* Use #BKE_library_filepath_set() rather than setting `filepath`
|
|
|
|
|
* directly and it will be kept in sync - campbell
|
|
|
|
|
*/
|
2020-06-23 09:54:07 +10:00
|
|
|
char filepath_abs[1024];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-07 22:19:13 +11:00
|
|
|
/** Set for indirectly linked libs, used in the outliner and while reading. */
|
|
|
|
|
struct Library *parent;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-12-27 15:07:19 +00:00
|
|
|
struct PackedFile *packedfile;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-01-07 12:07:37 +01:00
|
|
|
ushort tag;
|
|
|
|
|
char _pad_0[6];
|
|
|
|
|
|
LibOverride: add recursive resync.
Recursive resync means also resyncing overrides that are linked from
other library files into current working file.
Note that this allows to get 'working' files even when their
dependencies are out of sync. However, since linked data is never
written/saved, this has to be re-done every time the working file is
loaded, until said dependencies are updated properly.
NOTE: This is still missing the 'report' side of things, which is part
of a larger task to enhance reports regarding both linking, and
liboverrides (see T88393).
----------
Technical notes:
Implementing this proved to be slightly more challenging than expected,
mainly because one of the key aspects of the feature was never done in
Blender before: manipulating, re-creating linked data.
This ended up moving the whole resync code to use temp IDs out of bmain,
which is better in the long run anyway (and more aligned with what we
generally want to do when manipulating temp ID data). It should also
give a marginal improvement in performances for regular resync.
This commit also had to carefully 'sort' libraries by level of indirect
usage, as we want to resync first the libraries that are the least directly
used, i.e. libraries that are most used by other libraries.
2021-05-26 16:53:59 +02:00
|
|
|
/* Temp data needed by read/write code, and liboverride recursive resync. */
|
2016-06-07 01:54:59 +10:00
|
|
|
int temp_index;
|
Blender: change bugfix release versioning from a/b/c to .1/.2/.3
The file subversion is no longer used in the Python API or user interface,
and is now internal to Blender.
User interface, Python API and file I/O metadata now use more consistent
formatting for version numbers. Official releases use "2.83.0", "2.83.1",
and releases under development use "2.90.0 Alpha", "2.90.0 Beta".
Some Python add-ons may need to lower the Blender version in bl_info to
(2, 83, 0) or (2, 90, 0) if they used a subversion number higher than 0.
https://wiki.blender.org/wiki/Reference/Release_Notes/2.83/Python_API#Compatibility
This change is in preparation of LTS releases, and also brings us more
in line with semantic versioning.
Fixes T76058.
Differential Revision: https://developer.blender.org/D7748
2020-05-25 10:49:04 +02:00
|
|
|
/** See BLENDER_FILE_VERSION, BLENDER_FILE_SUBVERSION, needed for do_versions. */
|
2019-01-07 22:19:13 +11:00
|
|
|
short versionfile, subversionfile;
|
2002-10-12 11:37:38 +00:00
|
|
|
} Library;
|
|
|
|
|
|
2022-04-05 08:00:20 +10:00
|
|
|
/** #Library.tag */
|
2022-01-07 12:07:37 +01:00
|
|
|
enum eLibrary_Tag {
|
|
|
|
|
/* Automatic recursive resync was needed when linking/loading data from that library. */
|
|
|
|
|
LIBRARY_TAG_RESYNC_REQUIRED = 1 << 0,
|
|
|
|
|
};
|
|
|
|
|
|
2021-09-17 16:22:29 +02:00
|
|
|
/**
|
|
|
|
|
* A weak library/ID reference for local data that has been appended, to allow re-using that local
|
|
|
|
|
* data instead of creating a new copy of it in future appends.
|
|
|
|
|
*
|
|
|
|
|
* NOTE: This is by design a week reference, in other words code should be totally fine and perform
|
|
|
|
|
* a regular append if it cannot find a valid matching local ID.
|
|
|
|
|
*
|
|
|
|
|
* NOTE: There should always be only one single ID in current Main matching a given linked
|
|
|
|
|
* reference.
|
|
|
|
|
*/
|
|
|
|
|
typedef struct LibraryWeakReference {
|
|
|
|
|
/** Expected to match a `Library.filepath`. */
|
|
|
|
|
char library_filepath[1024];
|
|
|
|
|
|
|
|
|
|
/** MAX_ID_NAME. May be different from the current local ID name. */
|
|
|
|
|
char library_id_name[66];
|
|
|
|
|
|
|
|
|
|
char _pad[2];
|
|
|
|
|
} LibraryWeakReference;
|
|
|
|
|
|
2015-05-11 16:29:12 +02:00
|
|
|
/* for PreviewImage->flag */
|
|
|
|
|
enum ePreviewImage_Flag {
|
|
|
|
|
PRV_CHANGED = (1 << 0),
|
|
|
|
|
PRV_USER_EDITED = (1 << 1), /* if user-edited, do not auto-update this anymore! */
|
2021-11-24 11:20:35 +01:00
|
|
|
PRV_RENDERING = (1 << 2), /* Rendering was invoked. Cleared on file read. */
|
2011-05-16 18:37:54 +00:00
|
|
|
};
|
2007-09-02 17:25:03 +00:00
|
|
|
|
2016-10-27 09:51:10 +02:00
|
|
|
/* for PreviewImage->tag */
|
|
|
|
|
enum {
|
2018-09-24 17:27:41 +02:00
|
|
|
PRV_TAG_DEFFERED = (1 << 0), /* Actual loading of preview is deferred. */
|
|
|
|
|
PRV_TAG_DEFFERED_RENDERING = (1 << 1), /* Deferred preview is being loaded. */
|
|
|
|
|
PRV_TAG_DEFFERED_DELETE = (1 << 2), /* Deferred preview should be deleted asap. */
|
2016-10-27 09:51:10 +02:00
|
|
|
};
|
|
|
|
|
|
2007-09-02 17:25:03 +00:00
|
|
|
typedef struct PreviewImage {
|
2011-05-16 18:37:54 +00:00
|
|
|
/* All values of 2 are really NUM_ICON_SIZES */
|
2007-09-02 17:25:03 +00:00
|
|
|
unsigned int w[2];
|
2011-01-22 04:40:15 +00:00
|
|
|
unsigned int h[2];
|
2015-05-11 16:29:12 +02:00
|
|
|
short flag[2];
|
2010-07-14 14:11:03 +00:00
|
|
|
short changed_timestamp[2];
|
2012-05-03 21:35:04 +00:00
|
|
|
unsigned int *rect[2];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-05-11 16:29:12 +02:00
|
|
|
/* Runtime-only data. */
|
2013-01-22 11:18:41 +00:00
|
|
|
struct GPUTexture *gputexture[2];
|
2019-01-07 22:19:13 +11:00
|
|
|
/** Used by previews outside of ID context. */
|
|
|
|
|
int icon_id;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-07 22:19:13 +11:00
|
|
|
/** Runtime data. */
|
|
|
|
|
short tag;
|
2019-02-27 15:07:50 +11:00
|
|
|
char _pad[2];
|
2007-09-02 17:25:03 +00:00
|
|
|
} PreviewImage;
|
|
|
|
|
|
2015-05-11 16:29:12 +02:00
|
|
|
#define PRV_DEFERRED_DATA(prv) \
|
2016-10-27 09:51:10 +02:00
|
|
|
(CHECK_TYPE_INLINE(prv, PreviewImage *), \
|
|
|
|
|
BLI_assert((prv)->tag & PRV_TAG_DEFFERED), \
|
|
|
|
|
(void *)((prv) + 1))
|
2015-05-11 16:29:12 +02:00
|
|
|
|
2020-06-30 11:22:18 +02:00
|
|
|
#define ID_FAKE_USERS(id) ((((const ID *)id)->flag & LIB_FAKEUSER) ? 1 : 0)
|
|
|
|
|
#define ID_REAL_USERS(id) (((const ID *)id)->us - ID_FAKE_USERS(id))
|
|
|
|
|
#define ID_EXTRA_USERS(id) (((const ID *)id)->tag & LIB_TAG_EXTRAUSER ? 1 : 0)
|
2010-01-17 20:06:34 +00:00
|
|
|
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
#define ID_CHECK_UNDO(id) \
|
|
|
|
|
((GS((id)->name) != ID_SCR) && (GS((id)->name) != ID_WM) && (GS((id)->name) != ID_WS))
|
2011-09-28 18:45:17 +00:00
|
|
|
|
2018-06-05 15:10:33 +02:00
|
|
|
#define ID_BLEND_PATH(_bmain, _id) \
|
2020-06-23 09:54:07 +10:00
|
|
|
((_id)->lib ? (_id)->lib->filepath_abs : BKE_main_blendfile_path((_bmain)))
|
2018-06-09 15:16:44 +02:00
|
|
|
#define ID_BLEND_PATH_FROM_GLOBAL(_id) \
|
2020-06-23 09:54:07 +10:00
|
|
|
((_id)->lib ? (_id)->lib->filepath_abs : BKE_main_blendfile_path_from_global())
|
2011-10-08 11:02:58 +00:00
|
|
|
|
2020-06-30 11:22:18 +02:00
|
|
|
#define ID_MISSING(_id) ((((const ID *)(_id))->tag & LIB_TAG_MISSING) != 0)
|
First step to handle missing libs/datablocks when reading a file.
Idea is, instead of ignoring completely missing linked datablocks, to
create void placeholders for them.
That way, you can work on your file, save it, and find again your missing data once
lib becomes available again. Or you can edit missing lib's path (in Outliner),
save and reload the file, and you are done.
Also, Outliner now shows broken libraries (and placeholders) with a 'broken lib' icon.
Future plans are also to be able to relocate missing libs and reload them at runtime.
Code notes:
- Placeholder ID is just a regular datablock of same type as expected linked one,
with 'default' data, and a LIB_MISSING bitflag set.
- To allow creation of such datablocks, creation of datablocks in BKE was split in two step:
+ Allocation of memory itself.
+ Setting of all internal data to default values.
See also the design task (T43351).
Reviewed by @campbellbarton, thanks a bunch!
Differential Revision: https://developer.blender.org/D1394
2015-10-20 14:44:57 +02:00
|
|
|
|
2020-06-30 11:22:18 +02:00
|
|
|
#define ID_IS_LINKED(_id) (((const ID *)(_id))->lib != NULL)
|
2016-07-06 14:11:01 +02:00
|
|
|
|
2022-01-28 10:22:25 +01:00
|
|
|
/* Note that these are fairly high-level checks, should be used at user interaction level, not in
|
2019-09-05 20:43:52 +02:00
|
|
|
* BKE_library_override typically (especially due to the check on LIB_TAG_EXTERN). */
|
2022-01-28 10:22:25 +01:00
|
|
|
#define ID_IS_OVERRIDABLE_LIBRARY_HIERARCHY(_id) \
|
|
|
|
|
(ID_IS_LINKED(_id) && !ID_MISSING(_id) && \
|
2021-08-05 15:24:46 +02:00
|
|
|
(BKE_idtype_get_info_from_id((const ID *)(_id))->flags & IDTYPE_FLAGS_NO_LIBLINKING) == 0 && \
|
|
|
|
|
!ELEM(GS(((ID *)(_id))->name), ID_SCE))
|
2022-01-28 10:22:25 +01:00
|
|
|
#define ID_IS_OVERRIDABLE_LIBRARY(_id) \
|
|
|
|
|
(ID_IS_OVERRIDABLE_LIBRARY_HIERARCHY((_id)) && (((const ID *)(_id))->tag & LIB_TAG_EXTERN) != 0)
|
2019-09-05 20:43:52 +02:00
|
|
|
|
2021-02-10 17:10:24 +01:00
|
|
|
/* NOTE: The three checks below do not take into account whether given ID is linked or not (when
|
|
|
|
|
* chaining overrides over several libraries). User must ensure the ID is not linked itself
|
|
|
|
|
* currently. */
|
|
|
|
|
/* TODO: add `_EDITABLE` versions of those macros (that would check if ID is linked or not)? */
|
2020-06-30 11:33:36 +02:00
|
|
|
#define ID_IS_OVERRIDE_LIBRARY_REAL(_id) \
|
|
|
|
|
(((const ID *)(_id))->override_library != NULL && \
|
|
|
|
|
((const ID *)(_id))->override_library->reference != NULL)
|
|
|
|
|
|
|
|
|
|
#define ID_IS_OVERRIDE_LIBRARY_VIRTUAL(_id) \
|
2021-01-16 10:28:47 +01:00
|
|
|
((((const ID *)(_id))->flag & LIB_EMBEDDED_DATA_LIB_OVERRIDE) != 0)
|
2020-06-30 11:33:36 +02:00
|
|
|
|
2019-06-14 23:16:04 +02:00
|
|
|
#define ID_IS_OVERRIDE_LIBRARY(_id) \
|
2020-06-30 11:33:36 +02:00
|
|
|
(ID_IS_OVERRIDE_LIBRARY_REAL(_id) || ID_IS_OVERRIDE_LIBRARY_VIRTUAL(_id))
|
2017-12-18 12:01:50 +01:00
|
|
|
|
2022-03-09 12:46:29 +01:00
|
|
|
#define ID_IS_OVERRIDE_LIBRARY_HIERARCHY_ROOT(_id) \
|
|
|
|
|
(!ID_IS_OVERRIDE_LIBRARY_REAL(_id) || \
|
|
|
|
|
((ID *)(_id))->override_library->hierarchy_root == ((ID *)(_id)))
|
|
|
|
|
|
2019-06-14 23:16:04 +02:00
|
|
|
#define ID_IS_OVERRIDE_LIBRARY_TEMPLATE(_id) \
|
|
|
|
|
(((ID *)(_id))->override_library != NULL && ((ID *)(_id))->override_library->reference == NULL)
|
2017-12-18 12:01:50 +01:00
|
|
|
|
2020-12-16 11:58:30 +01:00
|
|
|
#define ID_IS_ASSET(_id) (((const ID *)(_id))->asset_data != NULL)
|
|
|
|
|
|
2020-01-16 14:57:33 +01:00
|
|
|
/* Check whether datablock type is covered by copy-on-write. */
|
2021-01-11 14:16:10 +01:00
|
|
|
#define ID_TYPE_IS_COW(_id_type) \
|
|
|
|
|
(!ELEM(_id_type, ID_LI, ID_IP, ID_SCR, ID_VF, ID_BR, ID_WM, ID_PAL, ID_PC, ID_WS, ID_IM))
|
2018-05-24 12:04:04 +02:00
|
|
|
|
2021-06-24 19:13:52 +10:00
|
|
|
/* Check whether data-block type requires copy-on-write from #ID_RECALC_PARAMETERS.
|
|
|
|
|
* Keep in sync with #BKE_id_eval_properties_copy. */
|
|
|
|
|
#define ID_TYPE_SUPPORTS_PARAMS_WITHOUT_COW(id_type) ELEM(id_type, ID_ME)
|
|
|
|
|
|
2011-01-07 19:18:31 +00:00
|
|
|
#ifdef GS
|
2012-05-12 20:39:39 +00:00
|
|
|
# undef GS
|
2011-01-07 19:18:31 +00:00
|
|
|
#endif
|
2017-08-28 11:19:58 +02:00
|
|
|
#define GS(a) \
|
|
|
|
|
(CHECK_TYPE_ANY(a, char *, const char *, char[66], const char[66]), \
|
|
|
|
|
(ID_Type)(*((const short *)(a))))
|
2011-01-07 19:18:31 +00:00
|
|
|
|
2016-11-30 15:25:54 +01:00
|
|
|
#define ID_NEW_SET(_id, _idn) \
|
|
|
|
|
(((ID *)(_id))->newid = (ID *)(_idn), \
|
|
|
|
|
((ID *)(_id))->newid->tag |= LIB_TAG_NEW, \
|
|
|
|
|
(void *)((ID *)(_id))->newid)
|
|
|
|
|
#define ID_NEW_REMAP(a) \
|
2020-09-19 16:01:32 +10:00
|
|
|
if ((a) && (a)->id.newid) { \
|
|
|
|
|
(a) = (void *)(a)->id.newid; \
|
|
|
|
|
} \
|
|
|
|
|
((void)0)
|
2012-05-12 20:39:39 +00:00
|
|
|
|
2021-02-13 17:44:51 +11:00
|
|
|
/** id->flag (persistent). */
|
2014-11-19 20:48:35 +01:00
|
|
|
enum {
|
2022-03-10 11:32:48 +11:00
|
|
|
/** Don't delete the data-block even if unused. */
|
2017-11-29 15:05:03 +01:00
|
|
|
LIB_FAKEUSER = 1 << 9,
|
2020-03-11 12:47:25 +01:00
|
|
|
/**
|
|
|
|
|
* The data-block is a sub-data of another one.
|
|
|
|
|
* Direct persistent references are not allowed.
|
|
|
|
|
*/
|
|
|
|
|
LIB_EMBEDDED_DATA = 1 << 10,
|
|
|
|
|
/**
|
2022-03-10 11:32:48 +11:00
|
|
|
* Data-block is from a library and linked indirectly, with LIB_TAG_INDIRECT
|
2019-09-16 14:52:06 +02:00
|
|
|
* tag set. But the current .blend file also has a weak pointer to it that
|
2020-03-11 12:47:25 +01:00
|
|
|
* we want to restore if possible, and silently drop if it's missing.
|
|
|
|
|
*/
|
2019-09-16 14:52:06 +02:00
|
|
|
LIB_INDIRECT_WEAK_LINK = 1 << 11,
|
2020-06-30 11:33:36 +02:00
|
|
|
/**
|
|
|
|
|
* The data-block is a sub-data of another one, which is an override.
|
2022-03-10 11:32:48 +11:00
|
|
|
* Note that this also applies to shape-keys, even though they are not 100% embedded data.
|
2020-06-30 11:33:36 +02:00
|
|
|
*/
|
|
|
|
|
LIB_EMBEDDED_DATA_LIB_OVERRIDE = 1 << 12,
|
2021-04-07 15:50:53 +02:00
|
|
|
/**
|
|
|
|
|
* The override data-block appears to not be needed anymore after resync with linked data, but it
|
|
|
|
|
* was kept around (because e.g. detected as user-edited).
|
|
|
|
|
*/
|
|
|
|
|
LIB_LIB_OVERRIDE_RESYNC_LEFTOVER = 1 << 13,
|
Split id->flag in two, persistent flags and runtime tags.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
2015-12-27 11:53:50 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* id->tag (runtime-only).
|
|
|
|
|
*
|
2019-04-22 01:42:45 +10:00
|
|
|
* Those flags belong to three different categories,
|
|
|
|
|
* which have different expected handling in code:
|
Split id->flag in two, persistent flags and runtime tags.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
2015-12-27 11:53:50 +01:00
|
|
|
*
|
2019-01-15 23:14:35 +11:00
|
|
|
* - RESET_BEFORE_USE: piece of code that wants to use such flag
|
|
|
|
|
* has to ensure they are properly 'reset' first.
|
|
|
|
|
* - RESET_AFTER_USE: piece of code that wants to use such flag has to ensure they are properly
|
|
|
|
|
* 'reset' after usage
|
|
|
|
|
* (though 'lifetime' of those flags is a bit fuzzy, e.g. _RECALC ones are reset on depsgraph
|
|
|
|
|
* evaluation...).
|
|
|
|
|
* - RESET_NEVER: those flags are 'status' one, and never actually need any reset
|
|
|
|
|
* (except on initialization during .blend file reading).
|
Split id->flag in two, persistent flags and runtime tags.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
2015-12-27 11:53:50 +01:00
|
|
|
*/
|
|
|
|
|
enum {
|
|
|
|
|
/* RESET_NEVER Datablock is from current .blend file. */
|
|
|
|
|
LIB_TAG_LOCAL = 0,
|
2019-01-15 23:14:35 +11:00
|
|
|
/* RESET_NEVER Datablock is from a library,
|
|
|
|
|
* but is used (linked) directly by current .blend file. */
|
Split id->flag in two, persistent flags and runtime tags.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
2015-12-27 11:53:50 +01:00
|
|
|
LIB_TAG_EXTERN = 1 << 0,
|
2019-01-15 23:14:35 +11:00
|
|
|
/* RESET_NEVER Datablock is from a library,
|
2019-06-16 13:37:21 +10:00
|
|
|
* and is only used (linked) indirectly through other libraries. */
|
Split id->flag in two, persistent flags and runtime tags.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
2015-12-27 11:53:50 +01:00
|
|
|
LIB_TAG_INDIRECT = 1 << 1,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-15 23:14:35 +11:00
|
|
|
/* RESET_AFTER_USE Flag used internally in readfile.c,
|
2019-02-26 14:14:56 +01:00
|
|
|
* to mark IDs needing to be expanded (only done once). */
|
|
|
|
|
LIB_TAG_NEED_EXPAND = 1 << 3,
|
|
|
|
|
/* RESET_AFTER_USE Flag used internally in readfile.c to mark ID
|
2019-06-12 09:04:10 +10:00
|
|
|
* placeholders for linked data-blocks needing to be read. */
|
2019-02-27 19:25:21 +01:00
|
|
|
LIB_TAG_ID_LINK_PLACEHOLDER = 1 << 4,
|
Split id->flag in two, persistent flags and runtime tags.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
2015-12-27 11:53:50 +01:00
|
|
|
/* RESET_AFTER_USE */
|
|
|
|
|
LIB_TAG_NEED_LINK = 1 << 5,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-06-12 09:04:10 +10:00
|
|
|
/* RESET_NEVER tag data-block as a place-holder
|
2019-01-15 23:14:35 +11:00
|
|
|
* (because the real one could not be linked from its library e.g.). */
|
Split id->flag in two, persistent flags and runtime tags.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
2015-12-27 11:53:50 +01:00
|
|
|
LIB_TAG_MISSING = 1 << 6,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-06-12 09:04:10 +10:00
|
|
|
/* RESET_NEVER tag data-block as being up-to-date regarding its reference. */
|
2019-06-14 23:16:04 +02:00
|
|
|
LIB_TAG_OVERRIDE_LIBRARY_REFOK = 1 << 9,
|
2019-06-12 09:04:10 +10:00
|
|
|
/* RESET_NEVER tag data-block as needing an auto-override execution, if enabled. */
|
2019-06-14 23:16:04 +02:00
|
|
|
LIB_TAG_OVERRIDE_LIBRARY_AUTOREFRESH = 1 << 17,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-04-16 15:22:15 +02:00
|
|
|
/* tag data-block as having an extra user. */
|
2016-01-04 20:17:23 +01:00
|
|
|
LIB_TAG_EXTRAUSER = 1 << 2,
|
2021-02-13 17:44:51 +11:00
|
|
|
/* tag data-block as having actually increased user-count for the extra virtual user. */
|
2016-01-04 20:17:23 +01:00
|
|
|
LIB_TAG_EXTRAUSER_SET = 1 << 7,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-08-11 11:22:57 +02:00
|
|
|
/* RESET_AFTER_USE tag newly duplicated/copied IDs (see #ID_NEW_SET macro above).
|
2019-06-12 09:04:10 +10:00
|
|
|
* Also used internally in readfile.c to mark data-blocks needing do_versions. */
|
Split id->flag in two, persistent flags and runtime tags.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
2015-12-27 11:53:50 +01:00
|
|
|
LIB_TAG_NEW = 1 << 8,
|
|
|
|
|
/* RESET_BEFORE_USE free test flag.
|
2021-07-03 23:08:40 +10:00
|
|
|
* TODO: make it a RESET_AFTER_USE too. */
|
Split id->flag in two, persistent flags and runtime tags.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
2015-12-27 11:53:50 +01:00
|
|
|
LIB_TAG_DOIT = 1 << 10,
|
|
|
|
|
/* RESET_AFTER_USE tag existing data before linking so we know what is new. */
|
|
|
|
|
LIB_TAG_PRE_EXISTING = 1 << 11,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-05-18 12:53:28 +10:00
|
|
|
/**
|
|
|
|
|
* The data-block is a copy-on-write/localized version.
|
|
|
|
|
*
|
2021-08-10 10:04:57 +02:00
|
|
|
* RESET_NEVER
|
|
|
|
|
*
|
2021-05-18 12:53:28 +10:00
|
|
|
* \warning This should not be cleared on existing data.
|
|
|
|
|
* If support for this is needed, see T88026 as this flag controls memory ownership
|
|
|
|
|
* of physics *shared* pointers.
|
|
|
|
|
*/
|
2018-06-04 15:11:09 +02:00
|
|
|
LIB_TAG_COPIED_ON_WRITE = 1 << 12,
|
2021-08-10 10:04:57 +02:00
|
|
|
/**
|
|
|
|
|
* The data-block is not the original COW ID created by the depsgraph, but has be re-allocated
|
|
|
|
|
* during the evaluation process of another ID.
|
|
|
|
|
*
|
|
|
|
|
* RESET_NEVER
|
|
|
|
|
*
|
|
|
|
|
* Typical example is object data, when evaluating the object's modifier stack the final obdata
|
|
|
|
|
* can be different than the COW initial obdata ID.
|
|
|
|
|
*/
|
2018-06-04 15:11:09 +02:00
|
|
|
LIB_TAG_COPIED_ON_WRITE_EVAL_RESULT = 1 << 13,
|
2021-08-10 10:04:57 +02:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* The data-block is fully outside of any ID management area, and should be considered as a
|
|
|
|
|
* purely independent data.
|
|
|
|
|
*
|
|
|
|
|
* RESET_NEVER
|
|
|
|
|
*
|
2021-08-12 14:34:43 +10:00
|
|
|
* NOTE: Only used by node-groups currently.
|
2021-08-10 10:04:57 +02:00
|
|
|
*/
|
2018-04-30 17:52:45 +02:00
|
|
|
LIB_TAG_LOCALIZED = 1 << 14,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-06-12 09:04:10 +10:00
|
|
|
/* RESET_NEVER tag data-block for freeing etc. behavior
|
2019-01-15 23:14:35 +11:00
|
|
|
* (usually set when copying real one into temp/runtime one). */
|
2018-04-30 17:52:45 +02:00
|
|
|
LIB_TAG_NO_MAIN = 1 << 15, /* Datablock is not listed in Main database. */
|
|
|
|
|
LIB_TAG_NO_USER_REFCOUNT = 1 << 16, /* Datablock does not refcount usages of other IDs. */
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
/* Datablock was not allocated by standard system (BKE_libblock_alloc), do not free its memory
|
|
|
|
|
* (usual type-specific freeing is called though). */
|
2019-02-26 20:07:36 +01:00
|
|
|
LIB_TAG_NOT_ALLOCATED = 1 << 18,
|
2020-03-17 12:29:36 +01:00
|
|
|
|
|
|
|
|
/* RESET_AFTER_USE Used by undo system to tag unchanged IDs re-used from old Main (instead of
|
|
|
|
|
* read from memfile). */
|
|
|
|
|
LIB_TAG_UNDO_OLD_ID_REUSED = 1 << 19,
|
2021-03-09 01:01:31 +11:00
|
|
|
|
|
|
|
|
/* This ID is part of a temporary #Main which is expected to be freed in a short time-frame.
|
|
|
|
|
* Don't allow assigning this to non-temporary members (since it's likely to cause errors).
|
|
|
|
|
* When set #ID.session_uuid isn't initialized, since the data isn't part of the session. */
|
|
|
|
|
LIB_TAG_TEMP_MAIN = 1 << 20,
|
|
|
|
|
|
2020-12-31 18:03:45 +01:00
|
|
|
/**
|
|
|
|
|
* The data-block is a library override that needs re-sync to its linked reference.
|
|
|
|
|
*/
|
|
|
|
|
LIB_TAG_LIB_OVERRIDE_NEED_RESYNC = 1 << 21,
|
2017-12-15 09:43:18 +01:00
|
|
|
};
|
|
|
|
|
|
2018-12-06 17:52:37 +01:00
|
|
|
/* Tag given ID for an update in all the dependency graphs. */
|
|
|
|
|
typedef enum IDRecalcFlag {
|
2019-03-13 15:38:45 +01:00
|
|
|
/***************************************************************************
|
|
|
|
|
* Individual update tags, this is what ID gets tagged for update with. */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-02-14 12:17:29 +01:00
|
|
|
/* ** Object transformation changed. ** */
|
2018-12-06 17:52:37 +01:00
|
|
|
ID_RECALC_TRANSFORM = (1 << 0),
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-04-26 16:35:22 +02:00
|
|
|
/* ** Geometry changed. **
|
2018-12-06 17:52:37 +01:00
|
|
|
*
|
|
|
|
|
* When object of armature type gets tagged with this flag, its pose is
|
|
|
|
|
* re-evaluated.
|
2021-06-24 19:13:52 +10:00
|
|
|
*
|
2018-12-06 17:52:37 +01:00
|
|
|
* When object of other type is tagged with this flag it makes the modifier
|
|
|
|
|
* stack to be re-evaluated.
|
2021-06-24 19:13:52 +10:00
|
|
|
*
|
2018-12-06 17:52:37 +01:00
|
|
|
* When object data type (mesh, curve, ...) gets tagged with this flag it
|
2021-04-26 16:35:22 +02:00
|
|
|
* makes all objects which shares this data-block to be updated.
|
2021-06-24 19:13:52 +10:00
|
|
|
*
|
|
|
|
|
* Note that the evaluation depends on the object-mode.
|
|
|
|
|
* So edit-mesh data for example only reevaluate with the updated edit-mesh.
|
|
|
|
|
* When geometry in the original ID has been modified #ID_RECALC_GEOMETRY_ALL_MODES
|
|
|
|
|
* must be used instead.
|
|
|
|
|
*
|
2021-04-26 16:35:22 +02:00
|
|
|
* When a collection gets tagged with this flag, all objects depending on the geometry and
|
|
|
|
|
* transforms on any of the objects in the collection are updated. */
|
2018-12-06 17:52:37 +01:00
|
|
|
ID_RECALC_GEOMETRY = (1 << 1),
|
2021-07-19 10:17:38 -03:00
|
|
|
|
|
|
|
|
/* ** Animation or time changed and animation is to be re-evaluated. ** */
|
|
|
|
|
ID_RECALC_ANIMATION = (1 << 2),
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-02-14 12:17:29 +01:00
|
|
|
/* ** Particle system changed. ** */
|
|
|
|
|
/* Only do pathcache etc. */
|
|
|
|
|
ID_RECALC_PSYS_REDO = (1 << 3),
|
|
|
|
|
/* Reset everything including pointcache. */
|
|
|
|
|
ID_RECALC_PSYS_RESET = (1 << 4),
|
|
|
|
|
/* Only child settings changed. */
|
|
|
|
|
ID_RECALC_PSYS_CHILD = (1 << 5),
|
|
|
|
|
/* Physics type changed. */
|
|
|
|
|
ID_RECALC_PSYS_PHYS = (1 << 6),
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-02-14 12:17:29 +01:00
|
|
|
/* ** Material and shading ** */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-02-14 12:17:29 +01:00
|
|
|
/* For materials and node trees this means that topology of the shader tree
|
|
|
|
|
* changed, and the shader is to be recompiled.
|
|
|
|
|
* For objects it means that the draw batch cache is to be redone. */
|
|
|
|
|
ID_RECALC_SHADING = (1 << 7),
|
|
|
|
|
/* TODO(sergey): Consider adding an explicit ID_RECALC_SHADING_PARAMATERS
|
|
|
|
|
* which can be used for cases when only socket value changed, to speed up
|
|
|
|
|
* redraw update in that case. */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-06 17:52:37 +01:00
|
|
|
/* Selection of the ID itself or its components (for example, vertices) did
|
2021-01-24 16:06:58 +11:00
|
|
|
* change, and all the drawing data is to be updated. */
|
2018-12-07 18:04:13 +01:00
|
|
|
ID_RECALC_SELECT = (1 << 9),
|
2019-06-16 13:37:21 +10:00
|
|
|
/* Flags on the base did change, and is to be copied onto all the copies of
|
2018-12-06 17:52:37 +01:00
|
|
|
* corresponding objects. */
|
2018-12-07 18:04:13 +01:00
|
|
|
ID_RECALC_BASE_FLAGS = (1 << 10),
|
|
|
|
|
ID_RECALC_POINT_CACHE = (1 << 11),
|
2018-12-06 17:52:37 +01:00
|
|
|
/* Only inform editors about the change. Is used to force update of editors
|
2019-06-12 09:04:10 +10:00
|
|
|
* when data-block which is not a part of dependency graph did change.
|
2018-12-06 17:52:37 +01:00
|
|
|
*
|
|
|
|
|
* For example, brush texture did change and the preview is to be
|
|
|
|
|
* re-rendered. */
|
2018-12-07 18:04:13 +01:00
|
|
|
ID_RECALC_EDITORS = (1 << 12),
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-02-14 12:17:29 +01:00
|
|
|
/* ** Update copy on write component. **
|
|
|
|
|
* This is most generic tag which should only be used when nothing else
|
|
|
|
|
* matches.
|
|
|
|
|
*/
|
|
|
|
|
ID_RECALC_COPY_ON_WRITE = (1 << 13),
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-06-04 16:52:48 +02:00
|
|
|
/* Sequences in the sequencer did change.
|
|
|
|
|
* Use this tag with a scene ID which owns the sequences. */
|
|
|
|
|
ID_RECALC_SEQUENCER_STRIPS = (1 << 14),
|
|
|
|
|
|
2022-02-03 21:32:50 +11:00
|
|
|
/* Runs on frame-change (used for seeking audio too). */
|
|
|
|
|
ID_RECALC_FRAME_CHANGE = (1 << 15),
|
|
|
|
|
|
2019-06-04 16:52:48 +02:00
|
|
|
ID_RECALC_AUDIO_FPS = (1 << 16),
|
|
|
|
|
ID_RECALC_AUDIO_VOLUME = (1 << 17),
|
|
|
|
|
ID_RECALC_AUDIO_MUTE = (1 << 18),
|
|
|
|
|
ID_RECALC_AUDIO_LISTENER = (1 << 19),
|
|
|
|
|
|
2019-06-17 12:54:56 +02:00
|
|
|
ID_RECALC_AUDIO = (1 << 20),
|
|
|
|
|
|
2021-06-24 19:13:52 +10:00
|
|
|
/* NOTE: This triggers copy on write for types that require it.
|
|
|
|
|
* Exceptions to this can be added using #ID_TYPE_SUPPORTS_PARAMS_WITHOUT_COW,
|
|
|
|
|
* this has the advantage that large arrays stored in the idea data don't
|
|
|
|
|
* have to be copied on every update. */
|
2019-06-17 14:09:01 +02:00
|
|
|
ID_RECALC_PARAMETERS = (1 << 21),
|
|
|
|
|
|
2019-07-28 13:24:18 +02:00
|
|
|
/* Input has changed and datablock is to be reload from disk.
|
|
|
|
|
* Applies to movie clips to inform that copy-on-written version is to be refreshed for the new
|
|
|
|
|
* input file or for color space changes. */
|
|
|
|
|
ID_RECALC_SOURCE = (1 << 23),
|
|
|
|
|
|
Fix T77774: New undo code broken by 'make local' behavior.
This is actually a nice issue due to too much optimization...
* Making an ID local just reuse the linked one whenever possible, instead of
actually making a copy of it.
* Therefore, the collection containing that ID is seen as unchanged, since
the pointer itself remained the same.
* But on undo step, there is no way to reuse that local object, which then
gets deleted, and linked one gets re-created - at a different address.
* Collection, however, since unchanged, is not updated at all and thus keeps
reference to the to-be-deleted local object, instead of the linked one.
* Issue gets even worse with viewlayers, this leads to the crash.
To address this, this patch adds a 'virtual' update flags that does nothing
in update case, but will ensure that the affected IDs using the one made local
are properly detected as changed across the relevant undo step.
Note that the recalc flags were chosen mostly for a logical reason, and also
because they are already properly dealt with and cleared by undo code,
so this looks like the optimal solution.
Reviewed By: brecht
Maniphest Tasks: T77774
Differential Revision: https://developer.blender.org/D8006
2020-06-15 15:10:17 +02:00
|
|
|
/* Virtual recalc tag/marker required for undo in some cases, where actual data does not change
|
|
|
|
|
* and hence do not require an update, but conceptually we are dealing with something new.
|
|
|
|
|
*
|
|
|
|
|
* Current known case: linked IDs made local without requiring any copy. While their users do not
|
|
|
|
|
* require any update, they have actually been 'virtually' remapped from the linked ID to the
|
|
|
|
|
* local one.
|
|
|
|
|
*/
|
|
|
|
|
ID_RECALC_TAG_FOR_UNDO = (1 << 24),
|
|
|
|
|
|
2021-12-21 15:18:56 +01:00
|
|
|
/* The node tree has changed in a way that affects its output nodes. */
|
|
|
|
|
ID_RECALC_NTREE_OUTPUT = (1 << 25),
|
|
|
|
|
|
2019-03-13 15:38:45 +01:00
|
|
|
/***************************************************************************
|
|
|
|
|
* Pseudonyms, to have more semantic meaning in the actual code without
|
|
|
|
|
* using too much low-level and implementation specific tags. */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-06-12 09:04:10 +10:00
|
|
|
/* Update animation data-block itself, without doing full re-evaluation of
|
2019-03-13 15:38:45 +01:00
|
|
|
* all dependent objects. */
|
|
|
|
|
ID_RECALC_ANIMATION_NO_FLUSH = ID_RECALC_COPY_ON_WRITE,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-06-24 19:13:52 +10:00
|
|
|
/* Ensure geometry of object and edit modes are both up-to-date in the evaluated data-block.
|
|
|
|
|
* Example usage is when mesh validation modifies the non-edit-mode data,
|
|
|
|
|
* which we want to be copied over to the evaluated data-block. */
|
|
|
|
|
ID_RECALC_GEOMETRY_ALL_MODES = ID_RECALC_GEOMETRY | ID_RECALC_COPY_ON_WRITE,
|
|
|
|
|
|
2019-03-13 15:38:45 +01:00
|
|
|
/***************************************************************************
|
|
|
|
|
* Aggregate flags, use only for checks on runtime.
|
2018-12-06 17:52:37 +01:00
|
|
|
* Do NOT use those for tagging. */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-06 17:52:37 +01:00
|
|
|
/* Identifies that SOMETHING has been changed in this ID. */
|
|
|
|
|
ID_RECALC_ALL = ~(0),
|
|
|
|
|
/* Identifies that something in particle system did change. */
|
|
|
|
|
ID_RECALC_PSYS_ALL = (ID_RECALC_PSYS_REDO | ID_RECALC_PSYS_RESET | ID_RECALC_PSYS_CHILD |
|
|
|
|
|
ID_RECALC_PSYS_PHYS),
|
|
|
|
|
|
|
|
|
|
} IDRecalcFlag;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2020-03-03 17:21:28 +01:00
|
|
|
/* To filter ID types (filter_id). 64 bit to fit all types. */
|
2020-03-17 14:41:48 +01:00
|
|
|
#define FILTER_ID_AC (1ULL << 0)
|
|
|
|
|
#define FILTER_ID_AR (1ULL << 1)
|
|
|
|
|
#define FILTER_ID_BR (1ULL << 2)
|
|
|
|
|
#define FILTER_ID_CA (1ULL << 3)
|
2022-02-18 09:50:29 -06:00
|
|
|
#define FILTER_ID_CU_LEGACY (1ULL << 4)
|
2020-03-17 14:41:48 +01:00
|
|
|
#define FILTER_ID_GD (1ULL << 5)
|
|
|
|
|
#define FILTER_ID_GR (1ULL << 6)
|
|
|
|
|
#define FILTER_ID_IM (1ULL << 7)
|
|
|
|
|
#define FILTER_ID_LA (1ULL << 8)
|
|
|
|
|
#define FILTER_ID_LS (1ULL << 9)
|
|
|
|
|
#define FILTER_ID_LT (1ULL << 10)
|
|
|
|
|
#define FILTER_ID_MA (1ULL << 11)
|
|
|
|
|
#define FILTER_ID_MB (1ULL << 12)
|
|
|
|
|
#define FILTER_ID_MC (1ULL << 13)
|
|
|
|
|
#define FILTER_ID_ME (1ULL << 14)
|
|
|
|
|
#define FILTER_ID_MSK (1ULL << 15)
|
|
|
|
|
#define FILTER_ID_NT (1ULL << 16)
|
|
|
|
|
#define FILTER_ID_OB (1ULL << 17)
|
|
|
|
|
#define FILTER_ID_PAL (1ULL << 18)
|
|
|
|
|
#define FILTER_ID_PC (1ULL << 19)
|
|
|
|
|
#define FILTER_ID_SCE (1ULL << 20)
|
|
|
|
|
#define FILTER_ID_SPK (1ULL << 21)
|
|
|
|
|
#define FILTER_ID_SO (1ULL << 22)
|
|
|
|
|
#define FILTER_ID_TE (1ULL << 23)
|
|
|
|
|
#define FILTER_ID_TXT (1ULL << 24)
|
|
|
|
|
#define FILTER_ID_VF (1ULL << 25)
|
|
|
|
|
#define FILTER_ID_WO (1ULL << 26)
|
|
|
|
|
#define FILTER_ID_PA (1ULL << 27)
|
|
|
|
|
#define FILTER_ID_CF (1ULL << 28)
|
|
|
|
|
#define FILTER_ID_WS (1ULL << 29)
|
|
|
|
|
#define FILTER_ID_LP (1ULL << 31)
|
Curves: Rename "Hair" types, variables, and functions to "Curves"
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
2022-02-07 11:55:54 -06:00
|
|
|
#define FILTER_ID_CV (1ULL << 32)
|
2020-03-17 14:41:48 +01:00
|
|
|
#define FILTER_ID_PT (1ULL << 33)
|
|
|
|
|
#define FILTER_ID_VO (1ULL << 34)
|
2020-04-20 10:37:38 +02:00
|
|
|
#define FILTER_ID_SIM (1ULL << 35)
|
2015-08-10 17:26:37 +02:00
|
|
|
|
2019-10-09 16:39:00 -03:00
|
|
|
#define FILTER_ID_ALL \
|
2022-02-18 09:50:29 -06:00
|
|
|
(FILTER_ID_AC | FILTER_ID_AR | FILTER_ID_BR | FILTER_ID_CA | FILTER_ID_CU_LEGACY | \
|
|
|
|
|
FILTER_ID_GD | FILTER_ID_GR | FILTER_ID_IM | FILTER_ID_LA | FILTER_ID_LS | FILTER_ID_LT | \
|
|
|
|
|
FILTER_ID_MA | FILTER_ID_MB | FILTER_ID_MC | FILTER_ID_ME | FILTER_ID_MSK | FILTER_ID_NT | \
|
|
|
|
|
FILTER_ID_OB | FILTER_ID_PA | FILTER_ID_PAL | FILTER_ID_PC | FILTER_ID_SCE | FILTER_ID_SPK | \
|
|
|
|
|
FILTER_ID_SO | FILTER_ID_TE | FILTER_ID_TXT | FILTER_ID_VF | FILTER_ID_WO | FILTER_ID_CF | \
|
|
|
|
|
FILTER_ID_WS | FILTER_ID_LP | FILTER_ID_CV | FILTER_ID_PT | FILTER_ID_VO | FILTER_ID_SIM)
|
2019-10-09 16:39:00 -03:00
|
|
|
|
2021-03-04 18:39:07 +01:00
|
|
|
/**
|
|
|
|
|
* This enum defines the index assigned to each type of IDs in the array returned by
|
|
|
|
|
* #set_listbasepointers, and by extension, controls the default order in which each ID type is
|
|
|
|
|
* processed during standard 'foreach' looping over all IDs of a #Main data-base.
|
|
|
|
|
*
|
|
|
|
|
* About Order:
|
|
|
|
|
* ------------
|
|
|
|
|
*
|
2021-03-05 14:33:38 +11:00
|
|
|
* This is (loosely) defined with a relationship order in mind, from lowest level (ID types using,
|
2021-03-04 18:39:07 +01:00
|
|
|
* referencing almost no other ID types) to highest level (ID types potentially using many other ID
|
|
|
|
|
* types).
|
|
|
|
|
*
|
|
|
|
|
* So e.g. it ensures that this dependency chain is respected:
|
|
|
|
|
* #Material <- #Mesh <- #Object <- #Collection <- #Scene
|
|
|
|
|
*
|
|
|
|
|
* Default order of processing of IDs in 'foreach' macros (#FOREACH_MAIN_ID_BEGIN and the like),
|
|
|
|
|
* built on top of #set_listbasepointers, is actually reversed compared to the order defined here,
|
|
|
|
|
* since processing usually needs to happen on users before it happens on used IDs (when freeing
|
|
|
|
|
* e.g.).
|
|
|
|
|
*
|
|
|
|
|
* DO NOT rely on this order as being full-proofed dependency order, there are many cases were it
|
|
|
|
|
* can be violated (most obvious cases being custom properties and drivers, which can reference any
|
|
|
|
|
* other ID types).
|
|
|
|
|
*
|
|
|
|
|
* However, this order can be considered as an optimization heuristic, especially when processing
|
|
|
|
|
* relationships in a non-recursive pattern: in typical cases, a vast majority of those
|
|
|
|
|
* relationships can be processed fine in the first pass, and only few additional passes are
|
|
|
|
|
* required to address all remaining relationship cases.
|
|
|
|
|
* See e.g. how #BKE_library_unused_linked_data_set_tag is doing this.
|
|
|
|
|
*/
|
2016-08-08 17:51:15 +02:00
|
|
|
enum {
|
2021-03-24 15:07:58 +01:00
|
|
|
/* Special case: Library, should never ever depend on any other type. */
|
2016-08-08 17:51:15 +02:00
|
|
|
INDEX_ID_LI = 0,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* Animation types, might be used by almost all other types. */
|
|
|
|
|
INDEX_ID_IP, /* Deprecated. */
|
2016-08-08 17:51:15 +02:00
|
|
|
INDEX_ID_AC,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* Grease Pencil, special case, should be with the other obdata, but it can also be used by many
|
|
|
|
|
* other ID types, including node trees e.g.
|
|
|
|
|
* So there is no proper place for those, for now keep close to the lower end of the processing
|
|
|
|
|
* hierarchy, but we may want to re-evaluate that at some point. */
|
2016-08-08 17:51:15 +02:00
|
|
|
INDEX_ID_GD,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* Node trees, abstraction for procedural data, potentially used by many other ID types.
|
|
|
|
|
*
|
|
|
|
|
* NOTE: While node trees can also use many other ID types, they should not /own/ any of those,
|
|
|
|
|
* while they are being owned by many other ID types. This is why they are placed here. */
|
2016-08-08 17:51:15 +02:00
|
|
|
INDEX_ID_NT,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* File-wrapper types, those usually 'embed' external files in Blender, with no dependencies to
|
|
|
|
|
* other ID types. */
|
2021-03-24 11:39:45 +01:00
|
|
|
INDEX_ID_VF,
|
2021-03-24 11:38:22 +01:00
|
|
|
INDEX_ID_TXT,
|
2021-03-24 11:35:26 +01:00
|
|
|
INDEX_ID_SO,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* Image/movie types, can be used by shading ID types, but also directly by Objects, Scenes, etc.
|
|
|
|
|
*/
|
2021-03-24 10:56:00 +01:00
|
|
|
INDEX_ID_MSK,
|
2016-08-08 17:51:15 +02:00
|
|
|
INDEX_ID_IM,
|
2021-03-24 11:22:56 +01:00
|
|
|
INDEX_ID_MC,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* Shading types. */
|
2016-08-08 17:51:15 +02:00
|
|
|
INDEX_ID_TE,
|
|
|
|
|
INDEX_ID_MA,
|
2021-03-24 11:29:31 +01:00
|
|
|
INDEX_ID_LS,
|
2021-03-24 11:31:00 +01:00
|
|
|
INDEX_ID_WO,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* Simulation-related types. */
|
2021-03-24 11:24:16 +01:00
|
|
|
INDEX_ID_CF,
|
2021-03-24 10:54:05 +01:00
|
|
|
INDEX_ID_SIM,
|
2021-03-24 11:28:03 +01:00
|
|
|
INDEX_ID_PA,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* Shape Keys snow-flake, can be used by several obdata types. */
|
2021-03-24 11:41:37 +01:00
|
|
|
INDEX_ID_KE,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* Object data types. */
|
2016-08-08 17:51:15 +02:00
|
|
|
INDEX_ID_AR,
|
|
|
|
|
INDEX_ID_ME,
|
2022-02-18 09:50:29 -06:00
|
|
|
INDEX_ID_CU_LEGACY,
|
2016-08-08 17:51:15 +02:00
|
|
|
INDEX_ID_MB,
|
Curves: Rename "Hair" types, variables, and functions to "Curves"
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
2022-02-07 11:55:54 -06:00
|
|
|
INDEX_ID_CV,
|
2020-03-17 14:41:48 +01:00
|
|
|
INDEX_ID_PT,
|
|
|
|
|
INDEX_ID_VO,
|
2016-08-08 17:51:15 +02:00
|
|
|
INDEX_ID_LT,
|
|
|
|
|
INDEX_ID_LA,
|
|
|
|
|
INDEX_ID_CA,
|
|
|
|
|
INDEX_ID_SPK,
|
2017-06-12 20:59:54 +10:00
|
|
|
INDEX_ID_LP,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* Collection and object types. */
|
2016-08-08 17:51:15 +02:00
|
|
|
INDEX_ID_OB,
|
2021-03-24 10:46:38 +01:00
|
|
|
INDEX_ID_GR,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* Preset-like, not-really-data types, can use many other ID types but should never be used by
|
|
|
|
|
* any actual data type (besides Scene, due to tool settings). */
|
2021-03-24 12:52:51 +01:00
|
|
|
INDEX_ID_PAL,
|
2021-03-24 11:01:52 +01:00
|
|
|
INDEX_ID_PC,
|
2021-03-24 12:50:03 +01:00
|
|
|
INDEX_ID_BR,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* Scene, after preset-like ID types because of tool settings. */
|
2016-08-08 17:51:15 +02:00
|
|
|
INDEX_ID_SCE,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* UI-related types, should never be used by any other data type. */
|
2021-03-24 10:57:04 +01:00
|
|
|
INDEX_ID_SCR,
|
2018-02-22 15:10:43 +11:00
|
|
|
INDEX_ID_WS,
|
|
|
|
|
INDEX_ID_WM,
|
2021-03-24 15:07:58 +01:00
|
|
|
|
|
|
|
|
/* Special values. */
|
2016-08-08 17:51:15 +02:00
|
|
|
INDEX_ID_NULL,
|
2018-06-21 19:40:14 +02:00
|
|
|
INDEX_ID_MAX,
|
2016-08-08 17:51:15 +02:00
|
|
|
};
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
}
|
|
|
|
|
#endif
|