The idea of those flags is to avoid evaluation of operations
which are not needed to bring visible objects to an up to date
state.
Previously, dependency graph attempted to do combine those
into an ID level flag. In practice it proved to be rather
tricky, since there could be dependency cycles on ID level
which will not exist on component level.
This allows to force duplicated object to be fully evaluated for
display/draw.
Previously only transform component of duplicated object was
forced to become evaluated.
Need to ensure objects from collection which was built but
is became visible in the new "context" are poked for re-built.
This should be rather cheap, since this only will update
their visibility flag.
Can not rely on visibility flush here, since there is no
relations between collection and its objects.
Avoids invisible objects from being considered visible when they
are used as driver variables.
If those cases are actually coming from a visible object, then
deg_graph_build_flush_visibility() will ensure visibility is
properly flushed there.
If something is a list of data, it is to be called list, and data
is to be called data. No need to call list a data and data a weird
two letter abbreviation.
Clarity is our friend!
Was happenign for following cases:
- Deep hierarchy of non-restircted collections, which has grand-grand
parent restricted.
- Collections which are constructed from invisible object.
The title says it all actually, the idea is to speedup the following case:
- Visible duplicator of a restricted collection (reported as T56512),
One of the questionable change is that none of the view layer bases is
ignored now. This ensures corresponding objects will have copy-on-write
component evaluated, making it possible to access those pointers. The
evaluation of those objects is skipped.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3641
This was just randomly leaving all the Particle datablocks in the
filtered graph (and causing and extra/excess pass over the ID's
to get run). Unless we actually need those specially kept for
some reason later, it's better to leave those out for now.
* COW data hasn't been expanded yet when we try to filter the graph
(you need to have tagged + evaluated it for this data to exist),
so all the offending nodes would just get left in
* Added more debug prints to verify whether the id_nodes vector is
getting cleared correctly
* Simplified operation-relation deletion. Now we collect the relations
to delete into a vector, then iterate through that, thus solving issues
with iterator invalidation (+ aborts arising from that)
* DEG_foreach_ancestor_ID() was assuming that all dependencies were
OperationDepsNodes, when in fact, some could be TimeSource nodes
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 commit adds a new method, DEG_foreach_ancestor_ID()
to accompany the existing DEG_foreach_descendent_ID().
It can be used to help print/collect all the ID's that
a given ID block depends on (i.e. all the datablocks that
need to be evaluated before the datablock of interest can
be evaluated)
