This was essentially a use-after-free issue. When a geometry nodes
group changes it has to be preprocessed again before it can be evaluated.
This part was working, the issue was that parent node groups have to be
preprocessed as well, which was missing. The lazy-function graph cached
on the parent node group was still referencing data that was freed when
the child group changed.
Now the depsgraph makes sure that all relevant geometry node groups are
preprocessed again after a change.
This issue was found by Simon Thommes.
Solves long-standing issue when dependencies of disabled modifiers are
evaluated.
Simple test case: no drivers or animation. Manually enabling modifier
is expected to bring FPS up, enabling modifier will bring FPS (sine
evaluation can not be avoided)
F13336690
More complex test case: modifier visibility is driven by an animated
property. In am ideal world FPS during property being zero is fast
and when property is 1 the FPS is low.
F13336691.
Differential Revision: https://developer.blender.org/D15625
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
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.
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.
So far it was needed to declare a new RNA struct to `RNA_access.h` manually.
Since 9b298cf3db we generate a `RNA_prototypes.h` for RNA property
declarations. Now this also includes the RNA struct declarations, so they don't
have to be added manually anymore.
Differential Revision: https://developer.blender.org/D13862
Reviewed by: brecht, campbellbarton
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Part of T91671.
Not much else to say, this is mainly a massive deletion of code.
Note that a few cleanups possible after this proxy removal were kept out
of this commit to try to reduce a bit its size.
Reviewed By: sergey, brecht
Maniphest Tasks: T91671
Differential Revision: https://developer.blender.org/D13995
The are few things in the dependency graph which lead to the issue:
- IDs are only built once.
- Object-data level (Armature, i,e,) builder dependent on the object
visibility.
This caused issues when an armature is first built as not directly
visible (via driver, i.e.) and then was built as a directly visible.
This did not update visibility flag on the node for the custom shape
object.
The idea behind the fix is to go away form passing object visibility
flag to the geometry-level builders and instead rely on the common
visibility flush post-processing to make sure certain objects are
fully visible when needed.
This is the safest minimal part of the change for 3.0 release which
acts as an additional way to ensure visibility. This means that it
might not be a complete fix (if some configuration was overseen) but
it should not make currently working cases to not work.
The fix should also make modifiers used on rigify widgets to work.
The more complete fix will have `is_object_visible` argument removed
from the geometry-level builder functions.
Differential Revision: https://developer.blender.org/D13404
This removes a lot of unnecessary code that is generated by
the compiler automatically.
In very few cases, a defaulted destructor in a .cc file is
still necessary, because of forward declarations in the header.
I removed some defaulted virtual destructors, because they are not
necessary, when the parent class has a virtual destructor already.
Defaulted constructors are only necessary when there is another
constructor, but the class should still be default constructible.
Differential Revision: https://developer.blender.org/D10911
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.
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
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.
The issue was caused by dependency graph always ignoring animation
update when it is first time constructed. This was a way to make it
preserve unkeyed changes on undo/redo. This, however, made it so
changes of animation data itself (such as deleting/moving keyframes)
did not trigger animation update by the dependency graph.
This worked prior to copy-on-write because animation recalc flags
were stored in the DNA and never re-set on file/undo load. This was
giving dependency graph a clue that animation is to be re-evaluated
when operator explicitly asked to (more precisely, when such operator
was undone/redone).
This change makes it so original ID's recalc flags are storing
recalc flags when ID is tagged for update as an response to user
input. This way re-building dependency graph can force animation
to be updated on redo.
Tricky part here is that ID's recalc flag is no longer to be zeroed
when loading undo step (which is the same as reading .blend file).
This is something what works differently comparing to legacy
dependency graph, which was zeroing object's recalc flags there but
not animation data's recalc flags.
Shouldn't be causing issues, since unkeyed changes are not preserved
upon opening a file anyway, at least to my knowledge.
Related reports which are to be taken into account and verified
they are not re-introduced when making changes in the area:
- T63111: Auto-Bake stuck at constant re-rendering
- T54296: Cycles viewport render stuck on constant re-render
Reviewers: campbellbarton, brecht
Reviewed By: campbellbarton, brecht
Maniphest Tasks: T66325
Differential Revision: https://developer.blender.org/D5316
This is a part of T61296: Crash with animated b-bone segments.
Consider animated/driven bendy bones segments as something what requires
special bendy-bones operation and relation in the dependency graph.
This is because it is more beneficial from a performance point of view
to not build operations if they are not needed. But if the property is
animated it is not possible to make any reliable decision based on just
a property value.
Differential Revision: https://developer.blender.org/D4739
Should be no functional changes, just switching code to use more
generic checks now.
One thing which goes a bit deeper than that is check for whether
base is a part of dependency graph. This is now done by explicitly
tagging corresponding ID node (of an object) rather than doing
animation check again.
Allows to speed up lookups like "is property FOO of data BAR animated".
Can be used to optimize object's visibility check, but also allows to
check animation on bones without too much of time penalty.
The cache is shared between both nodes and relations builder.
Currently is not used, just a boilerplate for an upcoming changes in
an actual logic.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
Object of evaluated base is not yet copied, so we can not know whether
it has animation on visibility or not.
This issue was reported in T56635#630383.
Original optimization idea was wrong: it is possible that some other
ID would reference an object which is also used by a base.
Rolled back to a bit more fragile solution.
In the future would be nice to make it somewhat less duplicated with
the builder itself.
Fixes assert failure (and possibly crashes) when adding grease pencil
object and switching to a draw mode.
While it's kind of common to use camel case in C++ this is not
currently agreed style for C++ in Blender.
Got confused by working on other areas with 3rd party libraries.
This allows dependency graph to evaluate drivers of those objects
and put them to a correct state. It will increase memory usage
since now we can no longer save it by skipping copy-on-write for
such objects. It will also currently make things slower, because
we do not have granular enough visibility update of components in
the dependency graph. Can do it later when the rest of the changes
are finished.
This commit does not update restriction flags on the base, since
that is somewhat tricky to do currently: need to somehow see whether
object is disabled due to flags on collection or due to own flags.
Differential Revision: https://developer.blender.org/D4419
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Some summary of changes:
- Don't use DEG prefix for types and enumerator values:
the code is already inside DEG namespace.
- Put code where it locally belongs to: avoid having one
single header file with all sort of definitions in it.
- Take advantage of modern C++11 enabled by default.
This removes a bunch of animation/driver evaluations and recalc flags that
should be redundant in the new depsgraph, and were incorrectly affecting
the evaluated scene in a permanent way.
Still two cases that could be removed if the depsgraph is improved, in
BKE_object_handle_data_update and BKE_cachefile_update_frame.
For physics subframe interpolation there are also still calls to
BKE_object_where_is_calc that should ideally be removed as well, though
they are not known to cause keyframing bugs.
Differential Revision: https://developer.blender.org/D4274
There were at least three copies of those:
- OB_RECALC* family of flags, which are rudiment of an old
dependency graph system.
- PSYS_RECALC* which were used by old dependency graph system
as a separate set since the graph itself did not handle
particle systems.
- DEG_TAG_* which was used to tag IDs.
Now there is a single set, which defines what can be tagged
and queried for an update. It also has some aggregate flags
to make queries simpler.
Lets once and for all solve the madness of those flags, stick
to a single set, which will not overlap with anything or require
any extra conversion.
Technically, shouldn't be measurable user difference, but some
of the agregate flags for few dependency graph components did
change.
Fixes T58632: Particle don't update rotation settings
Move all mask-related fields from Object and OperationDepsNode
to Object_Runtime and IDDepsNode. Auto-apply DEG_TAG_GEOMETRY
if the mask changes after DEG rebuild. Update DEG API and all
code that uses it.
This fixes "source mesh data is not ready" errors from Data
Transfer modifier when parameters are changed in the UI after
the recent mesh_get_eval_final fix.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D4025
- Use the original ID pointer for lookup in DEG_get_eval_flags_for_id.
- When the flags change after a DEG rebuild, tag the object for update.
- Instead of mixing int and short in different places, use uint32_t.
This fixes text not updating when a Follow Curve reference is set.
