Fix T61406: Particles don't render
Consider initial dependency graph evaluation as a file load.
Is still resetting too much, but that we can solve later.
Also update relations when modifier texture changes.
Basically same as rB6e00415a85a9, rBca2680aaeb1 but this time for
VertexWeight modifiers
Reviewers: sergey
Maniphest Tasks: T61185
Differential Revision: https://developer.blender.org/D4305
We may want to use 'TEST' BCode in the future for including data
besides thumbnails. This allows negative values to be used w/o
attempting to load a thumbnail.
Currently the preferences have both tweak and drag threshold,
this is confusing because most actions users would consider
dragging use the 'tweak' setting.
Now one drag threshold is used for both, with a maximum limit of half
the button unit-size in case of dragging UI elements.
Also added keys for toggling harden normals,
and cycling through miter types.
Still to do: add some shortcuts for affecting the
spread value for arc miters.
Most artists agree that RGB by default is not as flexible as HSV.
It's just the first time it opens anyway, since it will remember whatever
was set last like it always does.
When one is indirectly linking collections, better add collection to the
scene, than instantiating its objects into master collection of the
scene. That is much cleaner.
Noted/related to T61141.
Issue is, ob->id.us is not relevant anymore here, since several
collection might be referencing it inside of a same scene, that is still
only one usage from user perspective...
Note that for now we are just counting scenes instantiating an object,
time will say wether we need more refined/complete check (as a reminder,
most [all?] other Object usages are *not* refcounting ones).
Yes, we do can undo an ID deletion now.
However, this requires extra care in UI 'remapping' to new IDs step
(when undoing, we do not fully reload the UI from saved .blend).
Otherwise, new UI (i.e. one from saved .blend file) might reference
IDs that where freed in old bmain (the one before the undo), we cannot
use those to get ID name then, that would be a nasty use-after-free!
To prevent this, we generate a GSet of all valid ID pointers at that
time (i.e. those found in both old and new Main's), and ensure any ID
we try to remap by its name is in that GSet. Otherwise, there is no
possible remapping, just return NULL.
While ideally we could have a complete detailed list of deleted IDs,
that would require more work UI wise, think for now we can live with
just a rough summary.
Related to T61209.
make_duplis_collection() depends on the collection object cache,
which was not freed upon object viewport disable change.
The best way to reproduce the bug was to instance the default
collection, disable the cube, save and re-open the file.
Now even if you set the original cube to be enabled, you wouldn't see
the instanced one until you forced collection cache to be freed (e.g.,
changing a collection disable state.
Fix T61289: Emitting particles from instances not working properly
The first issue has been re-introduced by a code which was dealing
with missing hair after opening the file. That was re-setting all
particle systems all the time because modifier flags were not copied
back to original. This made every modifier run to be seem as an
initial file open.
Now we copy flags back to an original modifier. But also we are
trying to not do any resets unless needed in that case. This way
we can preserve in-memory caches.
Other part of the change is related on re-setting particle system
if number of mesh elements changed. But we only do it if the
modifier has been already evaluated once.
Mainly 'X' icon for Delete, which was already on modifiers and constraints,
but not for objects. Select icon for object selection and refresh for library reload.
