This makes evaluated objects to point to a non-evaluated collection,
which is already really bad. What is even more worse, objects in those
collections are not evaluated either.
Proper solution would be to implement visibility flag for nodes, which
will be set to 0 for transform/geometry components, but which will be
1 for copy-on-write components.
This way we will guarantee consistency of dependency graph.
For now this change is good enough and unlocks production.
Fixes T55375: Crash when changing visibility of instanced collection
Fixes T55357: Particle geometry crash
This is a beginning of series of commits which will clearly separate
building IDs which are used as object data from object building.
The goal is to be able to always build whatever ID. Required to make
driver targets to work reliably with copy-on-write concept.
DATA datablock must evaluation must never depend on object it is
used for. If there is something what depends on an object, it must
be done on object level.
At least the actual callback was empty.
Make it more reliable and predictable way of getting pointer to
an original mesh which came from copy-on-write engine.
Related change: made it (hopefully) more clear name for flags.
This includes:
- Skip OB_RECALC_TIME tag from object duplicate operator
not sure why it is needed: even if original object was
animated, duplicating it will copy evaluated values.
- Don't tag whole ID for update when updating it after
relations rebuilt. Use the same trickery to detect
whether animation is to be re-evaluated or not as is
done for update flag=0.
- Don't tag datablocks which are expanded for update
of copy-on-write.
- Avoid flush along relation from copy-on-write
operation in action. This will not invalidate any
pointers in the copied datablock since we don't
reference anything in the action.
When active dependency graph is evaluated, it will apply animation,
drivers and scalar evaluation data (such as object matrix) to an
original datablock. This way operators and tools can easily read
data from original datablock.
This will simplify porting them to copy-on-write, and solve issues
when some operator will allocate new datablock based on original one,
and will want to read data from it.
After discussion with Sergey and Dalai, we have decided to remove
this option completely. We're getting to the point where it is almost
impossible to really use 2.8 without COW, and keeping the old option
running ends up diverting dev resources away towards tracking down
and fixing problems with a parallel system that will be going away.
This introduces a new depsgraph API for getting updated datablocks,
rather than getting it from bpy.data.
* depsgraph.ids_updated gives a list of all datablocks in the depsgraph
which have been updated.
* depsgraph.id_type_updated('TYPE') is true if any datablock of the given
type has been added, removed or modified.
More API updates are coming to properly handle multiple depsgraphs and
finer update granularity, but this should make Cycles work again.
This is a first step to have correspondence of legacy derivedDeform
within a new formulation. Only base ground for now to support file
reading, copy-on-write remapping and such.
