| Age | Commit message (Collapse) | Author |
|---|
|
The name was confusing to a level that it sounded like the relation
goes the opposite direction than it is intended.
|
|
|
|
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
|
|
Goals of this refactor:
* More unified approach to updating everything that needs to be updated
after a change in a node tree.
* The updates should happen in the correct order and quadratic or worse
algorithms should be avoided.
* Improve detection of changes to the output to avoid tagging the depsgraph
when it's not necessary.
* Move towards a more declarative style of defining nodes by having a
more centralized update procedure.
The refactor consists of two main parts:
* Node tree tagging and update refactor.
* Generally, when changes are done to a node tree, it is tagged dirty
until a global update function is called that updates everything in
the correct order.
* The tagging is more fine-grained compared to before, to allow for more
precise depsgraph update tagging.
* Depsgraph changes.
* The shading specific depsgraph node for node trees as been removed.
* Instead, there is a new `NTREE_OUTPUT` depsgrap node, which is only
tagged when the output of the node tree changed (e.g. the Group Output
or Material Output node).
* The copy-on-write relation from node trees to the data block they are
embedded in is now non-flushing. This avoids e.g. triggering a material
update after the shader node tree changed in unrelated ways. Instead
the material has a flushing relation to the new `NTREE_OUTPUT` node now.
* The depsgraph no longer reports data block changes through to cycles
through `Depsgraph.updates` when only the node tree changed in ways
that do not affect the output.
Avoiding unnecessary updates seems to work well for geometry nodes and cycles.
The situation is a bit worse when there are drivers on the node tree, but that
could potentially be improved separately in the future.
Avoiding updates in eevee and the compositor is more tricky, but also less urgent.
* Eevee updates are triggered by calling `DRW_notify_view_update` in
`ED_render_view3d_update` indirectly from `DEG_editors_update`.
* Compositor updates are triggered by `ED_node_composite_job` in `node_area_refresh`.
This is triggered by calling `ED_area_tag_refresh` in `node_area_listener`.
Removing updates always has the risk of breaking some dependency that no
one was aware of. It's not unlikely that this will happen here as well. Adding
back missing updates should be quite a bit easier than getting rid of
unnecessary updates though.
Differential Revision: https://developer.blender.org/D13246
|
|
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
Ref T92709
|
|
This issue was that `BKE_object_eval_uber_data` was not called for
the text object, because its geometry was not dependent upon
and its `is_directly_visible` tag was `false`. The crash happens in
rendering code, because the evaluated data is missing.
This not only affects text objects, but all object types that have a
geometry component that geometry nodes does not support yet.
The solution is to just add the missing dependencies.
Differential Revision: https://developer.blender.org/D11385
|
|
This fixes T87666 and T83252.
The boolean modifier and geometry nodes can depend on the geometry
of an entire collection. Before, the modifiers had to manually create relations
to all the objects in the collection. This worked for the most part, but was
cumbersome and did not solve all issues. For example, the modifiers were not
properly updated when objects were added/removed from the referenced collection.
This commit introduces the concept of "collection geometry" in the depsgraph.
The geometry of a collection depends on the transforms and geometry of all
the objects in it. The boolean modifier and geometry nodes can now just depend
on the collection geometry instead of creating all the dependencies themselves.
Differential Revision: https://developer.blender.org/D11053
|
|
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
|
|
Reviewers: sergey, sybren
Differential Revision: https://developer.blender.org/D8611
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D8605
|
|
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
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D8150
|
|
Differential Revision: https://developer.blender.org/D7982
|
|
For now the "Simulation" modifier only exists for point cloud objects, because
we need this for the particle system. Right now, the modifier is doing nothing.
There is a new `DEG_add_simulation_relation` function that is used
by the modifier to make sure that the simulation is evaluated before
the modifier is executed.
Reviewers: brecht, sergey
Differential Revision: https://developer.blender.org/D7549
|
|
Surrounding includes with an 'extern "C"' block is not necessary anymore.
Also that made it harder to add any C++ code to some headers, or include headers
that have "optional" C++ code like `MEM_guardedalloc.h`.
I tested compilation on linux and windows (and got help from @LazyDodo).
If this still breaks compilation due to some linker error, the header containing
the symbol in question is probably missing an 'extern "C"' block.
Differential Revision: https://developer.blender.org/D7653
|
|
|
|
|
|
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 ff60dd8b18ed00902e5bdfd36882072db7af8735. 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 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
|
|
No functional changes.
|
|
|
|
Was only using first ID instead of all of them.
Might have been causing issues when updating motion paths of
multiple objects.
Spotted by Jack C, thanks!
|
|
The title explains it all actually: this commit introduces special
dependency graph builder API which builds graph which is sufficient
to evaluate given set of IDs.
|
|
crashes
The static mesh issue described in T65816 has been resolved by @Sergey
in T60094.
This commit fixes the last bit of the puzzle, which was two-fold:
- A missing depsgraph update when setting `orig_object.data = new_mesh`
from Python. Thanks @Sergey for providing the fix :)
- Properly locking the interface while exporting. This prevents crashes
as described in T60094. The previous approach of calling
`BKE_spacedata_draw_locks()` was not enough.
|
|
Currently unused, but will allow to keep of an owner of the depsgraph.
Could also simplify other APIs in the future by avoiding to pass bmain
explicitly to relation update functions and things like that.
|
|
|
|
Part of the issue was caused by missing speaker objects in the depsgraph
used for post-processing.
Remaining part was caused by missing scene sound update for this depsgraph.
|
|
Respect do_time flag in on_visible_update, matching behavior of old
dependency graph and avoids unwanted animation updates.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5026
|
|
This change makes it so sound handles are created for evaluated scene,
sequencer and speakers. This allows to have properly evaluated animation
on them.
For the viewport playback sound uses regular dependency graph.
For the final render sound uses dependency graph created for render pipeline,
which now also contains sequencer and sound datablocks.
All the direct sound update calls are replaced with corresponding dependency
graph recalc tag.
|
|
This is probably just one of the related issues.
Root of the problem was that compositor job was using original scene and node
tree for compositing. It is not guaranteed to have all the evaluated data.
Switched compositor job to use it's own render-pipeline-like dependency graph
which has everything evaluated in it.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4998
|
|
This change makes it so a minimal dependency graph which only includes
compositor and sequencer is built for the render pipeline purposes.
Tricky part here is that it's only compositor itself and sequencer who
to use this dependency graph and IDs from it. Render engines are still
to be provided original IDs because:
- They will create dependency graph for the given scene, and currently
it is not possible to create dependency graph from CoW scene.
- IDs from the compositor/sequencer dependency graph are "stripped",
as in, they wouldn't have all view layers, collections or objects
required for proper final render.
This creates annoying mess of mixing evaluated and original scene
access in various parts of the pipeline.
Fixes T63927: Compositing nodes - drivers don't really work
Reviewers: brecht
Maniphest Tasks: T63927
Differential Revision: https://developer.blender.org/D4911
|
|
This happened to be a bigger rabbit hole to hell than it originally seemed,
and there are higher priority design tasks to be handled (at this point high
priority design task is more important than high priority bug fix).
After talking to Brecht the decision was made to revert to the known isolated
issue, which will allow everyone in the studio work same as prior to last
Friday.
The remaining bits will be worked on after all the design tasks are out of
the way.
This commit reverts:
4cdb4b9532c Fix T64161: Crashing using undo and multiple windows
064273a4ae7 Sound: Port more cases to be a part of dependency graph
2e582f8ab53 Sound: Fix access wrong dependency graph
5fc49d9c915 Sound: add stubs to build without audaspace
c68c81a870b Sound: Make sure spin lock is initialized for new sound datablocks
c02534469ac Sound: Delay creating sound scene handle for until is needed
9f681bea68f Fix T64144: Crash when displaying audio waveforms in VSE
2f79286453e Cleanup: unused vars
bed8ad6f95a Fix crash in background rendering after recent sound changes
773691310f9 Fix T64143: Crash when scrubbing in the graph editor
888852055c1 Sound: Fix for being unable to jump to a frame during playback with A/V sync
6ab7b384645 Sound: More fixes for access of original scene
35db1195455 Sound: Fix access original scene during playback
211c4fd2e9a Depsgraph: Make comment about evaluation more obvious
c5fe16e121e Sound: Make sound handles only be in evaluated datablocks
b4e1e0946bf Depsgraph: Preserve sound and audio pointers through copy-on-write
4eedf784b04 Depsgraph: Store original sequencer strip pointer
6990ef151c1 Sound: Move evaluation to dependency graph
d02da8de23b Sound: Delay opening handlers for until really needed
3369b828916 Depsgraph: Add scene audio component
e8f10d64757 Depsgraph: Tag sequencer for update on changes
6e4b7a6e4d9 Depsgraph: Initial work to cover sequencer
17447ac5a6b Depsgraph: Make sound ID part of the graph
|
|
Just adds sequencer operation and links possible sound ID to it.
No functional changes, just moving towards sound system integration
into the dependency graph.
|
|
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
|
|
Convention was not to but after discussion on 918941483f7e we agree its
best to change the convention.
Names now mostly follow RNA.
Some exceptions:
- Use 'nodetrees' instead of 'nodegroups'
since the struct is called NodeTree.
- Use 'gpencils' instead of 'grease_pencil'
since 'gpencil' is a common abbreviation in the C code.
Other exceptions:
- Leave 'wm' as it's a list of one.
- Leave 'ipo' as is for versioning.
|
|
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
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
|
|
Previously was only shown on --debug-depsgraph-build which
had other unwanted noise.
|
|
This is what modifiers are to use to indicate that they depend
on a transformation of the object itself.
Currently should be no functional changes, but in the future
this will allow to easily change transform operation depending
on whether there is a simulation associated with the object.
|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
Missed when removing contributors.
|
|
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.
|
|
|
|
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
|
|
For some reason relations can not always be found. This is to be
investigated, but doesn't hurt to be safe here. Also allows to
unlock production.
|
