| Age | Commit message (Collapse) | Author |
|---|
|
This function doesn't free the collection, only it's memory.
|
|
This makes the internal naming consistent with the public API. And also gives
us a visibility_flag rather than restrictflag that can be extended with more
flags.
|
|
Collection"
Note that this name is essentially never used anywhere, besides as 'information'
mostly accessible from python console. Those embedded IDs are not in Main, so they
are not accessible by name ever, and mostly unusable from animation perspective
(either drivers or fcurves).
Therefore, no breakage is expected in user scripts or addons, nor when
loading in older versions of Blender.
Reviewed By: dfelinto, brecht
Differential Revision: https://developer.blender.org/D11812
|
|
|
|
This is complex situation. Tagged ID deletion (used to delete several
data-blocks at once) removes IDs to be deleted from Main.
But when we remove deleted IDs' usages of other IDs (using
`BKE_libblock_relink_ex`), some specific post-process is required on
some types, like Collections. Those post-processes would in some cases
rely on data actually being in Main.
That failing condition would lead in existing code on missing processing
the very ID (collection) we were working on, leading to missing removing
some child collection pointers, leading to the crash (later on in
LayerCollection resync process).
For now we go with an optimization & fix that avoids processing all
collections in Main when we actually know which one we are working one
(case of `BKE_libblock_relink_ex`, but not of
`BKE_libblock_remap_locked`).
This is however yet another demonstration of the need to rework that
whole collection/layer resync process, since it is not only extremely
inneficient currently, but it also requires valid Main/ID state way too
deep into the remapping code.
NOTE: This fix may very well not catch/address all possible fail cases
here, dealing with the double parent/child relationships of collections
is challenging...
Issue reported by @eyecandy from the studio, thanks.
|
|
scene's collections.
This is internaly using the code of `BKE_scene_objects_iterator` and
steals its gset. More efficient than using that iterator directly to
rebuild another GSet...
|
|
|
|
This adds the LineArt grease pencil modifier.
It takes objects or collections as input and generates various grease
pencil lines from these objects with the help of the active scene
camera. For example it can generate contour lines, intersection lines
and crease lines to name a few.
This is really useful as artists can then use 3D meshes to automatically
generate grease pencil lines for characters, enviroments or other
visualization purposes.
These lines can then be baked and edited as regular grease pencil lines.
Reviewed By: Sebastian Parborg, Antonio Vazquez, Matias Mendiola
Differential Revision: http://developer.blender.org/D8758
|
|
This concerns currently only collections (`master_collection` of scenes)
and root node trees. It removes the matching type-specific helpers
(`BKE_collection_master_scene_search` and `BKE_node_tree_find_owner_ID`).
No functional change expected here.
NOTE: Current implementation of `owner_get` is far from optimal, we
could probably do it better, see {T69169}.
NOTE: While it could also have it, shapekeys IDTypeInfo was left out of
this change for now. Mainly because it sould not be used currently, and
we ultimately want to demote shape keys from ID status anyway.
|
|
|
|
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.
|
|
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
|
|
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'.
|
|
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.
|
|
Would break on some systems/compilers...
|
|
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.
|
|
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: 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...
|
|
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...
|
|
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.
|
|
|
|
|
|
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.
|
|
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. :(
|
|
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
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
|
|
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
|
|
|
|
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.
|
|
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
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
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.
|
|
Done using:
source/tools/utils_maintenance/c_sort_blocks.py
|
|
|
|
Note we still have hardcoded IFACE_("Scene Collection") in the outliner.
I'm ok with getting of them as well, though no strong feelings here.
|
|
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3814
|
|
Because looping over the scene is unsafe and slow.
|
|
|
|
For physics simulation it's still fuzzy though, but this needs bigger
design for how it works with view layers and visibility.
|
|
This caused crashes in some cases, and should be fully handled by
the depsgraph now.
|
