The BLI_spin APIs use a `SpinLock` typedef whose underlying type is
contingent on the precense of `WITH_TBB`. Since our projects did not
consistently define the `WITH_TBB` definition, multiple `SpinLock` types
would end up in our final binary creating ODR violations.
Pull Request: https://projects.blender.org/blender/blender/pulls/124285
The viewport compositor crashes when the scene is changed in some
situations. That's because the viewport compositor tries to use node
tree data that was freed in the last depsgraph update, while it should
have invalidate those references based on the same depsgraph update.
The source of this issue is in the depsgraph itself. In particular, when
the depsgraph evaluation happens in two passes, the ID recalculate flags
are backed up for every pass then restored at the end of all passes,
however, this doesn't happen for the ID Type Update table. So whenever
evaluations happen in two passes, changes will not be propagated to
engines that require those information, like the viewport compositor
engine in that particular case.
To fix this, we backup and restore the ID Type Update table in a similar
manner to the ID recalculate flags.
Fixes#107235, #124335, #116142.
Pull Request: https://projects.blender.org/blender/blender/pulls/124409
Point caches can be part of modifiers, in which case changes to the
input geometry should reset the cache. This worked when the input data
is the initial object data, but does not take the modifier stack into
account. A preceding modifier could update based on some dependency
and the point cache would be none the wiser.
The `POINT_CACHE_RESET` depsgraph node now gets additional dependencies
if it's in a modifier with a predecessor.
Caveat: all caches are represented by a single node currently. That
means an indirect change to a modifier will reset all caches of that
object.
Fixes#74523
Pull Request: https://projects.blender.org/blender/blender/pulls/124247
Rename "Animation data-block" to "Action" or "Layered Action", where
appropriate. Some uses of the term actually refer to the `AnimData`
struct, in which case they were left as-is.
No real functional changes, just changing some messages & descriptions.
Pull Request: https://projects.blender.org/blender/blender/pulls/124170
Rename 'Binding' to 'Slot'. The old term was causing all kind of
confusion, and 'slot' was considered to be a better term for the
intended functionality.
This commit breaks existing blend files that were using the new layered
Action for their animation. The animation data will be lost due to the
rename, as there is no versioning code or DNA renaming logic. At this
time the new system is still marked as experimental, so shouldn't be
used for anything serious anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/124170
The idea is to skip building data-blocks referenced by ID
properties for dependency graphs used by render pipeline and
compositor preview. Those graphs do not use handlers, so it
is not required to have custom references to data-blocks
evaluated.
This solves an initial hicckup and memory usage with file
from #121188 when doing compositor. It also reduces the time
until first pixel when hitting F12 on that file.
Pull Request: https://projects.blender.org/blender/blender/pulls/123439
Reference identifiers instead of "above" in code comments as these
tends to become outdated. Even when declarations are removed it's at
least clear that the reference no longer exists instead of referring to
whatever is currently above the declaration.
It's also straightforward to search history for a removed identifier.
Corrected 4 cases of references to things that were no longer above
the doc-strings. Noticed other references which look to be incorrect
but need further investigation.
There is some special code in the Object's freeing which did
special checks for SubdivCCG based on the evaluated mesh state.
If the depsgraph is destroyed prior to the evaluated object it
makes object to access freed components of ID node.
The fix makes it so the evaluated ID is freed prior to freeing
components.
While the evaluated result is not well defined, we expect Blender to not crash
when there are dependency cycles.
The evaluation of one object often takes the evaluated geometry of another
object into account. This works fine if the other object is already fully
evaluated. However, if there is a dependency cycle, the other object may not be
evaluated already. Currently, we have no way to check for this and were mostly
just relying on luck that the other objects geometry is in some valid state
(even if it's not the fully evaluated geometry).
This patch adds the ability to explicitly check if an objects geometry is fully
evaluated already, so that it can be accessed by other objects. If there are not
dependency cycles, this should always be true. If not, it may be false
sometimes, and in this case the other objects geometry should be ignored. The
same also applies to the object transforms and the geometry of a collection.
For that, new functions are added in `DEG_depsgraph_query.hh`. Those should be
used whenever accessing another objects or collections object during depsgraph
evaluation. More similar functions may be added in the future.
```
bool DEG_object_geometry_is_evaluated(const Object &object);
bool DEG_object_transform_is_evaluated(const Object &object);
bool DEG_collection_geometry_is_evaluated(const Collection &collection);
```
To determine if the these components are fully evaluated, a reference to the
corresponding depsgraph is needed. A possible solution to that is to pass the
depsgraph through the call stack to these functions. While possible, there are a
couple of annoyances. For one, the parameter would need to be added in many new
places. I don't have an exact number, but it's like 50 or so. Another
complication is that under some circumstances, multiple depsgraphs may have to
be passed around, for example when evaluating node tools (also see
`GeoNodesOperatorDepsgraphs`).
To simplify the patch and other code in the future, a different route is taken
where the depsgraph pointer is added to `ID_Runtime`, making it readily
accessible similar to the `ID.orig_id`. The depsgraph pointer is set in the same
place where the `orig_id` is set.
As a nice side benefit, this also improves the situation in simple cases like
having two cubes with a boolean modifier and they union each other.
Pull Request: https://projects.blender.org/blender/blender/pulls/123444
This handles the transition to EEVEE-Next (now EEVEE).
This removes some things that make no sense to keep
even for compatibility.
- Scene.eevee.light_cache_data
- Scene Light cache operators
- Scene Light cache RNA properties
The remaining legacy properties will be removed later
on to avoid python API breakage.
We keep the identifier of EEVEE-Next as `BLENDER_EEVEE_NEXT`
to avoid addons being incorrectly silently made compatible
with the EEVEE-Next where the Python API is different.
This renaming should be done in 5.0 release.
Thank you EEVEE-Legacy, you served us well.
Pull Request: https://projects.blender.org/blender/blender/pulls/122433
If an object is hidden it is unsafe to look deep into its properties, such
as evaluated mesh state. Do early visibility checks to avoid accessing
possibly stake pointers.
Pull Request: https://projects.blender.org/blender/blender/pulls/122496
Only happens under certain circumstances: when a renderable object is
not visible at the graph node build time, but becomes visible due to
some indirect dependency like instancing.
In order to solve this, report all updates via the depsgraph.updates.
Reproduced with 210_0040-lighting.blend from the Gold repository at
revision 2834: open the file, enter rendered viewport, change frame,
and observe that sails do not move with the boat.
Pull Request: https://projects.blender.org/blender/blender/pulls/121833
Move all header file into namespace.
Unnecessary namespaces was removed from implementations file.
Part of forward declarations in header was moved in the top part
of file just to do not have a lot of separate namespaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/121637
The new/experimental, layered `Animation` data-block is merged with the
existing `bAction` data-block.
The `Animation` data-block is considerably newer than `bAction`, so the
supporting code that was written for it is also more modern. When moving
that code into `bAction`, I chose to keep the modernity where possible,
and thus some of the old code has been updated as well. Things like
preferring references over pointers.
The `Animation` data-block is now gone from DNA, the main database, etc.
As this was still an experimental feature, there is no versioning code
to convert any of that to Actions.
The DNA struct `bAction` now has a C++ wrapper `animrig::Action`, that
can be obtained via `some_action->wrap()`.
`animrig::Action` has functions `is_empty()`, `is_action_legacy()`, and
`is_action_layered()`. They **all** return `true` when the Action is
empty, as in that case none of the data that makes an action either
'legacy' or 'layered' is there.
The 'animation filtering' code (for showing things in the dope sheet,
graph editor, etc) that I wrote for `Animation` is intentionally kept
around. These types now target 'layered actions' and the
already-existing ones 'legacy actions'. A future PR may merge these two
together, but given how much work it was to add something new there, I'd
rather wait until the dust has settled on this commit.
There are plenty of variables (and some comments) named `anim` or
`animation` that now are of type `animrig::Action`. I haven't renamed
them all, to keep the noise level low in this commit (it's already big
enough). This can be done in a followup, non-functional PR.
Related task: #121355
Pull Request: https://projects.blender.org/blender/blender/pulls/121357
In previous code, the owner ID info would not be available when
processing an embedded ID in two cases, and was incorrectly set to the
processed (embedded) ID instead:
1. When directly calling `BKE_library_foreach_ID_link` on an embedded ID.
2. When using recursive processing (`IDWALK_RECURSE`).
This commit mostly fixes both cases, by using `BKE_id_owner_get` to find
the owner ID when it is unknown.
There are some caveats here though: in a few specific cases (mainly ID
copying, and depsgraph ID copying), `BKE_library_foreach_ID_link` can be
called on embedded IDs which owner ID is not yet valid. In such case, a
new flag can be used to keep using the previous behavior
(`IDWALK_IGNORE_MISSING_OWNER_ID`).
Fixing the issue with copy code being unaware of the owner ID when
copying an embedded one should also be fixed, but this will be addressed
separately.
Note that as 'side efect', this commit also fixes a matching issue in
the `lib_remap` code, where the `IDRemap.id-owner` pointer would also
wrongly be set to the remapped embedded ID instead of its actual owner.
This change is not expected to have any effect in current codebase.
Currently for node tools we create and evaluate a temporary depsgraph
with all the selected object data-blocks and all data-blocks referenced
by the node tree.
Needless to say, this can be very slow when those data-blocks contain
arbitrary procedural operations. Re-evaluating all the selected objects
is particularly because it will give a slowdown even in very basic uses
of node tools.
Originally I hoped that geometry nodes could be made to work with
original as well as evaluated data-blocks. But that would require far
too many tricky changes and arguably isn't right design-wise anyway.
Instead of that, this commit makes node tools dependency graph
evaluation more fine-grained in a few ways.
1. Remove the evaluation of selected objects. These are always visible
in the viewport and part of the active depsgraph anyway. To protect
against cyclic dependencies, we now compare `orig_id` instead of the
object pointer itself.
2. Evaluate the node group and its dependencies in a separate depsgraph
used only when necessary. This allows using the original node tree
without any copies when it doesn't reference any data-blocks.
3. Evaluate IDs from node group inputs (from the redo panel) in the extra
depsgraph as well, only when necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/120723
Avoid re-copying the scene when the scene is tagged for frame change.
For scenes with many objects scrubbing & jumping between first/last
caused noticeably worse performances.
Resolve by:
- Returning false from need_tag_cow_before_update when the recalc flag
is ID_RECALC_FRAME_CHANGE.
- Change deg_graph_tag_parameters_if_needed to consider
ID_RECALC_FRAME_CHANGE a clean flag.
Ref !104801
Collections which were pointed by a modifier used to follow visibility of the
current object, and this visibility is static throughout the lifetime of the
dependency graph.
Change the code so that collections pointed by modifiers rely on the visibility
flushing, allowing to be optimized out from evaluation.
Pull Request: https://projects.blender.org/blender/blender/pulls/120516
This is actually a deeper issue, which roots to the fact that updating
relations of the dependency graph does not properly handle cases when an
operation was previously skipped from evaluation (i.e. as a visibility
optimization).
The fix is to preserve needs-update flag throughout relations update of
a dependency graph, similar to the entry tags.
Pull Request: https://projects.blender.org/blender/blender/pulls/120477
Expand the `AnimData` struct with an `Animation *` + an
`binding_stable_index` field, and properly handle those relations.
This also adds functionality for actually pointing animated IDs to
`Animation` data-blocks, and automatically hooking up the relevant
`Binding`.
The Depsgraph code is extended to take these new relations into account,
but doesn't trigger any animation evaluation yet.
For more info, see #113594.
Pull Request: https://projects.blender.org/blender/blender/pulls/118677
Regression since 7a2d04a5c4.
Mask evaluation is part of parameters component, and there is no explicit
tags other than copy-on-eval for masks in a lot of cases.
Restore the previous graph topology for the link from copy-on-eval to the
parameters components of mask ID.
Potential candidate for 4.1.1.
Pull Request: https://projects.blender.org/blender/blender/pulls/119956
A regression caused by 7a2d04a5c4.
The offending commit made it so selection tag does not imply parameters
update, which also avoids transitive re-evaluation of the curve geometry.
However, the active curve index is stored on a Curve, and curve modifier
stack creates a copy of the curve to hold the evaluation results, which
makes it so evaluated curve object does not intrinsically share the active
spline index.
This change makes it so changes in selection triggers geometry evaluation
on curves, matching the behavior prior to the offending commit.
AN ideal fix would somehow avoid such geometry re-evaluation, but it would
be a bigger change, not suitable for possible corrective release.
Potential candidate for 4.1.1.
Pull Request: https://projects.blender.org/blender/blender/pulls/119918
The issue was caused by 29aaa2922d.
With the change from the offended commit there was nothing that
would have informed objects previously linked to a light that they
need to re-calculate their light linking collections.
This change makes it so scene's hierarchy is tagged for update,
which propagates to all dependencies which do depend on hierarchy
of objects and collections in the scene.
This brings behavior closer to what it used to be, without causing
slowdown with full re-evaluation (which was fixed by the offending
commit).
Pull Request: https://projects.blender.org/blender/blender/pulls/119698
"Own" (the adjective) cannot be used on its own. It should be combined
with something like "its own", "our own", "her own", or "the object's own".
It also isn't used separately to mean something like "separate".
Also, "its own" is correct instead of "it's own" which is a misues of the verb.
Introduce new DNA for the `Animation` data-block and its sub-data.
This includes the blenkernel code for reading & writing to blend files,
and for memory management (freeing, duplicating). Minimal C++ wrappers
are included, with just the functionality needed for blenkernel to do
its job.
The Outliner code is extended so that it knows about the new data-type,
nothing more.
For more info, see issue #113594.
Pull Request: https://projects.blender.org/blender/blender/pulls/119077
This adds a new `DEG_graph_build_from_collection` function and related
pipeline to more easily build a graph of all relevant IDs from a given
Collection.
It was modeled after the `FromIDsBuilderPipeline` with the difference
being that the list of IDs is gathered from the Collection rather than
passed in. It also slightly differs in that the filtering class shares a
common `Set` rather than building it twice, once for the node builder
and once for the relation builder.
It will eventually be used for the Collection IO project where various
IO exporters will be tied to a Collection and will be limited to just
IDs contained in said Collection.
Pull Request: https://projects.blender.org/blender/blender/pulls/118732
`RootPChanMap` will be nullptr when building DEG object-level
constraints (as as opposed to bone constraints where this map is built
prior), and in that case we don't need to check for the common chains in
`bone_target_opcode`.
Thx @sergey for additional confirmation
Pull Request: https://projects.blender.org/blender/blender/pulls/118745
The depsgraph CoW mechanism is a bit of a misnomer. It creates an
evaluated copy for data-blocks regardless of whether the copy will
actually be written to. The point is to have physical separation between
original and evaluated data. This is in contrast to the commonly used
performance improvement of keeping a user count and copying data
implicitly when it needs to be changed. In Blender code we call this
"implicit sharing" instead. Importantly, the dependency graph has no
idea about the _actual_ CoW behavior in Blender.
Renaming this functionality in the despgraph removes some of the
confusion that comes up when talking about this, and will hopefully
make the depsgraph less confusing to understand initially too. Wording
like "the evaluated copy" (as opposed to the original data-block) has
also become common anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118338
The `object_to_world` and `world_to_object` matrices are set during
depsgraph evaluation, calculated from the object's animated location,
rotation, scale, parenting, and constraints. It's confusing and
unnecessary to store them with the original data in DNA.
This commit moves them to `ObjectRuntime` and moves the matrices to
use the C++ `float4x4` type, giving the potential for simplified code
using the C++ abstractions. The matrices are accessible with functions
on `Object` directly since they are used so commonly. Though for write
access, directly using the runtime struct is necessary.
The inverse `world_to_object` matrix is often calculated before it's
used, even though it's calculated as part of depsgraph evaluation.
Long term we might not want to store this in `ObjectRuntime` at all,
and just calculate it on demand. Or at least we should remove the
redundant calculations. That should be done separately though.
Pull Request: https://projects.blender.org/blender/blender/pulls/118210
The issue was caused by Cycles doing dependency tracking on its
side, relying on the fact that view layer needs to be tagged as
modified when its properties change.
This was not the case when custom property on the a view layer is
modified via a driver.
Now the dependency graph will tag IDs which generic properties did
change as ID_RECALC_PARAMETERS, giving it a chance to render engines
to react to it.
Since this is quite generic code which might have unforeseen side
effects the change is not targeted to the current release branch.
Note that this chaneg does not fix the #103140, as the issue there
is use of RNA path to another data-block, without the node tree
registering relation to that data-block.
Pull Request: https://projects.blender.org/blender/blender/pulls/118134
