When adding `INSERT` operations over RNACollection items, rna diffing
code did not properly report the properties as not being equals.
This in turn triggered the 'purge unused exiting override properties'
mechanism, thus deleting the exitsting (valid) insert override property
operation.
NOTE: This should also be backported to 2.93, and probably 2.83.
Reviewed By: sybren, jbakker
Maniphest Tasks: T93353
Differential Revision: https://developer.blender.org/D13426
Original implementation was a quick prototype which should have never
landed as-is in master. It had very limiting constraints and did not
allow for any real further development.
This commit fixes the internal implementation to make more sensible,
maintainable and evolutive.
NOTE: This commit introduces another forward-incompatibility in the
Blender file format: Files saved after this commit won't open properly
in older versions of blender regarding local inserted constraints or
modifiers into overrides of linked data.
NOTE: Technical details: The 'anchor' item name/index is now stored in
`subitem_reference_` members, and the actual 'source' item name/index is
stored in `subitem_local_` members of the override property operation
data.
Previously, only the `subitem_local_` members were used, storing the
anchor item name/index, and assuming the 'source' item was always the
next in the list.
Milestone I of T82160.
Maniphest Tasks: T82160
Differential Revision: https://developer.blender.org/D13282
I think there are the following issues with {rB5fa6cdb77a98}:
- if we introduce a PROP_UNIT_TIME_ABSOLUTE unit, shouldnt it be visible
to RNA as well?
- seems like a double entry sneaked into that commit?
This is in preparation to use this for render time limit in cycles-x.
ref. T90701
Maniphest Tasks: T90701
Differential Revision: https://developer.blender.org/D12315
Allows to define properties which will have proper units displayed
in the interface. The internal storage is expected to be seconds
(which matches how other times are stored in Blender).
Is not immediately used in Blender, but is required for the upcoming
feature in Cycles X (D11526)
The naming does not sound very exciting, but can't think of anything
better either.
For test it probably easiest to define FloatProperty with subdtype
of TIME_ABSOLUTE.
Differential Revision: https://developer.blender.org/D11532
We can fairly easily detect some resync-needed cases when applying the
overrides operations on a Pointer RNA property.
This should cover all cases where an existing override's ID pointer is
changed in its linked data.
We still have to add code to detect when a not-yet-overridden linked ID
needs to become overridden (because its relations to other data-blocks
changed in a way that requires it).
Part of T83811 & D10649.
First step towards a better handling of relationships between IDs in
override context, especially when a resync is needed.
First, introduce a new flag to override operations,
`IDOVERRIDE_LIBRARY_FLAG_IDPOINTER_MATCH_REFERENCE`, for ID pointers.
It keeps track of whether an RNA ID pointer has been kept to its
'natural overriden ID' (in override hierarchy context), or has actually
been re-assigned to some other data-block.
Second, refactor how we deal with relationships between IDs in override
hierarchy code, especially in resync case. This will fixe several cases
listed in T83811, especially the case where an ID pointer to an existing
override needs to be updated to a new one due to a matching change in
linked data.
We should now have the tools to ensure consistency of ID pointers
diffing in `rna_property_override_diff_propptr`.
As a reminder, for most ID pointers we just check the actual pointer value,
but this is not possible for embedded IDs like root node trees or master
collections, and for fake embedded ones like shapekeys, so those should be
handled as mere sub-data of their owner IDs in override context.
Code generating override operations would not deal properly with Pointer
RNA properties, trying by default to use and check pointers' names
properties like it does with items of a collection.
However, using name property in pointer RNA property case makes no
sense, so specialize the `no_prop_name` flag for each case (pointer or
collection).
here, since second override would generate local data-blocks with
different names than the linked data ones, name matching would fail and
breck handling of override diffing in shapekeys.
Note that shape keys are the only one concerned by that problem, since
other embedded IDs (root node trees and master collections) are fully
real ones, so they always get the same names.
Approximately 138 changes in the spelling of compound words
and proper names like "Light Probe", "Shrink/Fatten", "Face Map".
In many cases, hyphens were used where they aren't correct, like
"re-fit". Other common changes include:
- "Datablock" -> "data-block"
- "Floating point" -> "floating-point"
- "Ngons" -> "n-gons"
These changes help give the language used in the interface
a consistent, more professional feel.
Differential Revision: https://developer.blender.org/D9923
Approximately 33 changes of capitalization to conform to MLA title style.
Differential Revision: https://developer.blender.org/D9796
Reviewed by Julian Eisel
Also makes NLA tracks and strips overridable.
User can either edit existing strips in existing NLA tracks (but not add or remove them), and/or add new NLA tracks after those comming from the linked data.
Most of the work was as usual checking operators and adding protections against illegal operations in override context.
Note that since we can only rely on indices to deal with local added tracks, we forbid any local track being before any linked/original track.
Maniphest Tasks: T72629
Differential Revision: https://developer.blender.org/D9611
In case we do not use names, code adding new insert operations in
collections was broken.
Not a proble in practice so far, since this case was not yet in use, but
will be soon with NLA overrides.
Some subtypes never made it to all neccessary places when they were
introduced. This was throwing warnings when accessing such a properties
subtype from python.
The sub_type enums were also defined in 4 different places:
- RNA_types.h 'PropertySubType'
- rna_rna.c 'rna_enum_property_subtype_items'
- rna_rna.c 'subtype_items'
- bpy_props.c as multiple enums
This patch syncs the definitions across all places so that they are the
same everywhere. It also looks redundant to define these twice in
rna_rna.c, now just use 'rna_enum_property_subtype_items' there (and get
rid off 'subtype_items').
Also moved 'POWER' & 'TEMPERATURE' to number enum in bpy_props (these
were defined in the array enum).
Fixes T82167.
Maniphest Tasks: T82167
Differential Revision: https://developer.blender.org/D9371
Before, it might have been possible in some cases (when there were no
items at all anymore in the collection) to miss that cleanup step,
leaving ghost useless and invalid operations around.
Handling of pointer replacements in collection items lead to validating
all operations for a given property, when some might actually be no more
valid and would need to be cleaned up.
Related to T81059, found while investigating it.
Supporting IDProperty-based data storage here in a generic way is fairly
simple, unlike actual RNA data (DNA-based), for which getting a proper
generic way to duplicate them from within RNA is currently not really
possible.
Part of T79562.
RNA diffing code was not dealing properly valid NULL PointerRNA (like
the empty texture slots of a ParticleSettings e.g., which were cause of
crash in that report).
To be backported to 2.90 and 2.83.
Based on the original patch by Vaishnav S (@padthai), this adds
support for temperature units. Initially supported units are Celsius,
Kelvin, and Fahrenheit.
The units aren't used anywhere with this commit. Those changes should
happen in separate patches by adding PROP_TEMPERATURE to RNA property
definitions. But it should be ensured that the various solvers and
simulations actually properly use real units.
The complexity of some of the changes comes from the fact that these
units have offsets from each other as well as coefficients. This also
makes the implementation in the current unit system troublesome.
For example, entering 0C evaluates correctly to 273K, but 0C + 0C
doubles that result, because each unit value is evaluated separately.
This is quite hard to solve in the general case with Blender's current
unit system, though, so it is not handled in this commit.
Differential Revision: https://developer.blender.org/D4401
This function is more expansive than the simpler `rna_ensure_property()`
one, and should only be used when IDProperty data is actually needed.
If one only needs to ensure it has a valid PropertyRNA pointer,
`rna_ensure_property()` is much more efficient.
Also add compiler warnings when results of those functions are unused,
this should never be the case.
The triplet static RNA / runtime RNA / custom properties is a real pain to
deal with...
Using the new `PropertyRNAOrID` struct helps clarifying and properly
dealing with all three cases.
Note that this makes override of py-defined RNA properties working
(support for that will be committed next).
Differential Revision: https://developer.blender.org/D8249
By using own path construction instead of handy printf-like functions,
we get a 10% improvement on overall diffing process!
This remains way to slow on some complex production characters, but
always good to have still.
The override operations generated from 'do not follow' RNA pointer
properties (i.e. pointers to other IDs) were not properly clearing their
'no more used' flag, and hence were incorrectly deleted on second save.
The triple possible status of an PropertyRNA (actual C-defined prop,
py-defined IDprop behaving similar ot RNA one, or actual 'pure' custom
prop) is really confusing... Not to mention the _RNA_UI ugly thingy on
top of that. :/
The old layout of `PointerRNA` was confusing for historic reasons:
```
typedef struct PointerRNA {
struct {
void *data;
} id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
This patch updates it to:
```
typedef struct PointerRNA {
struct ID *owner_id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
Throughout the code base `id.data` was replaced with `owner_id`.
Furthermore, many explicit pointer type casts were added which
were implicit before. Some type casts to `ID *` were removed.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D5558
The pointer argument is supposed to be the object the property belongs
to, not a pointer to the property metadata itself. This only worked
before because the argument was never used.
We were storing the 'item' part in the RNA path of the override op
itself, which will not work with IDs because overriding local one might
not have the same name as the linked one (when some local ID with same
name already exists).
Now we are properly handling this using the expected actual override
operation, which stores necessary data (names or indices) from both
local and linked data.
