This change fixes artifacts produced by these operations.
On a technical aspect this is done by porting all of the operations
to the new subdivision surface implementation which ensures that
tangent space used to evaluate modifier and those operations is
exactly the same (before modifier will use new code and the operations
will still use an old one).
The next step is to get sculpting on a non-top level to work, and
that actually requires fixes in the undo system.
- Split 'verify_fcurve' into two functions:
ED_action_fcurve_ensure which adds the f-curve if needed.
ED_action_fcurve_find which returns NULL when not found.
Callers of ED_action_fcurve_find had unused 'group'
argument which has been removed.
- Rename verify_adt_action to ED_id_action_ensure
It had an argument to add data which was always true,
remove this instead of splitting in into a separate function.
- Use 'BKE_object_material_*', 'BKE_id_material_*' prefix
for functions that operate on Object and ID types.
- Use '_len' suffix for length (matching BLI naming).
- Use '_p' suffix for functions that return a pointer to values
where the value would typically be returned.
Functions renamed:
- BKE_object_material_resize was BKE_material_resize_object
- BKE_object_material_remap was BKE_material_remap_object
- BKE_object_material_remap_calc was BKE_material_remap_object_calc
- BKE_object_material_array_p was BKE_object_material_array
- BKE_object_material_len_p was BKE_object_material_num
- BKE_id_material_array_p was BKE_id_material_array
- BKE_id_material_len_p was BKE_id_material_num
- BKE_id_material_resize was BKE_material_resize_id
- BKE_id_material_append was BKE_material_append_id
- BKE_id_material_pop was BKE_material_pop_id
- BKE_id_material_clear was BKE_material_clear_id
fails
Exposed by rB50d5c03e2d14.
This was only a problem when _only_ 'Object Data' was made local.
If also e.g. 'Object' or 'Materials' was checked, these were already
making sure realations were updated [DEG_relations_tag_update(bmain)].
Now also call DEG_relations_tag_update(bmain) for the 'Object Data'
case.
I assume the underlying issue is that there is some ID_NEW_REMAP
happening in 'single_obdata_users()' -- including that for 'me-
>texcomesh', which might be responsible for the glitches in selection/
editing? Also not entirely sure why this wasnt a problem prior to
rB50d5c03e2d14.(I assume this was somewhat hidden by the fact this was
always called with a default action being nothing, the user would always
need to access the redo panel. So this might have been hidden by an Undo
step involved?)
Maniphest Tasks: T73797
Differential Revision: https://developer.blender.org/D7020
Using a struct here allows to change given parameters to the callbacks
without having to edit all callbacks functions, which is always noisy
and time consuming.
This works on selected_editable_objects, so no active object mandatory.
After deletion of the active object and using slection tools such as
e.g. box select, the lack of an active object would prevent this
operator from being called without good reason.
Also cannot think of any other existing poll that would really make
sense (Editor type, ...).
ref T68975
Maniphest Tasks: T68975
Differential Revision: https://developer.blender.org/D6773
even when target is not a collection
Looks like this was (accidentally) removed in {rBbe9e469ead22}
https://developer.blender.org/
rBbe9e469ead227aee8d4c29b98a125cf599c5c8bb#change-pFg0VUTAHY2q
This could also result in a missing update in
object_handle_update_proxy, see T72083 for an example.
Thx @Macroni investigating!
Maniphest Tasks: T72083
Differential Revision: https://developer.blender.org/D6651
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
