Age | Commit message (Collapse) | Author |
|
|
|
disabled subcollections
Root of the issue was actually hidden deep in depsgraph itself: it would
not properly update all of its COW IDs using a datablock when depsgraph
decides to evaluate or un-evaluate it.
This would lead to evaluated IDs pointing to either:
- orig IDs when there was an evaluated version of those (annoying bug,
but not a crashing one).
- old address of previously evaluated IDs that no longer exists in the
depsgraph (causing the crash from the report e.g.).
This commit adds an extra step at the end of nodes building, that goes
over all of already existing IDs in the depsgraph to check whether they
do one of the two things above, and tag them for COW update if so.
NOTE: This only affects depsgraph (re-)building, not its evaluation.
This remains consistent with the fact that operations that may change
the depsgraph content (like Collection exclusion etc.) need to trigger a
rebuild.
NOTE: Performances: Worst case scenarii, like (un-)excluding a whole
character collection in a production file, lead to 5% to 10% extra
processing time in depsgraph building. Most of it comming from extra COW
processing (in depsgraph's update in `build_step_finalize`), the detection
loop itself only accounts for 1% to 2% of the whole building time.
Maniphest Tasks: T85752
Differential Revision: https://developer.blender.org/D10907
|
|
Building IDs which are not covered by copy-on-write process was not
implemented, which was causing parameters block not present, and, hence
causing crashes in areas which expected parameters to present.
First part of this change is related on making it so Copy-on-Write is
optional for ID nodes in the dependency graph.
Second part is related on using a generic builder for all ID types
which were not covered by Copy-on-Write before.
The final part is related on making it so build_id() is properly
handling ParticleSettings and Grease Pencil Data. Before they were not
covered there at all, and they need special handling because they do
have own build functions.
Not sure it worth trying to split those parts, as they are related to
each other and are not really possible to be tested standalone. Open
for a second opinion though.
Possible nut-tightening is to re-organize build_id() function so
that every branch does return and have an assert at the end, so that
missing ID type in the switch statement is easier to spot even when
using compilers which do not report missing switch cases.
As for question "why not use default" the answer is: to make it more
explicit and clear what is a decision when adding new ID types. We do
not want to quietly fall-back to a non-copy-on-write case for a newly
added ID types.
Differential Revision: https://developer.blender.org/D10075
|
|
Revert "Fix T83411: Crash when using a workspace/layout data path in a driver"
The fix for the crash exposed design violation in the viewport shading updates,
which is for some reason relying on dependency graph tag of interface data.
The viewport module did not respond to the issue in 2 weeks, and the architect
considered missing update for multiple users a more serious issue than a crash
in a very specific case.
This reverts commit 0f95f51361d73fbd8ba8d80b3b65da930dcf3b20.
|
|
Building IDs which are not covered by copy-on-write process was not
implemented, which was causing parameters block not present, and, hence
causing crashes in areas which expected parameters to present.
First part of this change is related on making it so Copy-on-Write is
optional for ID nodes in the dependency graph.
Second part is related on using a generic builder for all ID types
which were not covered by Copy-on-Write before.
The final part is related on making it so build_id() is properly
handling ParticleSettings and Grease Pencil Data. Before they were not
covered there at all, and they need special handling because they do
have own build functions.
Not sure it worth trying to split those parts, as they are related to
each other and are not really possible to be tested standalone. Open
for a second opinion though.
Possible nut-tightening is to re-organize build_id() function so
that every branch does return and have an assert at the end, so that
missing ID type in the switch statement is easier to spot even when
using compilers which do not report missing switch cases.
As for question "why not use default" the answer is: to make it more
explicit and clear what is a decision when adding new ID types. We do
not want to quietly fall-back to a non-copy-on-write case for a newly
added ID types.
Differential Revision: https://developer.blender.org/D10075
|
|
The root of the issue was caused by the dependency graph using ID pointer
to map evaluated state from old depsgraph to new one upon relations update.
This was failing when IDs were re-allocated rapidly: was possible that
Object ID's evaluated state assigned to Mesh and vice versa.
Now depsgraph uses Session UUID to identify which IDs to restore evaluated
state to. The session UUID is stored in the IDNode, so that id_orig is not
dereferenced on depsgraph update since the ID might be freed.
The root of the issue is identified by Campbell, original patch was done
by Bastien, thanks! Also thanks to Oliver and Ray and everyone else for
testing!
|
|
|
|
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D8150
|
|
A driver reading `Object.hide_viewport` would break when that object was
hidden. Hidden objects don't have the `OBJECT_BASE_FLAGS` node in the
depsgraph, but that node was required for the driver to work.
Now the `OBJECT_FROM_LAYER` component (which optionally contains the
`OBJECT_FROM_LAYER` node) has explicit `ENTRY` and `EXIT` nodes, which
are used for relations with other components. These relations now remain
valid, even when the `OBJECT_FROM_LAYER` node is absent.
Differential Revision: https://developer.blender.org/D8124
Reviewed By: sergey
|
|
It turns out that
`DepsgraphNodeBuilder::build_object_data_geometry(Object *object, bool
is_object_visible)` was called for the custom shape with
`is_object_visible=false` when there are drivers, and
`is_object_visible=true` when there aren't any.
|
|
We decided that `blender::Vector` should be the default choice for
a vector data structure in Blender.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7981
|
|
|
|
Conflicts:
source/blender/blenkernel/intern/lib_query.c
source/blender/depsgraph/intern/builder/deg_builder_relations.cc
|
|
Fix T75279: BLI_assert failed when deleting object in debug build
(only).
And all general cases of ID pointer idproperties that would use a
data-block not referenced anywhere else in the depsgraph.
This includes idproperties from:
* All ID types;
* Bones and pose bones;
* Sequences;
* Nodes and sockets.
Differential Revision: https://developer.blender.org/D7551
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7519
|
|
This data block will be the container for simulation node trees.
It will be used for the new particle node system (T73324).
The new data block has the type `ID_SIM`.
It is not visible to users and other developers by default yet.
To enable it, activate the cmake option `WITH_NEW_SIMULATION_TYPE`.
New simulation data blocks can be created by running `bpy.data.simulations.new("name")`.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7225
|
|
More detailed symptoms: there was no curve cache created for an object
which was used by draw manager.
A bit tricky situation, which involves collection instances and their
proxies.
The root of the problem in the dependency graph was that instanced
collections visibility was not updated when object is requested with
different visibility. So what was happening is that one of the objects
was pulled as an indirect dependency of something invisible, so it
built instanced collections as if the instancer is invisible. After
that the same object was built as visible. Before this fix this was
only update object flags, the instanced collections still believed they
are invisible. Since there is no path via relations which would connect
visible object with instanced objects the visibility flush which is
happening during graph finalization did not "fix" the visibility flags.
This change makes it so instanced collections are updating their
visibility when their instancer's visibility is changing to truth.
This is similar to how collections will accumulate their visibility
when same collection is used from multiple ones with different
visibility.
However, this alone wasn't enough to get crash fixed. This marked
collections as visible, but the geometry component of the curve object
was still considering self as invisible.
This is something tricky, since the code which is responsible for this
issue was added as an optimization in afb4da6650d. This looks like like
an oversight in that commit since it's rather weird that ID node's
flag would depend on construction order (in "normal" object builder the
ID node's directly_visible flag is initialized to object's visibility).
So it seems logical to get this part of code in sync between "regular"
and "accumulative" object builder.
And last but not least the naming is_directly_visible is old and does
not really represent what it actually mans now: a more correct name
would be "will be used by the draw manager".
Differential Revision: https://developer.blender.org/D7217
|
|
This fixes an issue where drivers using `object.dimension` only add a dependency on `GEOMETRY` to the depsgraph, whereas they should also depend on `TRANSFORM`.
This patch adds a new no-op operation that depends on the geometry and transform components to the Parameters component.
An alternative implementation would be to have `RNANodeQuery::construct_node_identifier` return multiple node identifiers. However, this would spread throughout the depsgraph code and unnecessarily force many other functions to either return or handle multiple nodes where in 99.999% of the time a single node would suffice.
The new `DIMENSIONS` node is added for each object. An upcoming patch will go over all no-op operation nodes and remove them from the depsgraph. Since this is a more dangerous operation, it'll be reviewed separately.
Differential Revision: https://developer.blender.org/D7031
|
|
No functional changes.
|
|
FreeStyle line styles were not part of the dependency graph, and
blacklisted from the Copy-on-Write system. As a result, animated
FreeStyle properties would not be updated by the animation system,
resulting in T72213. There was an explicit call to run the animation
system on the original datablocks, but that was (for good reasons)
removed in D5394.
This commit adds the FreeStyleLineStyle datablocks to the dependency
graph and allows them to be handled by the CoW system. As a result
- the UI now updates properly when properties are animated, and
- animated property values are actually used when rendering.
This commit includes @Sergey's patch P1222, which unifies two bits of
code that did the same thing: check whether datablock type is covered by
copy-on-write.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D6609
|
|
Allows to override behavior in a subclasses.
Currently no functional changes. The penalty of calls being virtual
should be neglectable.
|
|
Currently no functional changes, but allows to make it more clear to
implement depsgraph construction from a given subset of scene.
|
|
|
|
|
|
The root of the issue comes to the fact that part of dependency graph
is being removed, without doing any further remapping.
This was happening because only materials used by objects were pulled
in, so when material mode is changed some material became unused and
removed from the dependency graph and freed, causing object or its
data to point to a freed memory in its materials array.
Simplest and safest way to solve this is to pull materials referenced
by both object and object data. This causes somewhat higher memory
usage but keeps evaluated state of scene in an always consistent state,
without any need to tag/update object's data on material mode change.
Don't think it is a problem in practice.
Reviewers: brecht, fclem
Reviewed By: brecht, fclem
Differential Revision: https://developer.blender.org/D5172
|
|
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.
|
|
Need to pull in speakers from scene strips and make sure they
are properly updated.
|
|
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 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 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 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
|
|
The idea is to make that responsible for dealing with
things like audio update on frame jump and such.
|
|
Just adds sequencer operation and links possible sound ID to it.
No functional changes, just moving towards sound system integration
into the dependency graph.
|
|
Currently those IDs are not covered by copy-on-write mechanism since
that ruins the current design of BKE_sound, But this change allows to
move towards system where sound handlers are only valid for an evaluated
ID datablocks.
|
|
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
|
|
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
|
|
Just de-duplicates some logic. Should be no functional changes.
|
|
|
|
- BKE_lamp -> BKE_light
- Main.lamp -> light
|
|
Was once again caused by an ambiguity of the entry/exit operations.
Only did for objects since those are the only one who needs this.
The rest types of IDs needs to be checked and only added extra
operations if needed (adding operations and relations causes some
overhead for evaluation, so need to be careful).
|
|
The dependency graph now handles updating image users to point to the current
frame, and tags images to be refreshed on the GPU. The image editor user is
still updated outside of the dependency graph.
We still do not support multiple image users using a different current frame
in the same image, same as 2.7. This may require adding a GPU image texture
cache to keep memory usage under control. Things like rendering an animation
while the viewport stays fixed at the current frame works though.
|
|
The initial idea of using char pointer was to save some
memory since the dependency graph was kind of the one
with the main database.
Nowadays dependency graph should be separatable from the
main database and being self-sustainable.
Other issue which was caused by this pointer is the
re-tagging of operations during relations update: it is
possible to have node which as tagged for update but had
the owner of the name removed (i.e. driver or bone was
removed).
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
Missed when removing contributors.
|
|
Quite often we need to create nodes which defines various
evaluation stages.
|