Happens after recent changes in the area.
The asserts were a bit too strict and were against the way how the
ID_RECALC_ALL is handled. So remove them with explanation why things
needs to be silent.
The tagging code was iterating over bits set in the ID_RECALC_ALL and
was casting the flag to IDRecalcFlag. This was triggering an undefined
behavior warning in Clang since the bit might not have a corresponding
value in the enumerator.
The solution is to pre-define all reacalc flags for all bits. While
this seems a bit annoying this seems to be the least fragile solution
from all suggested ones.
Differential Revision: https://developer.blender.org/D15602
Always use unsigned int for the recalc flags. This allows to use
all 32 bit of integer for the flags without worrying about the
sign. Use full notation of `unsigned int` instead of short `uint`
to avoid pulling more headers in.
Whenever depsgraph API allows passing combined recalc flags call
the variable `flags` and use `unsigned int` type for it. For a
single flag use `IDRecalcFlag` flag.
No functional changes expected.
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
A mistake in the 0dcee6a386 which made specific driven visibility
to work, but did not properly handle actual time-based visibility.
The basic idea of the change is to preserve recalculation flags of
nodes which were tagged for update but were not evaluated due to
visibility constraints. In the file from the report this makes it
so tagging which is done first time ID is in the dependency graph
are handled when the ID actually becomes visible. This is what
solved the root of the problem from the report: there was missing
geometry update since it was "swallowed" by the evaluation during
the object being invisible. In other configurations this change
allows to handle pending geometry updates due to animated modifiers
be handled when object becomes visible without time change.
This change also solves visibility issue of the synchronization
component which also started to be handled badly since the
previous fix attempt. Basically, the needed exception in its
visibility handling did not happen and a regular logic was used
for it.
Tested with files from the T99733, T99976, and from the Heist
project.
Differential Revision: https://developer.blender.org/D15544
The issue was caused by the fact that objects with driven or animated
visibility were considered visible by the dependency graph evaluation.
This change makes it so the dependency graph evaluation is aware of
visibility which might be changing. This is achieved by evaluating the
path of the graph which affects objects visibility and adjusts to it
before evaluating the rest of the graph.
There is some time penalty to this, but there does not seem to be a
way to fully avoid this penalty.
With the production shot from the heist project the FPS drops by a
tenth of a frame (~9.4 vs ~9.3 fps) when adding a driver to an object
which keeps it visible. Note that this is a bit hard to measure since
the FPS fluctuates quite a bit throughout the playback. On the other
hand, having a driver on a visibility of a heavy object from character
and setting visibility to false gives big speedup.
Also worth noting that there is no penalty at all when there are no
animated visibilities in the scene.
Differential Revision: https://developer.blender.org/D15498
The goal is to make it possible to evaluate the graph in multiple
passes without evaluating the same node multiple times.
Currently should not be any functional changes.
Semantically it is more correct as the cache does not modify the ID.
There is need to do couple of const casts since the BKE (which is in C)
does not easily allow to iterate into f-curves of const ID.
Should be no functional changes.
Not sure why multiple pools were created: the pool should be able to
handle two sets of tasks.
Perhaps non-measurable improvement in terms of performance but this
change simplifies code a bit.
This is useful when using an armature as a camera rig, to avoid creating and
targetting an empty object.
Differential Revision: https://developer.blender.org/D7012
Even if the driver is not dependent on time the modifiers were always
re-evaluated during playback. This is due to the legacy nature of the
check whether modifier depends on time or not: it was simply checking
for sub-string match for modifier in the F-Curve and drivers RNA paths.
Nowadays such dependencies are created by the dependency graph builder,
which allows to have more granular control over what depends on what.
The code is now simplified to only check for "static" dependency of the
modifier form time: for example, Wave modifier which always depends on
time (even without explicit animation involved).
This change also fixes missing relation from the animation component to
the shader_fx modifiers, fixing race condition.
Additional files used to verify relations:
- Geometry: F13257368
- Grease Pencil: F13257369
- Shader FX: F13257370
In these files different types of modifiers have an animated property,
and the purpose of the test is to verify that the modifiers do react
to the animation and that there is a relation between animation and
geometry components of the object. The latter one can only be checked
using the dependency graph relation visualization.
The drivers are not tested by these files. Those are not typically
depend on time, and if there were missing relation from driver to
the modifier we'd receive a bug report already. As well as if there
was a bug in missing time relation to a driver we'd also receive a
report.
Differential Revision: https://developer.blender.org/D15358
Active camera is a property of Scene, so need to take scene changes into
account for such drivers to work reliably.
The fix covers all the common cases of such configurations, but some of
them might not be yet fully supported. Mainly cases when the target ID
is not covered by the copy-on-write mechanism.
There is a fuller explanation available in the code for the ease of reading
by the future generations.
Differential Revision: https://developer.blender.org/D15146
Instead of directly accessing constraint-specific callbacks
in code all over blender, introduce two wrappers to retrieve
and free the target list.
This incidentally revealed a place within the Collada exporter
in BCAnimationSampler.cpp that didn't clean up after retrieving
the targets, resulting in a small memory leak. Fixing this should
be the only functional change in this commit.
This was split off from D9732.
Differential Revision: https://developer.blender.org/D13844
`bNodeTree` has a lot of run-time embedded in it currently. Having a separately
allocated run-time struct has some benefits:
* Run-time data is not stored in files.
* Makes it easy to use c++ types as run-time data.
* More clear distinction between what data only exists at run-time and which doesn't.
This commit doesn't move all run-time data to the new struct yet, only the data where
I know for sure how it is used. The remaining data can be moved separately.
Differential Revision: https://developer.blender.org/D15033
This is a regression caused by a230445cae.
The internal cause of the issue was that the synchronization component
was no longer tagged as visible (and hence not evaluated) as it not
connected to any directly visible IDs.
Changed the logic in a way that if any component of an ID is evaluated
the synchronization component will be evaluated as well.
The naming of the flag in the component node is a bit confusing, but
for the simplicity of the change for the upcoming release left it
unchanged.
The goal is to make it easier to track down sources of errors during
the dependency graph builder.
With this change whenever a relation can not be added a trace to the
entity which requested the relation will be printed. For example:
```
Failed to add relation "Copy Location"
Could not find op_from: OperationKey(type: BONE, component name: 'MissingBone', operation code: BONE_DONE)
Trace:
Depth Type Name
----- ---- ----
1 Object Armature.001
2 Pose Channel Bone
3 Constraint Copy Location
```
On an implementation detail traced places where `checkIsBuiltAndTag`
is called, with some additional places to help tracking pose channels,
constraints, and modifiers.
Further improvements in granularity are possible, but that could happen
as a followup development once the core part is proven to work.
An example of such improvement would be to have entries in the trace
which will indicate NLA and drivers building. Currently it might be
a bit confusing to see IDs in the trace referenced from driver.
Even with such limitation the current state of the patch brings a
very valuable information (some information is much better than no
information at all).
Differential Revision: https://developer.blender.org/D15017
Previously, the depsgraph assumed that every node tree might contain
a reference to a video. This resulted noticeable overhead when there
was no video.
Checking whether a node tree contained a video was relatively expensive
to do in the depsgraph. It is cheaper now due to the structure of the new
node tree updater.
This also adds an additional run-time field to `bNodeTree` (there are
quite a few already). We should move those to a separate run-time
struct, but not as part of a bug fix.
Differential Revision: https://developer.blender.org/D14957
Fix a crash when a driver variable targets an object and uses
`data.shape_keys.key["name"].value` in its expression.
The fix consists of adding an extra relation from the targeted object's
`GEOMETRY` component to the driver evaluation. This ensures that its
`data` pointer has been evaluated by the depsgraph and is safe to
follow.
This also resolves the concern raised on rB56407432a6aa.
Reviewed by: brecht
Differential Revision: https://developer.blender.org/D14956
