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.
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...
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...
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 b1af682001).
* 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
This introduces a new iterator, FOREACH_COLLECTION, that unlike the
FOREACH_SCENE_COLLECTION it iterates over all the Blender file
collections, including the scene master collection, as well the database
ones (bmain).
Reviewers: brecht
This partially reverts commit a77feabb51,
removing the shallow 'duplicate hierarchy' option from outliner.
Core changes from that commit in BKE_collections are kept.
Convention was not to but after discussion on 918941483f we agree its
best to change the convention.
Names now mostly follow RNA.
Some exceptions:
- Use 'nodetrees' instead of 'nodegroups'
since the struct is called NodeTree.
- Use 'gpencils' instead of 'grease_pencil'
since 'gpencil' is a common abbreviation in the C code.
Other exceptions:
- Leave 'wm' as it's a list of one.
- Leave 'ipo' as is for versioning.
Point is, you may want to duplicate your set of collections, but not
duplicate all their objects.
Some notes:
* Am rather skeptical about the practice of using operator name to
define behavior of some common exec code. Imho, that should be a single
operator with an enum to refine its behavior (@cambpellbarton may also
have an opinion here?). Left it as-is for now, because this seems to be
used by other operators too in that code. :/
* @dfelinto, @pablovazquez, @billreynish am not so happy with current
names, but cannot find really good short ones either... Also, shouldn't
we move those into a dedicated `Duplicate` sub-menu?
That one was an empty place-holder, BKE_collection_duplicate() is now
doing that. And its call from full scene copying is not needed
currently, 'deep copy' in that case is handled in editor's
`ED_scene_add()`.
Note that at some point, we might want to move that logic into BKE, but
for now let's keep thing as they are - working.
* Fix incorrect handling of children collections being linked more than
once in the hierarchy (previous code would make a new copy for each
link, instead of just re-linking the first copy for each extra link).
* Simplify some aspects of it (we do not need a GHash for new objects,
we can use ID->newid pointer instead, and some iterations can be done
directly on existing linked lists of old collection, instead of making
temp local copies of them).
* Move all copy logic into a single private recursive function (it was a
bit odd/disturbing to see calling function being indirectly called again
by the recursive helper one - not wrong, but that kind of code path can
quickly become problematic in recursive patterns).
* Added some comments about expected behavior of
`BKE_collection_duplicate()` depending on its booleans options.
As per the suggestion on T57064, this introduces two new options to duplicate collections.
We then have:
* Duplicate > Collection (New collection with linked content).
* Duplicate > Hierachy (Duplicate entire hierarchy and make all contents single user).
* Duplicate > Linked Hierarchy (Duplicate entire hierarchy keeping content linked with original).
Development TODO: `single_object_users` can/should use the new functions.
Reviewers: brecht, mont29
Subscribers: pablovazquez, billreynish, JulienKaspar
Differential Revision: https://developer.blender.org/D4394
At some I unified the "move to collection" with the remove from all collections
functionality. That meant that even when we were still to keep the object in one
of the collections we would clear its rigid body data.
Now why to even remove the rigidbody data when removing an object from all
collections? That mimics the 2.79 behaviour when we were to unlink an
object from a scene. I suspect it has to do with the rigid body data
being tied to the scene rigid body. Which is a strange design anyways
(add to the list?) since an object can be in more than one scene.
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
We were never removing the parent collection from a collection upon removal
of the parent.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D4099
There were at least three copies of those:
- OB_RECALC* family of flags, which are rudiment of an old
dependency graph system.
- PSYS_RECALC* which were used by old dependency graph system
as a separate set since the graph itself did not handle
particle systems.
- DEG_TAG_* which was used to tag IDs.
Now there is a single set, which defines what can be tagged
and queried for an update. It also has some aggregate flags
to make queries simpler.
Lets once and for all solve the madness of those flags, stick
to a single set, which will not overlap with anything or require
any extra conversion.
Technically, shouldn't be measurable user difference, but some
of the agregate flags for few dependency graph components did
change.
Fixes T58632: Particle don't update rotation settings
Logical flaw in `BKE_scene_objects_iterator_begin()` code (two errors
actually, wrong handling of first object of Master collection, and
missing call to `object_base_unique()` to 'register' that first object
and avoid getting it returned a second time).
Simply fixed by always calling `BKE_scene_objects_iterator_next()`
after minimal proper init, that one knows how to do the things. ;)
