This renames the `OB_GPENCIL` object type and the `ID_GD` to `OB_GPENCIL_LEGACY` and `ID_GD_LEGACY` respectively.
There is no change for the user.
Pull Request: blender/blender#105541
Imgaes which are render results and the like should not be considered as
unused, even if they do not have actual users.
NOTE: this does not apply to 'regular' images, which should be purged by
the recursive purge code, even if they are currently shown in an Image
Editor (this is not actual data usage).
In some cases, there is a chance code already knows who might be the
owner of the given ID, in which case it can be more efficient to check
it first (especially in cases like embedded node trees or scene
collections, where the only other way is to loop over all possible
owners currently).
Will be used in next commit in some Outliner fix.
New remapper code would also fail in some cases when remapping
libraries, similar to the issue yesterday, because ID_LI type had no
mask value.
That would fail to remap `parent` member of a library to NULL when
deleting that parent, leading to a crash e.g. in Outliner tree building
code.
Reported by @JulienKaspar from Blender studio.
Cases were e.g. an object would use a material, and this material would
use this object (e.g. through a driver), even if both those data-blocks
are technically unused, they would remain forever since they were not
detected as such.
Now this is properly detected and purged as part of the 'recursive
purge' operation.
This commit renames enums related the "Curve" object type and ID type
to add `_LEGACY` to the end. The idea is to make our aspirations clearer
in the code and to avoid ambiguities between `CURVE` and `CURVES`.
Ref T95355
To summarize for the record, the plans are:
- In the short/medium term, replace the `Curve` object data type with
`Curves`
- In the longer term (no immediate plans), use a proper data block for
3D text and surfaces.
Differential Revision: https://developer.blender.org/D14114
For an upcoming project we would want to match multiple id types in a
single go. To not replicate the implementation using other types we
introduce `BKE_library_id_can_use_filter_id` that returns all supported
types as a filter.
Not all ID types have a filter_id (ID_LI, ID_KE, ID_SCR) These
exceptions are not available in the filter_id function.
Reviewed By: mont29
Maniphest Tasks: T95279
Differential Revision: https://developer.blender.org/D14061
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
This change will make handling of liboverrides hierarchies (especially
resyncing) much easier and efficient. It should also make it more
resilient to 'degenerate' cases, and allow proper support of things like
parenting an override to another override of the same linked data (e.g.
a override character parented to another override of the same
character).
NOTE: this commit only implements minimal changes to add that data and
generate it for existing files on load. Actual refactor of resync code
to take advantage of this new info will happen separately.
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
Part of T91671.
Not much else to say, this is mainly a massive deletion of code.
Note that a few cleanups possible after this proxy removal were kept out
of this commit to try to reduce a bit its size.
Reviewed By: sergey, brecht
Maniphest Tasks: T91671
Differential Revision: https://developer.blender.org/D13995
Since 2.8, background images are tied to cameras (in 2.79 these were
tied to a View3D I think).
Code in `BKE_library_id_can_use_idtype` wasnt taking this relation
between `Camera` and `Image` into account, thus leading to ID deletion/
unlinking not working properly -- in particular `libblock_remap_data`
not doing its thing (and leaving the camera as a user of the image),
then things went downhill from there...
Now make the "Camera-can-use-an-Image" relation clear in
`BKE_library_id_can_use_idtype`.
Maniphest Tasks: T94544
Differential Revision: https://developer.blender.org/D13722
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
- Minor improvements to doc-strings.
Ref T92709
Those were used in a very few places to detect whether iteration should
be stopped or not, but one can use `BKE_lib_query_foreachid_iter_stop`
now for that.
Also fix early break handling in embedded IDs processing.
Fix T90922: Fix return policy inconsistency in `scene_foreach_id`.
In case `library_foreach_ID_link` would return early in recursive
process, it would not properly free its utils data.
Also add proper iteration break in case some sub-calls requested it.
Finally, make this function return a boolean to know whether iteration
should be stopped or not (will be used in future commit to fix this
handling in embedded IDs case).
Part of T90922: Fix return policy inconsistency in `scene_foreach_id`.
Add a function to check if iteration over ID usages should stop (using
internal `IDWALK_STOP` status flag).
Use it in `BKE_LIB_FOREACHID_PROCESS_` macros, and in
`window_manager_foreach_id` to handle properly the active workspace case
(previous code could skip the call to `BKE_workspace_active_set` in case
iteration over ID usages was stopped by callback on that specific ID
usage).
Part of T90922: Fix return policy inconsistency in `scene_foreach_id`.
Embedded IDs (root nodetrees, master collection, etc.) pointer itself is
not editable, but their content may be overridden.
LibOverride code is supposed to know how to handle those embedded IDs.
While this is still very fuzzy in current code, this old behavior makes
it close to impossible to efficiently use out-of-main temp data, as it
implies that we'd need to update refcounts everytime we add something
back into BMain (an 'un-refcount' ID usages when removing from BMain).
Now that we have two separate flags/tags for those two different things,
let's not merge them anymore.
Note that this is somewhat on-going process, still needs more checks and
cleanup. Related to T88555.
Not all python-defined ID properties are overridable (yet), this needs
to be detected by libquery 'foreach id' code, such that those ID
pointers can be ignored by override code when working on override
hierarchies.
Fixes part of the issues found while investigating studio files (namely,
some py-defined ID pointer properties from rigify that are not currently
overridable would cause issues and false detections during resync).
Move the detection/decision of whether an ID pointer should be taken
into account in library override hierarchy processing to the LibQuery
area of code, by introducing a new callback flag.
This allows to factorize the test logic, be explicit in liboverride code
about ID relationships that can be ignored when exploring the override
hierarchy, and adds the possibility to do more checks about pointers to
be tagged as non-overridable in the future.
Note that all but the 'special' ID pointers (loop-back, embedded, etc.)
should be overridable. If some is not, relevant IDType 'foreach_id'
callback code is reponsible to tag it properly.
Python-defined IDProperties however are not systematicaly overridable
(yet), so this should allow us to detect that case and act accordingly
in an incomming commit.
No behavioral change expected in this commit.
The `MAX_LIBARRAY` define was an annoying doublon to the `INDEX_ID_MAX` enum value
now defined in `DNA_ID.h`, and it is no more useful.
And comments were somewhat outdated. Also added an explanation about
chosen order for the `INDEX_ID_<IDTYPE>` order.
With the option to detect orphaned data recursively (i.e. if ID `a` is the
only user of ID `b`, and ID `a` is unused, ID `b` will also get tagged
as unused).
To be used by the Purge operation.
`bmain.relations` is used to store temp data of relations between IDs,
to speed-up some complex processes heavily relying on such information.
Previous implementation was failry unclear/confusing, and required a
not-so-nice hack to 'tag' some ID as processed.
New code changes as such:
* Using `from`/`to` naming (instead of `user`/`used`).
* More clear separation between `to` `id_pointer` and `from` one,
using an union instead of hacking around difference between `ID *` and
`ID **` pointers.
* Adds storage of `session_uuid` informations (mainly useful as
debug/ensuring proper consistency of data currently).
* Adds a structure per ID in the mapping. This enables possibility of
storing tags (and potentially more data in the future) per-ID,
without polluting the IDs themselves with very short-life info.
Differential Revision: https://developer.blender.org/D10164
A simulation data block has an embedded node tree, which requires
special handling in a couple of places. Some of those places were
missing beforehand.
This also adds a relation to make sure that the simulation is evaluated
after animations on the embedded node tree are evaluated.
Now callbacks for animdata, nla strip and fcurve are in their own proper
BKE files (mimicking `foreach_id` callback of `IDTypeInfo`).
This commit also fixes some missing handling of ID pointers (text ID and
IDProperties of script fcurve modifier...).
