Age | Commit message (Collapse) | Author |
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
|
|
|
|
Display exact integer values of a floating point fields without
a fraction if the step is also an exact integer. This is intended
for cases when the value can technically be fractional, but most
commonly is supposed to be integer.
This handling is not applied if the field has any unit except frames,
because integer values aren't special for quantities like length.
The fraction is discarded in the normal display mode and when copying
the value to clipboard, but not when editing to remind the user that
the field allows fractions.
Differential Revision: https://developer.blender.org/D13753
|
|
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
|
|
This allowed custom ID-properties to share a name-space
with regular properties which won't work well as the names may collide.
|
|
|
|
|
|
Also use doxy style function reference `#` prefix chars when
referencing identifiers.
|
|
|
|
|
|
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
|
|
That one skiped the move to CLOG a few weeks ago, could spam a lot in
the console in some cases.
|
|
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.
|
|
Use _fn as a suffix for callbacks.
|
|
|
|
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.
|
|
instance.
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.
|
|
Caused by not going through the proper accessor function to access the
property identifier.
|
|
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
|
|
Prepare for `BLI_str_unescape` which doesn't read well
without the separator.
|
|
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.
|
|
results in Crash.
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
|
|
Storing this info will help with dealing with reset operations and the
like (as we do not want to reset overrides of ID pointers essentially).
|
|
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.
|
|
|
|
|
|
pqrt of T72604.
|
|
Note that `BKE_library.h`/`library.c` were renamed to
`BKE_lib_id.h`/`lib_id.c` to avoid having a too generic name here.
Part of T72604.
|
|
cloth modifier.
Was not taking into account the case where pointer RNA prop is valid,
but has no data (i.e. is a 'null' pointer)...
|
|
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
|