Before it was only doing this for directly linked objects. This was
initially needed to solve fps issues in some of the shots. Now this
fps drop i can no longer reproduce. Was likely needed prior to
modifiers dependencies "inheriting" visibility from the "parent".
This commit makes it so objects which are linked indirectly to the
scene via collections are properly considered visible (or, rather,
evaluatable) by dependency graph.
Solves missing eyelashes and braids issues with 01_035_A.
Normally the time can be read from DEG_get_ctime(depsgraph), but this is a
bit more forgiving for e.g. addons that don't care too much about the details
of the COW depsgraph.
Previously it was possible to have geometry component to
tag batch for DIRTY_ALL and shading to tag with SHADING_UPDATE.
Now there is a relation between uber eval and shading, which
solves this issue.
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.
