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.
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
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.
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 fixes a threading issue (T73593) between drivers that write to the
same memory address. Driver nodes in the depsgraph now get relations to
each other in order to ensure serialisation.
These relations are only added between drivers that target the same
struct in RNA, which is determined by removing everything after the last
period. For example, a driver with data path
`pose.bones["Arm_L"].rotation_euler[2]` will be grouped with all other
drivers on that datablock with a data path that starts with
`pose.bones["Arm_L"]` to form a 'driver group'.
To find a suitable relation within such a driver group, say the relation
(from → to), a depth-first search is performed (turned out to be
marginally faster than a breadth-first in my test case) to see whether
this will create a cycle, and to see whether there already is such a
connection (direct or transitive). This is done by recursively
inspecting the incoming connections of the 'to' node and thereby walking
from it towards the 'from' node. This is an order of magnitde faster
than inspecting the outgoing connections of the 'from' node.
This approach generalises the special case for array properties, so the
code to support that special case has been removed from
`DepsgraphRelationBuilder::build_animdata_drivers()`.
A test on the Spring rig [1] shows that this process adds approximately
8% to the build time of the dependency graph. In my test case, it takes
28 ms for this process on a total 329 ms construction time. However,
since it also made some code obsolete, it only adds 24 ms (=8%) to the
construction time. I have experimented with a simple cache to keep track
of known-connected (from, to) node pairs, but this did not significantly
improve the timing.
Note that animation data and drivers are already connected by a
relation, which means that animating a field and also changing it with a
driver will not cause conflicts.
[1] https://cloud.blender.org/p/spring/5d30a1076249366fa1939cf1
Differential Revision: https://developer.blender.org/D6905
Reviewed By: sergey, mont29
This partially fixes T73593.
The `add_relation(driver_key, property_entry_key, ...);` call can fail
in the following situation:
- A collection is linked, and instanced into the scene by an Empty.
- The collection contains an object with a driver on its `hide_render` or
`hide_viewport` property.
As the object doesn't exist as a real object in the scene, it's added with
`base_index=-1` to the depsgraph (see `DepsgraphNodeBuilder::build_collection()`).
As a result the node for syncing the restrictflags back to the base
isn't present in the depsgraph, and the `add_relation()` call failed.
This commit fixes the warning, simply by not attempting to add the
offending relation.
This patch fixes {T73051}. The cause of the issue was the absence of
relations in the depsgraph between IK solvers of overlapping IK chains.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D6700
This dependency was removed in fd0bc7e002,
as there already were dependencies ANIMATION -> PARAMETERS and
PARAMETERS -> CACHE, making ANIMATION -> CACHE unnecessary.
Upon subsequent inspection, the ANIMATION -> PARAMETERS dependency was
there due to the fallback behaviour in
`RNANodeQuery::construct_node_identifier()`. Now this is no longer
relied upon, and the required relation is made explicit again.
The dependency graph has to know whether a driver must be re-evaluated
every frame due to a dependency on the current frame number. For python
drivers it was using a heuristic based on searching for certain sub-
strings in the expression, notably including '('.
When the expression is actually evaluated using Python, this can't be
easily improved; however if the Simple Expression evaluator is used,
this check can be done precisely by accessing the parsed data.
Differential Revision: https://developer.blender.org/D6624
When there are ID properties on an object, and these are animated and
used by a driver, the depsgraph has proper connections between ACTION →
ID PROPERTY → DRIVER.
When these properties are defined on a mesh, however, the depsgraph
relations are incorrectly created between GEOMETRY → PROPERTIES_EXIT →
DRIVER (because it's assumed that 'source = ENTRY' implies 'geometry').
This patch solves this by first checking whether the targeted property
is an ID property and handling it accordingly. This also made it
possible to remove some special cases from pose bone relations.
Maniphest Tasks: T73001
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D6571
FreeStyle line styles were not part of the dependency graph, and
blacklisted from the Copy-on-Write system. As a result, animated
FreeStyle properties would not be updated by the animation system,
resulting in T72213. There was an explicit call to run the animation
system on the original datablocks, but that was (for good reasons)
removed in D5394.
This commit adds the FreeStyleLineStyle datablocks to the dependency
graph and allows them to be handled by the CoW system. As a result
- the UI now updates properly when properties are animated, and
- animated property values are actually used when rendering.
This commit includes @Sergey's patch P1222, which unifies two bits of
code that did the same thing: check whether datablock type is covered by
copy-on-write.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D6609
Was caused by recent animation backup added to depsgraph as a part of
another bugfix.
This commit effectively disables the animation backup, restoring bug
related on handlers, but makes it possible to interact with objects
again.
Will re-iterate over handlers+animated properties.
It was possible to have object copy-on-write happening during
action's copy-on-write, which was causing access to a freed
memory from animation backup.
Solves crash reported in T73029.
Was caused by 6183688c35 (thanks ronsn for nailing it down!).
The issue is that order of copy-on-write operations is not defined, so
can not use flags set by that operation to make decision.
It is possible to have action which is not nullptr but which have no
f-curves in it (for example, animate cube's location, then delete all
f-curves).
Such situation should not add time dependency as it could slow down
scene evaluation on frame change.
This is something which worked in Blender 2.79.
Need to do special trickery to ensure peoxy_from points to a
proper object.
Differential Revision: https://developer.blender.org/D6040
This change is two-fold:
- Ensure the result of the F-Curve evaluation is stored on the FCurve
object. This was done in 2.79 but lost when we moved to more granular
per-curve evaluation from the depsgraph.
- Flush this result from the CoW copy back to the original.
Reviewed by: sergey
Differential Revision: https://developer.blender.org/D5888
time change
followup to 815ca2310f, this one fixes the RNA_MeshLoopColor case, adds
RNA_VertexGroupElement and RNA_LatticePoint.
coop with @sergey, thx.
Fixes T68666
