| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
'template'.
Similar to what we already had using an object as 'template'.
|
|
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.
|
|
Cyclic check was not checking for collections instanciated by objects...
|
|
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.
|
|
Followup to rB74ec37b70cbc8dc2, also missed a case in collection
deepcopy then.
|
|
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
|
|
|
|
Differential Revision: https://developer.blender.org/D7408
|
|
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
|
|
|
|
'Private' can be a rather confusing term, especially when considering
its meaning in programming languages.
So now root node trees and master collections are 'embedded' IDs
instead.
|
|
Note: we still need BKE_collection_free since we call it from scene.c.
|
|
Instead of using anonymous booleans flags, also allows to keep the same
behavior in all cases, without needing special handling from calling
code for our beloved oddballs object proxies...
|
|
This info is now stored in ID tags themselves, so no need to pass an
extra anonymous boolean parameter around, yay!
|
|
Also removed some only used locally from the header, `BKE_lib_id.h`
is already way too big, no need to overload it with unused things.
|
|
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.
|
|
Once again, am not exactly sure why that was working before, and not
anymore - but in any case, doing that kind of update here is not only
useless (since we have to do it at the end of the whole
collections/objects duplication and remapping anyway), it is also rather
dangerous, as collections are currently in rather invalid states at that
point of the code...
Note that in ideal world, `BKE_main_collection_sync()` & co would be
lazy (setting only a flag, then code actually needing this to be valid
again should call some sort of `BKE_main_collection_sync_ensure()`).
Then we would not have to worry about such things (and we'd get nice
performance improvements in some cases, also in main remapping code,
etc.).
Food for some refactoring, some day...
|
|
That would lead to crashes and other issues. The solution is not elegant
though, it involves resyncing all the collections again.
Differential Revision: https://developer.blender.org/D6043
|
|
Side-reported in T70505.
Code did not ensure deleted object was removed from the RBW constraints
collection, leading to some invalid status (object in constraints
collection but without relevant contraints data).
Also fixed another issue - code deleting RBW objects would try to remove
any constraint one using it as target, in a very bad and broken way,
since you cannot iterate over objects of a collection while removing
some... Now instead just NULLify relevant pointers... I hope it works,
otherwise we'll have to take a different approach.
Needless to stress again how weak the whole RBW code is in general, and
regarding same object being used by RBW in more than one scene in particular,
that is known broken situation anyway.
|
|
Now that we 'properly' support private ID data in lib management, there
is no reason anymore to have that custom func, badly named and
by-passing the whole generic ID management code.
|
|
In its current version that was a totally useless extra layer of crap
that we can totally avoid. Plus name was bad too.
|
|
Same issue here as with root nodetrees, those are private ID data owned
by another ID, and not in Main DB. This requires special handling.
there are still quiet a few things to do here, like getting rid of
special code for master collection (regular ID copying should handle
that just as it already does for root nodetrees), cleanup in ID copying
code, etc.
|
|
Some statements were split across multiple lines because of their
trailing comments.
In most cases it's clearer to put the comments above.
|
|
collections.
Some ugly very low-level collection code was using the generic
LIB_TAG_DOIT tag... should never happen, that one is for rather
high-level code to use, core process shall use own tags.
|
|
RigidBodyConstraints collection.
We only had a very limited, specific handling of that in collection
duplication code, but this has to be handled at a much more general
level in Object copy code itself, since it makes no sense to duplicate
rigidbody object data without adding new copy to relevant rigidbody
collections...
WARNING: This is a fairly risky rework of rigidbody handling logic
when copying an Object data-block. It is *NOT* considered safe enough
for 2.80 release.
I tried to take into account copy flags to not mess with other IDs
(collections) when we are copying outside of Main, and also not do deg
tags when this is forbidden, but risk of something going wrong here is
too high...
|
|
Not the cleanest solution, but should be fine until we add support for driving
collection visibility and revise this system as a whole.
|
|
added to Rigid Body World.
As title says, we need to add back new copies of objects that are RB
items to the RBW collections...
|
|
parent collection.
Collections are a tad annoying with all their caching of objects... When
we modify content of a children collection, we need to tag DeG for CoW
update of all of the ancestors.
For now keeping that recursive tagging helper private, but would not be
surprised if we found more similar cases and needed to expose it to more
code...
|
|
|
|
Same for holdout, indirect only and exclude.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4945
|
|
It's not always possible to keep 'by hand' parent relationships valid in
collections hierarchy. Add functions to remake those
(re-using/factorizing code from `readfile.c` `lib_link_collection_data()`
function).
Can't stress again how painful it is to have those kind of backward
relationships in our data structures, those *always* end up being
serious issues to keep in sync... Should only be generated on the fly
when needed, period. :(
|
|
`BKE_collection_object_add_from()` would not check wether collections
were local or not... Trivial to fix.
Note that here I assume we do not use that function in some special
cases where we would like to edit linked datablocks. Think that is
reasonable stance, though.
|
|
|
|
No major API change here, only in the outliner restriction column
variables (e.g., show_restrict_column_selectable > show_restrict_column_select).
* Get rid of _INSTANCE (introduced on b1af68200159).
* Differentiate (everywhere but the API) between HIDE (temporary) and VIEWPORT (global).
* Use the expected icon for restrict viewport (same as objects and modifiers).
* selectable > select
|
|
See T61578 for discussions and mockups.
Visibility Options
==================
We are adding more granular control over restriction columns in the outliner,
exposing "indirect only" and "holdout" as options, and change the way
users enable/disable collections in a viewlayer.
We also rename the object viewport restriction to hide instance.
So the options we have are:
Collection
----------
* Render Visibility
* Instance Visibility
* Selectable
(View) Layer Collection
-----------------------
* Enable
* Holdout
* Indirect Only
* Viewport
Shortcuts
=========
Isolate Collection
------------------
* Ctr + click isolates the collection.
It turns all its parents and children "visible", and all the other
collections "invisible".
If ALL the collections were already properly set, we re-set the
collections to their default value.
Set Collection Inside Collections and Objects
---------------------------------------------
* Shift + click: Set/unset inside collections and objects.
We only set objects values as well when we are in View Layer mode and
(obviously) when the objects have a matching property.
Icons
=====
Little reminder that we will need better icons for holdout, indirect only, and
probably instanced (nothing wrong with the current, but it differs from
the proposal when it is turned off).
Also, we need to decide where do we want the modifier/bones/... icons to
be (in which column) and ideally make sure their icons match the ones we
use for collections/objects.
At the moment those are using the screen icon, which is not being used
by collections.
Reviewers: brecht, billrey
Subscribers: pablovazquez
Differential Revision: https://developer.blender.org/D4823
|
|
|
