Currently this is needed to properly tag PointCache's for info update
(fixes an issue reported in T82503).
Suspect we may need this in more cases in the future though, RNA
assign/update processes are not always 100% enough to deal with
complicated corner cases.
No ID (even remotely) related to Main database should ever be created
directly through MEM_mallocN. Using `BKE_libblock_alloc` is the bare
minimum.
Note that there is no behavior change expected here.
The flag syncing code expects to find collection flags in same view
layer before and after the move, it even has an assert for it. However,
there is one case where this doesn't happen, when dragging a collection
that exists in two scenes to the master collection.
This commit removes this assert, frees the temporary flag structs
separately, and updates some comments with this information.
There is more detail in the adjusted comment.
Differential Revision: https://developer.blender.org/D9785
The original code for viewlayer collection flag syncing across moves
from D9158 didn't consider the case where the collection could no longer
be found in its original view layer (moving a collections betwen scenes).
The fix is to just check if the collection starts in the same scene as
it will be moved to before trying to do the flag syncing. I thought about
this for a while and tried a couple other solutions, but I couldn't come
up with a proper way to support syncing the layer collection flags across
scenes without making too many changes.
Differential Revision: https://developer.blender.org/D9568
This is essentially adding that new callback, and using it only for already
existing Scene's 3DCursor.
Note that the place where this is called has been moved again, after all
have been lib-linked, such that those callbacks may also work on ID pointers.
Maniphest Tasks: T71759
Differential Revision: https://developer.blender.org/D9237
This one was a bit more tricky, because the file loading is
mixed with versioning code and because collections are
embedded into scenes.
All tests that passed before, still pass.
The code that restored collection flags after they are rebuilt when
moving a collection didn't take into account collection children. The
flag for the active collection was properly restored, but all of its
children would take on the exclude flag of the collection the active
collection was dragged into.
This commit builds a temporary tree structure to store the flags for
the moving collection and its children. Then it reapplies these flags
after `BKE_main_collection_sync`.
Differential Revision: https://developer.blender.org/D9158
Better use higher-level code from common ID management when possible.
Helps to de-duplicate logic, and reduces outside usages of more
'dangerous' functions.
Note that we could get rid of many of those `BKE_<id_type>_add`
functions now, but on the other hand several of those take extra
parameters and perform additional actions, so think we can keep them all
for now as 'non-standard ID specific creation functions'.
This adds color tagging to collections. There are 8 color
options which are themable in the user preferences, with an additional
option for no color tag by default.
This adds a new filled collection icon and 8 colored variants of the
icon that can be themed in the user preferences.
In this commit the only interface to setting the color tags is through
Python, and there is nowhere in the interface where the collections are
shown colored. Setting and viewing the color tags from the outliner will
follow.
Manifest Task: https://developer.blender.org/T77777
Differential Revision: https://developer.blender.org/D8622
This is part of T76372.
It adds the `blend_write`, `blend_read_data`, `blend_read_lib`
and `blend_read_expand` which correspond to the various
steps when reading and writing .blend files.
Having these callbacks allows us to decentralize the blenloader
code a lot more. This has the affect that code related to any
specific ID type is less scattered.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D8670
Code dealing with object copy of master collection was bugy in case one
of the new object copy would get a name lesser than the original object,
leading to new copy being inserted before original one in lists.
Maniphest Tasks: T79931
Differential Revision: https://developer.blender.org/D8656
Old and new collections are the same data in Master collection case
here, so we cannot consider the `gobject` listbase of `collection_old`
as always immutable.
That project cannot be opened correctly ayway, it has recursive
collections intanciating themselves...
But at least now we have a check at startup to detect and 'fix' those
nasty cycles in collections.
Note that this behavior is enforced on user level for now, but on code
side it is controlled with a flag, which should make it easy to refine
that behavior if needed.
Only exception is when we duplicate a linked ID directly (then we assume
user wants a local deep-copy of that linked data, and we always also
duplicate linked sub-data-blocks).
Note that this commit also slightly refactor the handling of actions of
animdata, by simplifying `BKE_animdata_copy_id_action()` and adding an
explicit new `BKE_animdata_duplicate_id_action()` to be used during ID
duplication (deep copy).
This also allows us to get rid of the special case for liboverrides.
Now that we have a uniform consistent behavior in all our ID duplicate
funtions, we can easily factorize it greatly. Code gets cleaner,
smaller, and less error-prone.
Note that ultimately, this duplicate/deep copy behavior could be added
as a callback of IDTypeInfo.
We could also rethink the duplicate flags (some data, even some obdata,
like Lattice, are not coverred currently).
And so on. But at least code should now be much more easily maintainable
and extendable.
Previously, object (and sub-data) actions would be controlled by the
user preferences flag, collections actions would never be duplicted, and
scenes actions were always duplicated...
Now they all follow the user preferences settings.
Main change from user side, besides that all pointers should now be
properly remapped to new IDs, is that linked objects are no longer
preserved when doing a full copy of scenes.
Will open a task to check whether we actually still want that behavior
(and re-code it in a more correct way then).
This is the main part of work done here, it aims at uniformizing and
sanitizing that 'deep copy' process for supported IDs (currently scenes,
collections and objects).
Note that there will be more follow up commits after that one, but this
should be the most risky and changing one.
Using enum type itself in implementations, and uint in headers (as using
enums types in headers is a pain when enum are not defined and used in a
single same header file...).
It makes no sense to deep-copy a collection and not also copy its
children collections... Parameter was not used anymore anyway.
So now this duplicate function will always at least deep-duplicate all
of its children collections, recursively.
We want to get rid of those for all ID types ultimately, but that one
was only used in one place, being the only one calling
`BKE_collection_duplicate` without hierarchical duplicate and parent
collection pointer, effectively using the full power of the complex deep
duplication code for a mere `BKE_id_copy` call...
This will allow for further cleanup in duplicate code.
Now that `BKE_main_collections_parent_relations_rebuild()` is called
from readfile code, we need to make it resilient to potential NULL
master collection pointer in scenes.
Override collections do not support that, add proper checks in BKE code
adding objects to collections.
Also try to find a suitable collection in parents in that case.
Note that this is enforced on 'public' API level, internal code can
still bypass those checks if needed. Exposing this possibility to public
API should not be needed.
Those are then assumed already duplicated, and not touched. However, all
of ther objects and sub-collections can still be processed as with any
other regular collection...
This commit enables basic copy of overrides on generic ID level, as well
as from (deep) copy operators for objects and collections.
So e.g. if your linked overridden caracter is in a collection, you can
now (from the outliner) Duplicate that override collection to get a new
overriding copy of the character.
We still need operators (new or modifying existing ones) to handle that
from 3DView e.g.
Note that deep copy code for objects/collections (and incidently
animdata) had to be modified to avoid duplicating/making local IDs that
remain linked ones being used by overrides ones.
When using the "Make Library Override" operator on instance collections, keep
the overriden collection in the parent collection of the instance empty.
Previoulsy the collection would be added to the scene collection, which was
confusing and not what users expected. It was placed there for a reason after
all.
Part of T76555.
Reviewed by: Andy Goralczyk, Bastien Montange.
Differential Revision: https://developer.blender.org/D7626
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
