Use more generic id->recalc flag.
Also sanitize flag flush from settings to particle system.
Need to do such flush before triggering point cache reset, since
point cache reset will do some logic based on what flags are set.
This will solve crash caused by threaded update which will set
some bitflags while point cache reset is in progress.
It is possible that datablock will not be re-used for the new
dependency graph building. Freeing function was freeing all
the nested pointers of databnlock, but not datablock memory
itself.
Introduced explicit ID property node for driers in depsgraph,
so it is clear what is the input for driver, and what is the
output.
This also solved relations builder throwing lots of errors
due to ID property not being found.
It was possible to have relations like A -> B -> C -> A (import thing is
that no other operations points into this cluster) which were not detected
or reported by dependency cycle solver.
Now this is solved by ensuring we don't leave unvisited nodes behind.
This allows us to:
- Not mock around with tags stored in a global space,
and not to iterate over all datablocks in the database
to clear the tags.
- Properly deal with datablocks which might not be in main database.
While it sounds crazy, it might be handy when dealing with preview,
or some partial scene updates, such as motion paths.
- Avoids majority of places where depsgraph construction needed bmain.
This is something what could help in blender2.8 branch.
From tests with production file here did not see any measurable slowdown.
Hopefully, there is no functional changes :)
Not sure why we need a relation from solver to a tip local transform, this
will be handled via parent relation.
Fixes remaining dependency cycles reported in T54083.
This is kind of doesn't matter where macro itself is defined.
We should stick to the following:
- If some macro is actually more an inline function, follow regular
function name conventions.
- If macro is a macro, type it in capitals. Use module prefix if that
helps readability or it if helps avoiding accidents.
This fixes an issue where old cache data was used after an object has been moved.
Particles were coming from very wrong positions. Reproduction case is to move an
object while animation is running and then let the animation loop back and
play again.
Differential Revision: https://developer.blender.org/D3044
The reason it appeared working was due to left-over debug code to force
time dependency.
Real fix seems to include force tagging objects used by duplication,
similar to what we do for some other modifiers already.
Was happening when viewport visibility on the particle system is disabled.
This became an issue after c45afcf, but the actual issue goes a bit deeper
and the following aspects were involved:
- Relations builder for particle system was ignoring particle system if
it's visibility is not enabled for viewport. This is something what
shouldn't have been done -- depsgraph relations are supposed to be the
same no matter if it's viewport or render.
- Relation builder was only dealing with duplication set to object, but
was ignoring group duplication.
This is technically a regression in 2.79a-RC as well, so would need to
backport this fix to the branch after extra testing is done here in the
studio.
The new depsgraph was only considering the active action
when attaching relations from the AnimData component/operation
to the properties that are affected by the animation data.
As a result, only properties animated by the active action
were working, while those animated by NLA strips did not change
when playing back/scrubbing the timeline.
This commit fixes this introducing a recursive method to properly
visit all NLA strips, and calling DepsRelBuilder::build_animdata_curves_targets()
on each of those strips.
It is possible to have animation (or driver) to modify nested datablock, such
as shape key value for example (where animation is on Mesh level, but shape key
is it's own datablock). To deal with such cases we need to create relation
from nested datablock CoW to animaiton/driver operation.
One thing i'm not fully happy with is all this is_same_* functions. Need to
get rid of this by probably adding explicit entry/init/whatever nodes and
maybe making node criteria aware of whether key will be used as "from" or
as "to" node.
Before we were re-using newid pointer inside of ID structure where we were
storing pointer to an original datablock.
It seems there is no way we can avoid requirement of having pointer to an
original datablock, so let's stop obusing system which was only designed to
be a runtime only thingie. Will be more safe this way, without need to worry
about using any API which modifies newid.
