Solve O(n^2) time complexity problem where a dependency graph iterator loops
over all nodes to clear flags, which happened for every object at the start
of transform.
Differential Revision: https://developer.blender.org/D7503
issue: Painting a texture that is set as a particle system influencer, doesn't
update particles. An external trigger (such as changing influence slider)
is required to update particles.
fix: The root cause is a missing relationship from image to texture in the
dependency graph.
test: Once fixed, image texture painting updates expected dependencies
such as particle system influence or displacement modifier.
Reviewed By: sergey
Maniphest Tasks: T75845
Differential Revision: https://developer.blender.org/D7472
This data block will be the container for simulation node trees.
It will be used for the new particle node system (T73324).
The new data block has the type `ID_SIM`.
It is not visible to users and other developers by default yet.
To enable it, activate the cmake option `WITH_NEW_SIMULATION_TYPE`.
New simulation data blocks can be created by running `bpy.data.simulations.new("name")`.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7225
Scene audio volume changes require the scene to be tagged with
`ID_RECALC_AUDIO_VOLUME` (see `BKE_scene_update_sound()`). Tagging
happens in the RNA update function `rna_Scene_volume_update()`, but that
function is not called by the animation system. As a result, animated
volume changes are not sent to the audio system.
This commit adds a new depsgraph operation node that sets this tag when
necessary, so that the animated values are used in the rest of the
depsgraph evaluation.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D7429
The problem was that in direct_link_id_restore_recalc, recalc_undo_accumulated
should contain the changes from the target state to the current state. However
it had already been cleared at that point, to start accumulating changes up to
the next undo push.
Delaying the clear of this flag seems like the obvious solution, but it's hard
to find the right place for that (if there is one). Instead this splits up the
flag into two separate variables.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D7402
The issue was that the deps graph relation builder assumed that all
bones that had a IK constraint on them would be evaluated. However for
targetless IK bones, only the active bone would receive updates and the
others would be skipped (as those would be treated as if the IK
constraint was disabled).
I didn't see an easy way to solve this from the depsgraph side of
things.
Instead I came up with a solution that I feel is quite strait forward
and reflects what is actually supposed to happen under the hood.
Now all targetless IK constraints are treated as disabled and will not
be added to any relations in the depsgraph.
Instead, a temporary IK constraint will be created when the bone in
question is transformed. This is basically activating "Auto IK" for the
bone while transforming.
Reviewed By: Sergey, Brecht
Differential Revision: http://developer.blender.org/D7378
Tasks: move priority from task to task pool {rBf7c18df4f599fe39ffc914e645e504fcdbee8636}
Tasks: split task.c into task_pool.cc and task_iterator.c {rB4ada1d267749931ca934a74b14a82479bcaa92e0}
Differential Revision: https://developer.blender.org/D7385
These changes only have an effect when the experimental Undo Speedup preference
is enabled.
* For DEG_id_tag_update, accumulate recalc flags immediately before the undo
push happens instead of afterwards. Otherwise the undo state does not
contain enough flags, and the current state may contain too many flags.
This also means we call DEG_id_tag_update after undo with the accumulated
flags to ensure they are flushed to other datablocks.
* For undo, accumulate recalc flags in id->recalc and clear accumulated flags
immediately. Not clearing would cause circular behavior where accumulated
flags may never end up being cleared.
This matches what happens after an undo push where these are also cleared,
indicating that the undo state and current in-memory state match exactly.
* Don't change id->recalc of identical datablocks, it should not be needed.
There is one exception for armatures where pointers across datablocks
exist which otherwise would cause problems. There may be a better solution
to this but it seems to work in agent 327 production files.
* This contains a change in undofile.c to avoid detecting all datablocks as
changed for the first of the two undo steps, where we restore to the state
of the last undo push before going to the one before.
Without this the whole system is much less efficient. However this is unsafe
in the sense that if an app handler or operators edits a datablock after an
undo push, that change will not be undone.
It can be argued that this is acceptable behavior, since a following undo push
will include that change and this may already have unexpected side effects.
Ref T60695
Differential Revision: https://developer.blender.org/D7339
The `BKE_animsys.h` and `anim_sys.c` files already had a an "AnimData
API" section. The code in that section has now been split off, and
placed into `BKE_anim_data.h` and `anim_data.c`.
All files that used to include `BKE_animsys.h` have been adjusted to
only include the animation headers they need (sometimes none).
No functional changes.
The files are now split up into the following sections:
- `BKE_anim_path.h` and `anim_path.c` for path/curve functions.
- `BKE_anim_visualization.h` and `anim_visualizationanim_path.c` for
animation visualization (mostly motion paths).
- `BKE_duplilist.h` for DupliList function declarations. These were
already implemented in `object_dupli.c`, so they were rather out of
place being declared in `BKE_anim.h` in the first place.
No functional changes.
The root cause of the issue reported in T74983 is that an `IDNode` would
not be marked as user-modified. This marking happened while looping over
outgoing relations of one of its operation nodes. Since rBff60dd8b18ed
unused relations are removed, and as a result the `IDNode` would not be
marked.
The solution was to move the responsible code outside the loop; this is
probably a good idea anyway, as the code did not actually use the
looped-over relations at all, and was thus repeated unnecessarily.
More detailed symptoms: there was no curve cache created for an object
which was used by draw manager.
A bit tricky situation, which involves collection instances and their
proxies.
The root of the problem in the dependency graph was that instanced
collections visibility was not updated when object is requested with
different visibility. So what was happening is that one of the objects
was pulled as an indirect dependency of something invisible, so it
built instanced collections as if the instancer is invisible. After
that the same object was built as visible. Before this fix this was
only update object flags, the instanced collections still believed they
are invisible. Since there is no path via relations which would connect
visible object with instanced objects the visibility flush which is
happening during graph finalization did not "fix" the visibility flags.
This change makes it so instanced collections are updating their
visibility when their instancer's visibility is changing to truth.
This is similar to how collections will accumulate their visibility
when same collection is used from multiple ones with different
visibility.
However, this alone wasn't enough to get crash fixed. This marked
collections as visible, but the geometry component of the curve object
was still considering self as invisible.
This is something tricky, since the code which is responsible for this
issue was added as an optimization in afb4da6650. This looks like like
an oversight in that commit since it's rather weird that ID node's
flag would depend on construction order (in "normal" object builder the
ID node's directly_visible flag is initialized to object's visibility).
So it seems logical to get this part of code in sync between "regular"
and "accumulative" object builder.
And last but not least the naming is_directly_visible is old and does
not really represent what it actually mans now: a more correct name
would be "will be used by the draw manager".
Differential Revision: https://developer.blender.org/D7217
The `build_driver_relations()` function in the depsgraph relations builder
adds relations between drivers that potentially write to the same memory
location. This of course is only useful when there are two or more drivers.
Started to happen after recent fix for T72632.
Was caused by runtime fields backup doing an early exit in the case the
given ID was never expanded by the Copy-on-Write mechanism, but it was
not done int the backup restore function (since it was not possible to
know "locally").
Now both init() and restore() will do an early exit when the ID had
nothing to be backed up.
Mpving utils from idcode to idtype proved to be somewhat painful for
some reasons, but now all looks good.
Had to add a fake/empty shell for the special snowflake too,
`ID_LINK_PLACEHOLDER/INDEX_ID_NULL`...
Both scaling the text itself, as well as scaling the curve wasnt
updating, now added relations for this.
Maniphest Tasks: T74701
Differential Revision: https://developer.blender.org/D7140
The parenting was using the old logic, but with new engine the draw is done using eval data.
Fixed the depsgraph relationship missing with bones to get an update when the bone is transformed.
Also fixed Snap cursor to Selected
Extract will steal all depsgraphs currently stored in given bmain, and
restore will put them back in place, using scene and viewlayers as keys.
Preliminary work for undo-speedup.
Part of T60695/D6580.
Was happening when having compositor open with Viewer node attached
directly to Render Layers output.
There were two things involved here:
1. The code which was storing CoW-ed versions of IDs was checking all
IDs for whether they are expanded or not. This was causing access
of freed memory for deleted IDs which do not need CoW (such as IM).
Simple fix: store ID type as a scalar and use early check before
doing more elaborate check based on accessing fields of id_cow.
2. The code which was ensuring view layer pointer is doing CoW for
scene. This isn't an issue on its own, but scene might have an
embedded ID such as compositor which was actually traversed by the
ID remap routines. This was causing remapping procedure to go into
non-updated copy of compositor, accessing freed Viewer image ID.
Solved by not recursing into embedded IDs for datablocks as those
are supposed to have own copy-on-write operations which takes care
of re-mapping.
Reported my Bastien, and also pair-coded with him.
We implement cubemap array support for EEVEE's lightcache reflection probes.
This removes stretched texels and bottom hemisphere seams artifacts caused
by the octahedral projection previously used.
This introduce versioning code for the lightcache which will discard any
lightcache version that is not compatible.
Differential Revision: https://developer.blender.org/D7066
This commit is a full refactor of the grease pencil modules including Draw Engine, Modifiers, VFX, depsgraph update, improvements in operators and conversion of Sculpt and Weight paint tools to real brushes.
Also, a huge code cleanup has been done at all levels.
Thanks to @fclem for his work and yo @pepeland and @mendio for the testing and help in the development.
Differential Revision: https://developer.blender.org/D6293
Unused no-op operation nodes are not bound to a callback function, and
have no outgoing relations. Incoming relations of such nodes are removed
since ff60dd8b18. However, this was done
too broadly, causing too many relations to be lost and indirectly linked
objects to be unevaluated.
This commit introduces a `DEPSOP_FLAG_FAKE_USER` flag for operation
nodes, which indicates they are not to be removed, even when they appear
to be unused.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D7074
This is the companion of D7031. That patch adds a new DIMENSIONS node to
the depsgraph for each object that has geometry. However, this node is
only necessary when there are drivers using an object's dimensions as
variable. Since this is rare, it's easiest to remove these nodes after
they turn out to be unnecessary. This is what (almost) happens in this
patch.
Removing nodes from the depsgraph is hard, and there are no functions to
do this yet. Instead, this patch recursively removes all the incoming
relations from unused no-op nodes (i.e. no-op operation nodes without
outgoing connections). Actually removing the nodes will be left as a
future improvement.
I've tested this on a Spring file [1]. Here are there results of blender
--debug-depsgraph-time spring_02_055_A.eevee.blend and letting it run
for a while to stabilise the reported FPS:
master: 11.7 FPS
Just D7031: 11.7 FPS
Just D7033: 11.8 FPS
Both D7031 + D7033: 12.3 FPS
[1] https://cloud.blender.org/p/spring/5d30a1076249366fa1939cf1
Differential Revision: https://developer.blender.org/D7033
This fixes an issue where drivers using `object.dimension` only add a dependency on `GEOMETRY` to the depsgraph, whereas they should also depend on `TRANSFORM`.
This patch adds a new no-op operation that depends on the geometry and transform components to the Parameters component.
An alternative implementation would be to have `RNANodeQuery::construct_node_identifier` return multiple node identifiers. However, this would spread throughout the depsgraph code and unnecessarily force many other functions to either return or handle multiple nodes where in 99.999% of the time a single node would suffice.
The new `DIMENSIONS` node is added for each object. An upcoming patch will go over all no-op operation nodes and remove them from the depsgraph. Since this is a more dangerous operation, it'll be reviewed separately.
Differential Revision: https://developer.blender.org/D7031
Since `std::deque` is used in a few areas of the Depsgraph, and an
upcoming patch adds one more, it's time it's considered as "commonly
used type".
No functional changes.
- 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
This is in preparation of new object types. This only changes mesh_eval, we
may do the same for mesh_deform_eval and other areas in the future if there is
a need for it.
This previously caused a bug in T74283, that should be fixed now.
Differential Revision: https://developer.blender.org/D6695
This reverts commit f2b95b9eae.
Fix T74283: modifier display lost when moving object in edit mode.
The cause is not immediately obvious so better to revert and look at this
carefully.
This is in preparation of new object types. This only changes mesh_eval, we
may do the same for mesh_deform_eval and other areas in the future if there is
a need for it.
Differential Revision: https://developer.blender.org/D6695