Avoid computationally expensive copying operations
when only some settings have been modified.
This is done by adding support for updating parameters
without tagging for copy-on-write.
Currently only mesh data blocks are supported,
other data-blocks can be added individually.
This prepares for changing values such as edit-mesh auto-smooth angle
in edit-mode without duplicating all mesh-data.
The benefit will only be seen when the user interface no longer tags
all ID's for copy on write updates.
ID_RECALC_GEOMETRY_ALL_MODES has been added to support situations
where non edit-mode geometry is modified in edit-mode.
While this isn't something user are likely to do,
Python scripts may change the underlying mesh.
Reviewed By: sergey
Ref D11377
Would crash when adding or removing a collection directly to the master
collection of a scene.
Consequence of change to handle depsgraph-controlled evaluation of some
IDs (like excluded collections which do not get evaluated and do not get
a COW anymore). See rBcf4258673755 and D10907.
Note that this mostly demonstrates once again how weak and flacky our
handling of embedded IDs still remains, with some part of the code
handling them as independent IDs, some as fully local/private data, some
as a mix of both... and lots and lots of custom handling code and corner
cases that are a bottomless pit of issues.
Also quiet incredible that this was not reported already, luckily this
original change did not make it to 2.93 release.
Root of the issue was actually hidden deep in depsgraph itself: it would
not properly update all of its COW IDs using a datablock when depsgraph
decides to evaluate or un-evaluate it.
This would lead to evaluated IDs pointing to either:
- orig IDs when there was an evaluated version of those (annoying bug,
but not a crashing one).
- old address of previously evaluated IDs that no longer exists in the
depsgraph (causing the crash from the report e.g.).
This commit adds an extra step at the end of nodes building, that goes
over all of already existing IDs in the depsgraph to check whether they
do one of the two things above, and tag them for COW update if so.
NOTE: This only affects depsgraph (re-)building, not its evaluation.
This remains consistent with the fact that operations that may change
the depsgraph content (like Collection exclusion etc.) need to trigger a
rebuild.
NOTE: Performances: Worst case scenarii, like (un-)excluding a whole
character collection in a production file, lead to 5% to 10% extra
processing time in depsgraph building. Most of it comming from extra COW
processing (in depsgraph's update in `build_step_finalize`), the detection
loop itself only accounts for 1% to 2% of the whole building time.
Maniphest Tasks: T85752
Differential Revision: https://developer.blender.org/D10907
The sockets are not exposed in any nodes yet.
They work similar to the Object/Collection sockets, which also
just reference a data block.
This is part of D11222.
This fixes T87666 and T83252.
The boolean modifier and geometry nodes can depend on the geometry
of an entire collection. Before, the modifiers had to manually create relations
to all the objects in the collection. This worked for the most part, but was
cumbersome and did not solve all issues. For example, the modifiers were not
properly updated when objects were added/removed from the referenced collection.
This commit introduces the concept of "collection geometry" in the depsgraph.
The geometry of a collection depends on the transforms and geometry of all
the objects in it. The boolean modifier and geometry nodes can now just depend
on the collection geometry instead of creating all the dependencies themselves.
Differential Revision: https://developer.blender.org/D11053
Make the SHADING_PARAMETERS operation on node tree a real no-op.
The function used as a callback was only doing a debug print.
The issue with this function was that an original ID was passed
as an argument. This is a violation of design, and if anything it
should be left up to the implementation to check whether depsgraph
is active.
There are no functional changes for users in the interface. The
only difference is that the debug print will no longer happen.
This change removes copy-on-write operations from ID nodes which do not
need copy-on-write.
Should be no functional changes, as before the copy-on-write operation
would do nothing for those nodes anyway.
Building IDs which are not covered by copy-on-write process was not
implemented, which was causing parameters block not present, and, hence
causing crashes in areas which expected parameters to present.
First part of this change is related on making it so Copy-on-Write is
optional for ID nodes in the dependency graph.
Second part is related on using a generic builder for all ID types
which were not covered by Copy-on-Write before.
The final part is related on making it so build_id() is properly
handling ParticleSettings and Grease Pencil Data. Before they were not
covered there at all, and they need special handling because they do
have own build functions.
Not sure it worth trying to split those parts, as they are related to
each other and are not really possible to be tested standalone. Open
for a second opinion though.
Possible nut-tightening is to re-organize build_id() function so
that every branch does return and have an assert at the end, so that
missing ID type in the switch statement is easier to spot even when
using compilers which do not report missing switch cases.
As for question "why not use default" the answer is: to make it more
explicit and clear what is a decision when adding new ID types. We do
not want to quietly fall-back to a non-copy-on-write case for a newly
added ID types.
Differential Revision: https://developer.blender.org/D10075
If a force field was of type "Texture", any changes of that texture (e.g.
its type - as reported in T85139 - or also its properties) were not
properly updating rigid bodies and particle systems.
Now ensure that texture is actually in the depsgraph and set up relation
accordingly.
Also fixes T75198.
Maniphest Tasks: T85139
Differential Revision: https://developer.blender.org/D10234
This reverts commit 76fd41e9db. This should have
been reverted along with 0f95f51361, since this
change by itself is causing crashes when the depsgraph accesses a non-existent
copy-on-write component.
Ref T84717
Revert "Fix T83411: Crash when using a workspace/layout data path in a driver"
The fix for the crash exposed design violation in the viewport shading updates,
which is for some reason relying on dependency graph tag of interface data.
The viewport module did not respond to the issue in 2 weeks, and the architect
considered missing update for multiple users a more serious issue than a crash
in a very specific case.
This reverts commit 0f95f51361.
This change removes copy-on-write operations from ID nodes which do not
need copy-on-write.
Should be no functional changes, as before the copy-on-write operation
would do nothing for those nodes anyway.
Building IDs which are not covered by copy-on-write process was not
implemented, which was causing parameters block not present, and, hence
causing crashes in areas which expected parameters to present.
First part of this change is related on making it so Copy-on-Write is
optional for ID nodes in the dependency graph.
Second part is related on using a generic builder for all ID types
which were not covered by Copy-on-Write before.
The final part is related on making it so build_id() is properly
handling ParticleSettings and Grease Pencil Data. Before they were not
covered there at all, and they need special handling because they do
have own build functions.
Not sure it worth trying to split those parts, as they are related to
each other and are not really possible to be tested standalone. Open
for a second opinion though.
Possible nut-tightening is to re-organize build_id() function so
that every branch does return and have an assert at the end, so that
missing ID type in the switch statement is easier to spot even when
using compilers which do not report missing switch cases.
As for question "why not use default" the answer is: to make it more
explicit and clear what is a decision when adding new ID types. We do
not want to quietly fall-back to a non-copy-on-write case for a newly
added ID types.
Differential Revision: https://developer.blender.org/D10075
The root of the issue was caused by the dependency graph using ID pointer
to map evaluated state from old depsgraph to new one upon relations update.
This was failing when IDs were re-allocated rapidly: was possible that
Object ID's evaluated state assigned to Mesh and vice versa.
Now depsgraph uses Session UUID to identify which IDs to restore evaluated
state to. The session UUID is stored in the IDNode, so that id_orig is not
dereferenced on depsgraph update since the ID might be freed.
The root of the issue is identified by Campbell, original patch was done
by Bastien, thanks! Also thanks to Oliver and Ray and everyone else for
testing!
The implementation is pretty much the same as for Object sockets.
The socket color is the one that is used for collections in the outliner.
Part of D9739.
Modernize loops by using the `for(type variable : container)` syntax.
Some loops were trivial to fix, whereas others required more attention
to avoid semantic changes. I couldn't address all old-style loops, so
this commit doesn't enable the `modernize-loop-convert` rule.
Although Clang-Tidy's auto-fixer prefers to use `auto` for the loop
variable declaration, I made as many declarations as possible explicit.
To me this increases local readability, as you don't need to fully
understand the container in order to understand the loop variable type.
No functional changes.
Because depsgraph isn't rebuild for animated properies, we have to
assume that active bodies will always want to have updates from the
rigidbody simulation.
We need to have transforms from passive objects if they are animated or
driven by parent relations. This is not immediately obvious as the
object transform matrix will still be available, it is just one frame
behind in some cases.
Fixed dependency cycles if there is a constraint between two rigid
bodies. Because bullet keeps track of its simulated bodies, we do not
need to supply objects transforms as bullet should already have them.
I need combine these two fixes because otherwise we will get depsgraph
warnings that nodes are missing that it expects to be there.
Reviewed By: Sergey, Jacques
Differential Revision: http://developer.blender.org/D8732
A simulation data block has an embedded node tree, which requires
special handling in a couple of places. Some of those places were
missing beforehand.
This also adds a relation to make sure that the simulation is evaluated
after animations on the embedded node tree are evaluated.
Having a sound strip in the VSE caused a missing relation error to be
logged on the console. This was caused by the AUDIO depsgraph component
not having an entry node. This commits adds that node, and sets up
relations correctly.
Differential Revision: https://developer.blender.org/D8290
Reviewed By: Sergey
A driver reading `Object.hide_viewport` would break when that object was
hidden. Hidden objects don't have the `OBJECT_BASE_FLAGS` node in the
depsgraph, but that node was required for the driver to work.
Now the `OBJECT_FROM_LAYER` component (which optionally contains the
`OBJECT_FROM_LAYER` node) has explicit `ENTRY` and `EXIT` nodes, which
are used for relations with other components. These relations now remain
valid, even when the `OBJECT_FROM_LAYER` node is absent.
Differential Revision: https://developer.blender.org/D8124
Reviewed By: sergey
This reverts commit baa0da3e69.
The commit causes some issues I didn't foresee, I'd rather take the time
to do it properly than hastily try and commit a fix for it.
An object can be targeted by a driver that reads its `hide_viewport` or
`hide_render` property. The existence of such a driver will create a
relation between the 'sync base flags' depsgrpah node, and the datablock
containing the driver. When the object is hidden, however, it has no
base, and thus it had no 'sync base flags' depsgraph node. To support
such a driver, that depsgraph node is now always added, but for hidden
objects it will just be a no-op. If the node is not used by anything, it
will be automatically disconnected and have a negligible effect on
performance.
It turns out that
`DepsgraphNodeBuilder::build_object_data_geometry(Object *object, bool
is_object_visible)` was called for the custom shape with
`is_object_visible=false` when there are drivers, and
`is_object_visible=true` when there aren't any.
We decided that `blender::Vector` should be the default choice for
a vector data structure in Blender.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7981
It was causing wrong binding for image animation: since there was no
ID node for texture at the moment of build_animdata original texture
ID was passed to the callback. This is not what is supposed to happen.
This is part of fix for T65889.
Lamps were not tagged with `ID_RECALC_SHADING` when they were updated
from drivers. As a result, Cycles considered the lamp as unchanged. This
is resolved by having a (seemingly non-functional) callback in a new
`LIGHT_UPDATE` depsgraph node.
This patch unconditionally adds the `LIGHT_UPDATE` node + the relation
from the lamp's PARAMETERS node.
Differential Revision: https://developer.blender.org/D7822
Reviewed by: brecht
From what I can see, there are two issues at play in {T76689} and its merged-in report {T76590}:
- In Blender ≤ 2.79 the bone layer dots were updated in the draw code. This ensured the info was up to date before drawing. This is no longer possible, as the drawing code uses evaluated objects, and those should not be written to. This has been addressed in rB709f126e8143 by calling the update function explicitly in various places in the code. The problem is that this wasn't added to all necessary spots.
- When in edit mode, changes are made to the edit bones but not to the 'actual' bones (this is synced when exiting edit mode). This causes undo to mess up the layer indicators.
I think both issues can be addressed by having the dependency graph update the used layer info as part of the armature evaluation. This will make the undo system work properly, and allows the removal of some `BKE_armature_refresh_layer_used()` from various places.
There is still the issue that there are two functions (`BKE_armature_refresh_layer_used()` and `ED_armature_edit_refresh_layer_used()`) that are both responsible for updating `bArmature::layer_used`. This is a trickier thing to solve, though, as the definition of the `EditBone` struct resides in the armature editor module. This means that blenkernel can't iterate over edit bones, but on the other hand the dependency graph shouldn't call any editor functions either. This is why I left the `ED_armature_edit_refresh_layer_used()` calls untouched.
The downside of recalculating `layer_used` from the dependency graph (at least in the way that I did it now) is that it is called every time a user moves a bone in pose mode. This frequency of updates is not necessary.
Differential Revision: https://developer.blender.org/D7709
For now the "Simulation" modifier only exists for point cloud objects, because
we need this for the particle system. Right now, the modifier is doing nothing.
There is a new `DEG_add_simulation_relation` function that is used
by the modifier to make sure that the simulation is evaluated before
the modifier is executed.
Reviewers: brecht, sergey
Differential Revision: https://developer.blender.org/D7549
