I only specified the identifiers for the units that are actually accessible for now.
This way we can postpone some decisions for now. E.g. if it should be `METER_SQUARE`, `SQUARE_METER`, `METER_SQ`, ...
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3945
Tssst… that piece of code should have been removed when we got rid of
bases here, kind of obvious it would break if object pointer itself is
NULL! And since deleting an object clears its ID pointers in outliner
tree, this fixes for free the issue of deleting several time the same
object (being selected in several collections at once).
Do early output when trying to add target relation with wrong rna_path.
We can't do anything reliably in that case anyway, so hopefully it is
a no-functional-change for artists, just avoids noisy error prints in
the terminal.
The constraint is supposed to automatically initialize the rest
length when it is first evaluated, so now that evaluation is done
on a separate copy it also has to copy the value to the master
instance - or newly created constraints will be broken.
Since this is supposed to happen once at constraint creation,
implementing as a search for now instead of adding new fields.
This finished old standing TODO which was attempting to
ignore objects of all invisible collections.
The difference here is that we remove invisible bases from
view layers. This guarantees that the evaluated state is
consistent and does not reference original objects.
Rig generators (e.g. rigify) use dummy drivers to attach extra
ID references to rigs for Append/Link. These references use
Single Property variables with empty path, which is intentionally
invalid and shouldn't produce low-level error logs from depsgraph.
The removed code would always print an error because RNAPathKey
requires a valid path to produce a non-NULL reference.
It appears that Python gets next item before using current one, which
would break our Depsgraph instance iterator (since only current item is
valid there, we use the same memory at each iteration).
Working around that with an ugly ping-pong game between two sets of
iterator data, so that previous one (C RNA-iterator-wise) remains valid
memory for Python to access to.
Logical flaw in `BKE_scene_objects_iterator_begin()` code (two errors
actually, wrong handling of first object of Master collection, and
missing call to `object_base_unique()` to 'register' that first object
and avoid getting it returned a second time).
Simply fixed by always calling `BKE_scene_objects_iterator_next()`
after minimal proper init, that one knows how to do the things. ;)
With the current implementation it only confuses logic around
checks like vewport/render subdivision levels.
If this mode is really needed for any decision making, implement
this properly.
Among all the lines moved around, the general idea is quite simple.
Actually, there are two ideas implemented there.
First one, is when object itself is tagged for update, we tag its
point cache component for evaluation, which makes it so point cache
is properly reset. We do it implicitly because otherwise we'll need
to go everywhere and add explicit tag in almost all the properties.
Second thing is, we link all collider and force fields to a point
cache component using special type of link. This type of link only
allows flush if change is caused by a user update. This way reset
does not happen when change is caused due to animation, but will
properly happen when user causes indirect change to the objects
which are part of physics simulation.
