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...
Simplify a bit, and remove some now redundant remappings.
As a side note, rBac723db57fd8ba5 actually also fixed some unreported
issues (missing remappings to new objects/collections in new copied
scene, that were not previously handled by the 'custom' code).
There are almost certainly still some missing remappings around,
though...
rBac723db57fd8ba5 makes proper remapping of all pointers in Scene...
including the object pointers of bases in ViewLayers.
Using `BKE_main_collection_sync_remap()` makes sense here anyway
(compared to `BKE_main_collection_sync()`, it additionally clears caches
in ViewLayers and Collections), this whole code makes a lot of
remapping.
Note that I do not really understand *why* that was working OK
before rBac723db57fd8ba5. I.E. *why* not remapping at all ViewLayers'
base object pointers seemed to be OK...
This whole collection/viewlayer caching is very hard to follow, and
really needs a full rework at some point (just as much as ID copying
code in general, and scene copying code in particular, in fact).
Never treat one of those horrorible 'IDs that are not real IDs' as
regular ID, and expect ID management code to do so. Unless there is a
very good reason, one should never explicitely pass those fake IDs to ID
management code directly.
In that specific case, user count is sort of 'disabled' in libquery
code, because master collections are not in bmain (`LIB_TAG_NO_MAIN`).
The core of the issue here is that 'make single user' functions still
does its own, manual and quite partial, remapping of IDs, which covers
all most common cases but cannot consider *all* possible ID usages
(especially when it comes to drivers or custom properties, that can
essentially point to any kind of data-blocks).
This fix is merely a band-aid, there is no way to fully solve this
without a complete rewrite of that area of code to make use of modern ID
management code.
That's exactly why we should get rid of all those 'custom cases'
remapping code, it's hard enough to keep a single place
(library_query.c) up to date and 100% valid, but having more areas doing
their own remapping is just impossible to maintain... Some day...
Similar change to the one done for tagged IDs overriding some days ago.
We do not always want to remap all local usages of a linked data-block
to its new local overriding copy.
* `make_override_library_exec` was not properly cleaning `LIB_TAG_DOIT`
from all IDs in the Main DB.
* `BKE_override_library_create_from_tag` was doing dangerous things
(like iterating over a BMain listbase while adding items to it...).
* It would remap *all* local usages of overridden linked IDs to new
overriding local IDs, which was very inconvinient.
New handling of remapping now allows to only remap inside of the group
of IDs that is being overridden, in other words you can still have e.g.
other empties still instancing the same linked collection...
The old layout of `PointerRNA` was confusing for historic reasons:
```
typedef struct PointerRNA {
struct {
void *data;
} id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
This patch updates it to:
```
typedef struct PointerRNA {
struct ID *owner_id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
Throughout the code base `id.data` was replaced with `owner_id`.
Furthermore, many explicit pointer type casts were added which
were implicit before. Some type casts to `ID *` were removed.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D5558
This change ensures that operators which needs access to evaluated data
first makes sure there is a dependency graph.
Other accesses to the dependency graph made it more explicit about
whether they just need a valid dependency graph pointer or whether they
expect the graph to be already evaluated.
This replaces OPTYPE_USE_EVAL_DATA which is now removed.
Some general rules about usage of accessors:
- Drawing is expected to happen from a fully evaluated dependency graph.
There is now a function to access it, which will in the future control
that dependency graph is actually evaluated.
This check is not yet done because there are some things to be taken
care about first: for example, post-update hooks might leave scene in
a state where something is still tagged for update.
- All operators which needs to access evaluated state must use
CTX_data_ensure_evaluated_depsgraph().
This function replaces OPTYPE_USE_EVAL_DATA.
The call is generally to be done in the very beginning of the
operator, prior other logic (unless this is some comprehensive
operator which might or might not need access to an evaluated state).
This call is never to be used from a loop.
If some utility function requires evaluated state of dependency graph
the graph is to be passed as an explicit argument. This way it is
clear that no evaluation happens in a loop or something like this.
- All cases which needs to know dependency graph pointer, but which
doesn't want to actually evaluate it can use old-style function
CTX_data_depsgraph_pointer(), assuming that underlying code will
ensure dependency graph is evaluated prior to accessing it.
- The new functions are replacing OPTYPE_USE_EVAL_DATA, so now it is
explicit and local about where dependency graph is being ensured.
This commit also contains some fixes of wrong usage of evaluation
functions on original objects. Ideally should be split out, but in
reality with all the APIs being renamed is quite tricky.
Fixes T67454: Blender crash on rapid undo and select
Speculation here is that sometimes undo and selection operators are
sometimes handled in the same event loop iteration, which leaves
non-evaluated dependency graph.
Fixes T67973: Crash on Fix Deforms operator
Fixes T67902: Crash when undo a loop cut
Reviewers: brecht
Reviewed By: brecht
Subscribers: lichtwerk
Maniphest Tasks: T67454
Differential Revision: https://developer.blender.org/D5343
Better to make internal code naming match official/UI naming to some
extent, this will reduce confusion in the future.
This is 'breaking' scripts and files that would use that feature, but
since it is not yet officially supported nor exposed in 2.80, as far
as that release is concerned, it is effectively
a 'no functional changes' commit.
Note that there are probably many other similar cases... This code is
really legacy, should use library_query helpers and other modern
BKE_library code instead of doing its own dirty cooking...
This is old logic that no longer makes sense in the new depsgraph, and causes
issues when multiple threads try to modify the same bevel object.
Differential Revision: https://developer.blender.org/D4913
Caused by own recent rB17c15798c35f33e (already a fix in that code).
We cannot erase immediately master_collection's childrn list, as it is
used in sub-code to check in how many scenes an object is instanciated.
Further more, we only want to do the remove old/add new children
collections in case we are actually duplicating them.
Makes me even more eager to nuke that whole piece of code and rethink
from scratch that kind of ID handling. Some day...
Issue was that (deep) duplication code of scene ended up leaving
children collections of new master one without any parent.
Note that even though I think that fix is OK for now, we should really
make 'deep' duplication of IDs part of the generic ID management code.
Am less and less happy with current handling of this, done half from
/editors code, half from some semi-specialized helpers from /blenkernel,
with sometimes nearly the same logic replicated several times for
slightly different needs, etc. Unfortunately this would not be a small
refactor, so it will have to wait...
for objects other than Empties
In 2.8 support for dupli-group instancing for non-empty objects was
removed (rB2eca054e14b1), so better prevent operators from setting
this...
Reviewers: brecht
Maniphest Tasks: T63004
Differential Revision: https://developer.blender.org/D4599
Issue would happen in case affected object is linked to collections that
are shared between different scenes' ViewLayers. When switching back to
another scene after making single user, you'd get immediate crash.
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
Similar to T60623 / rB2894e75121d7.
Issue (when parenting with 'Follow Curve') is that the curves
CU_FOLLOW flag is set on the original, but not the
evaluated curve (yet), leading to misbehaviour in 'ob_parcurve()'.
Setting this on both now.
Reviewers: sergey
Maniphest Tasks: T62601
Differential Revision: https://developer.blender.org/D4524
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.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
This reverts part of rBbc5482337669.
Problem with above commit is that the evaluated object seems to not have
partype, par1, par2, par3 copied from the original (yet). Using original
object instead now.
Second issue (when parenting to 'Bone Relative') is that the bones
BONE_RELATIVE_PARENTING flag is set on the original, but not the
evaluated bone (yet), setting this on both now.
Fixes T60623 (and part of T59352)
Reviewers: brecht, sergey
Maniphest Tasks: T60623
Differential Revision: https://developer.blender.org/D4309
