| Age | Commit message (Collapse) | Author |
|---|
|
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 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
|
|
So far it was needed to declare a new RNA struct to `RNA_access.h` manually.
Since 9b298cf3dbec 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
|
|
This implements the update cache described in T95401.
The cache is currently only used for drawing strokes and
sculpting (using the push brush).
**Note: Making use of the cache throughout grease pencil will
have to be done incrementally in other patches. **
The update cache stores what elements have changed in the
original data-block since the last time the eval object
was updated. Additionally, the update cache can store multiple
updates to the data and minimizes the number of elements
that need to be copied.
Elements can be tagged using `BKE_gpencil_tag_full_update` and
`BKE_gpencil_tag_light_update`. A full update means that the element
itself will be copied but also all of the content inside. E.g. when a
layer is tagged for a full update, the layer, all the frames inside the
layer and all the strokes inside the frames will be copied.
A light update means that only the properties of the element are copied
without any of the content. E.g. if a layer is tagged with a light
update, it will copy the layer name, opacity, transform, etc.
When the update cache is in use (e.g. elements have been tagged) then
the depsgraph will not trigger a copy-on-write, but an update-on-write.
This means that the update cache will be used to determine what elements
have changed and then only those elements will be copied over to the
eval object.
If the update cache is empty or the data block was tagged with a full
update, we always fall back to a copy-on-write.
Currently, the update cache is only used by the active depsgraph. This
is because we need to free the update cache after an update-on-write so
it's reset and we need to make sure it is not freed or read by other
depsgraphs.
Co-authored-by: @yann-lty
This patch was contributed by The SPA Studios.
Reviewed By: sergey, antoniov, #dependency_graph, pepeland, mendio
Maniphest Tasks: T95401
Differential Revision: https://developer.blender.org/D13984
|
|
Evaluating the dependency graph potentially executes Python code when
evaluating drivers. In specific situations (see T91046) this could
deadlock Blender entirely. Temporarily releasing the GIL when evaluating
the depsgraph resolves this.
This is an improved version of
rBfc460351170478e712740ae1917a2e24803eba3b, thanks @brecht for the diff!
Manifest task: T91046
|
|
It is causing crashes in rendering, when releasing the GIL in render threads
while the main thread is holding it.
Ref T91046
This reverts commit fc460351170478e712740ae1917a2e24803eba3b.
|
|
Evaluating the dependency graph potentially executes Python code when
evaluating drivers. In specific situations (see T91046) this could deadlock
Blender entirely. Temporarily releasing the GIL when evaluating the depsgraph
resolves this.
Calling the `BPy_BEGIN_ALLOW_THREADS` macro is relatively safe, as it's
a no-op when the current thread does not have the GIL.
Developed in collaboration with @sergey
Manifest task: T91046
|
|
Without this tests fail to lknk in D11377. Commit separately as the
depsgraph is using BKE it should link to it.
|
|
This is the initial merge from the geometry-nodes branch.
Nodes:
* Attribute Math
* Boolean
* Edge Split
* Float Compare
* Object Info
* Point Distribute
* Point Instance
* Random Attribute
* Random Float
* Subdivision Surface
* Transform
* Triangulate
It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier.
Notes on the Generic attribute access API
The API adds an indirection for attribute access. That has the following benefits:
* Most code does not have to care about how an attribute is stored internally.
This is mainly necessary, because we have to deal with "legacy" attributes
such as vertex weights and attributes that are embedded into other structs
such as vertex positions.
* When reading from an attribute, we generally don't care what domain the
attribute is stored on. So we want to abstract away the interpolation that
that adapts attributes from one domain to another domain (this is not
actually implemented yet).
Other possible improvements for later iterations include:
* Actually implement interpolation between domains.
* Don't use inheritance for the different attribute types. A single class for read
access and one for write access might be enough, because we know all the ways
in which attributes are stored internally. We don't want more different internal
structures in the future. On the contrary, ideally we can consolidate the different
storage formats in the future to reduce the need for this indirection.
* Remove the need for heap allocations when creating attribute accessors.
It includes commits from:
* Dalai Felinto
* Hans Goudey
* Jacques Lucke
* Léo Depoix
|
|
This is first step of refactoring task T77580.
Next step will be breaking up files into smaller ones.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D8492
|
|
Add a new depsgraph builder class that includes invisible objects and
use that in the Alembic exporter.
Alembic supports three options for visibility, "visible", "inherited",
and "hidden". This means that parents can be hidden and still have
visible children (contrary to USD, where invisibility is used to prune
an entire scene graph subtree). Because of this, the visibility is
stored on the transform node, as that represents the Object in Blender
and thus keeps the Alembic file as close to Blender's own structure as
possible.
Reviewed By: Sergey
Differential Revision: https://developer.blender.org/D8595
|
|
|
|
This will make it easier & cleaner to make custom-built depsgraph (for
example for exporting invisible objects to USD or Alembic, see T75936).
No functional changes.
Reviewed by: sergey
Differential Revision: https://developer.blender.org/D8423
|
|
This makes `RNANodeQuery::construct_node_identifier()` more strict in
its matching of certain property names.
The downside of this approach is that it's not possible any more to use
`"rotation"` and expect a match for `"rotation_euler"` and friends, so
the list of strings to test against is now 3x as long.
Reviewed By: sergey
Maniphest Tasks: T79121
Differential Revision: https://developer.blender.org/D8375
|
|
The extra depsgraph relations that were added to prevent threading
issues during evaluation (rB4c30dc343165) caused a considerable slowdown
on complex scenes with many drivers (T77277, T78615). This commit
improves this as follows.
Only the following drivers are considered for execution serialisation:
- Drivers on Array elements, and
- Drivers on Boolean or Enum properties.
Relations between drivers of the same arrays are added blindly, i.e.
without checking for transitive or cyclic relations. This is possible as
other relations will just target the `PROPERTIES_ENTRY` or
`PROPERTIES_EXIT` nodes.
Checking whether a driver is on an array is first done by checking
`array_index > 0`, and then falling back to resolving the RNA path to an
RNA property and inspecting that.
The code also avoids circular dependencies when there are multiple
drivers on the same property. This not something that is expected to
happen (both the UI and the Python API prevent duplicate drivers), it
did happen in a file (F8669945, example file of T78615) and it is easy
to deal with here.
Reviewers: sergey
Subscribers: mont29
Comment update
|
|
Only the volume object is exposed in the user interface. It is based on OpenVDB
internally. Drawing and rendering code will follow in another commit.
https://wiki.blender.org/wiki/Source/Objects/Volume
https://wiki.blender.org/wiki/Reference/Release_Notes/2.83/Volumes
Hair and PointCloud object types are hidden behind a WITH_NEW_OBJECT_TYPES
build option. These are unfinished, and included only to make it easier to
cooperate on development in the future and avoid tricky merges.
https://wiki.blender.org/wiki/Source/Objects/New_Object_Types
Ref T73201, T68981
Differential Revision: https://developer.blender.org/D6945
|
|
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
|
|
|
|
The FPS here is measured based on a timestamp from when depsgraph
was previously evaluated.
Allows to ease investigating performance improvements/regressions
which are not related on animation system but on modifications on
a single frame (such as transforming vertex in edit mode).
|
|
|
|
The issue was caused by special handling of animation update after
manual edits in frame_post handler: to avid loss of manual edits
done on top of animated property. This was done as a separate pass
for non-animation update after frame_post did modifications.
This caused some other side-effect: non-modified animated property
was re-setting to the value which is used in the viewport.
Idea of this solution is simple: preserve values which came from
animation update through copy-on-write process. The actual process
of this is a bit involved: need to decode RNA path and do it twice
since f-curve might point to a sub-data which pointer will change.
Since this is only done for non-active depsgraph (aka depsgraph
used for render pipeline) this is probably fine since all this
extra overhead is just a fraction of overall render process.
Differential Revision: https://developer.blender.org/D6330
|
|
It started to be a long code of all various cases in a single file,
which started to be really confusing.
|
|
Allows to access dependency graphs created for render engines
to inform them about changes in .blend file structure from the
Python handlers.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5724
|
|
|
|
This is used by driers and this is a first step towards support of
scenes used for only compositor or sequencer.
Fixes T61014: Assert adding a driver that uses a single property of a scene ID
|
|
This was an attempt to speed up motion path calculation, which didn't
really work in real world animation files, where animators already
hide and disable all the heavy collections. Filtering approach also
doesn't allow to have multiple frames evaluated in multiple threads
easily.
Filtering also adds extra complexity on keeping the graph in a correct
and consistent state.
Fixes T64057: Blender crash when use motion paths
|
|
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.
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
No functional change, this adds LIB definition and args to cmake files.
Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS'
since there are many platforms/configurations that could break when
changing linking order.
Manually add and enable WITHOUT_SORTED_LIBS to try building
without sorted libs (currently fails since all variables are empty).
This check will eventually be removed.
See T46725.
|
|
Currently should have no functional changes, but allows to
implement runction optimizations more localized and easily.
|
|
Following removal from C source code.
See: 8c68ed6df16d8893
|
|
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.
|
|
When this works correctly, we should be able to feed in an existing
depsgraph instance, and get out a "filtered" copy of it that contains
only the subset of nodes needed to evaluate what we're interested in.
The current implementation only filters on ID blocks/nodes,
and starts by building a full new depsgraph instance first.
I'd originally intended to do it per operation instead, copying
over individual nodes as appropriate to have the smallest and least
memory intensive graph possible. However, I ended up running into
into problems with function binding + COW arguments, hence the
current slow solution.
|
|
|
|
|
|
This is in preparation of upgrading our library dependencies, some of which
need C++11. We already use C++11 in blender2.8 and for Windows and macOS, so
this just affects Linux.
On many distributions this will not require any changes, on some
install_deps.sh will need to be run again to rebuild libraries.
Differential Revision: https://developer.blender.org/D3568
|
|
This makes tagging much more generic and make the world updates more in
line with the new tagging system (Depsgraph).
|
|
To find all effectors in the scene, we need to loop over all objects.
Doing this during depsgraph evaluation caused crashes because not all
objects are guaranteed to be evaluated yet.
To fix this, we now cache the relations as part of the dependency graph
build. As a bonus this also makes evaluation faster for big scenes,
since looping over all objects for each particle system is slow.
Fixes T55156.
|
|
Use single function to evaluate all the collections for the given view layer.
This way we avoid need to get scene ID sub-data. Similar to pchan index, this
allows us to avoid build-time scene expansion, which also simplifies update of
the scene datablock.
Well, sort of. There is still work to be done to get rid of build-time scene
datablock expansion, which includes:
- Need to pass view layer by index.
Annoying part would be to get actual view layer for that index. In practice
doing list lookup might not be such a bad idea, since such lookup will not
happen very often, and it is unlikely to have more than handful of view
layer anyway.
Other idea could be to use view layer from evaluation context.
Or maybe from depsgraph, which is supposed to be in the context. Can have
some assert statements to make sure everything is good.
- Need to get id of base binding for flags flush.
We can replace that with index-based lookup from an array created by view
layer evaluation.
Reviewers: dfelinto
Differential Revision: https://developer.blender.org/D3141
|
|
|
|
Currently unused, actual logic change will come in the next commit.
|
|
|
|
This statistics is only collected when debug_value is different from 0.
Stored in depsgraph node itself, so we can always have access to average data
and other stats which requires persistent storage. This way we also don't waste
time trying to find stats from a separately stored hash map.
|
|
We might implement other things to dump into graphviz, so better to
start having explicit names.
|
|
|
|
|
|
|
|
|
|
|
