The issue was happening because dependency graph did not inform particle
settings as modified. This is a regression caused by tagging and flushing
mechanism refactor.
The real fix would be to make particle settings to use ID level recalc flags
rather than own flags, which will also simplify relations around particle system,
and particle settings evaluation.
Reported by Mai in IRC.
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.
There was a fake cyclic dependency happening when node of node tree is driving
another node of the same tree.
This is related to T53794, but more fixes is needed here.
Helps in cases of not very complex scenes and lots of system threads available.
A bit hard to measure change on it's own, it works best with the upcoming
changes and gives measurable improvements.
Now all the fine-tuning is happening using parallel range settings structure,
which avoid passing long lists of arguments, allows extend fine-tuning further,
avoid having lots of various functions which basically does the same thing.
This allows a duplicator (as known as dupli parent) to be in a visible
collection so its duplicated objects are visible, however while being
invisible for the final render.
An object that is a particle emitter is also considered a duplicator.
Many thanks for the reviewers for the extense feedback.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2966
This statistics is only collected when debug_value is different from 0.
Stored in depsgraph node itself, so we can always have access to average data
and other stats which requires persistent storage. This way we also don't waste
time trying to find stats from a separately stored hash map.
This is something deliver form node type, there is no reason to try cache it
anywhere, especially since it's not used in any performance critical code.
Lighter weight dependency graph is what we want.