Previously each of the objects which has armature modifier will
request deformation matricies from bbones. Thing is, all those
deformations are the same and do not depend on object which is
being modified. What's even worse is that this calculation is
not cheap.
This change makes it so bbones deformation is calculated once
and stored in the armature object. After this armature modifiers
simply use it.
With a rigs we've got here dependency graph evaluation time
goes down from 0.02 sec to 0.012 sec.
Possible further optimization is to make bbone deformation
calculated at the time when bone is calculated. This will avoid
an extra threaded loop over all bones.
The issue was caused by dependency cycle solver killing relation
which was guaranteed various things: i.e. copy-on-write component
orders and pose evaluation order (which must first run pose init
function).
Now it is possible to prevent such relations from being ignored.
This is not a complete fix, but is enough to make this specific
rig to work. Ideally, we also need to run copy-on-write operation
prior to anything else.
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.
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.
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.
We already had a BKE_main.h header, no reason not to put there
Main-specific functions, BKE_library has already more than enough to
handle with IDs and library management!
NLA strips are users of their action, so we need to pass along ID
management flags.
This commit also cleans up a bit things by passing along ID_CREATE/COPY
flags instead of dummy booleans...
If there was a dependency cycle involved, it was possible that pchan
array will be freed before all bones are evaluated. Now clear is
done in a dedicated node, which is never a part of dependency cycle.
The Nearest Surface Point shrink method, while fast, is neither
smooth nor continuous: as the source point moves, the projected
point can both stop and jump. This causes distortions in the
deformation of the shrinkwrap modifier, and the motion of an
animated object with a shrinkwrap constraint.
This patch implements a new mode, which, instead of using the simple
nearest point search, iteratively solves an equation for each triangle
to find a point which has its interpolated normal point to or from the
original vertex. Non-manifold boundary edges are treated as infinitely
thin cylinders that cast normals in all perpendicular directions.
Since this is useful for the constraint, and having multiple
objects with constraints targeting the same guide mesh is a quite
reasonable use case, rather than calculating the mesh boundary edge
data over and over again, it is precomputed and cached in the mesh.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D3836
The main use one can imagine for this is adding tweak controls to
parts of a model that are already deformed by multiple other major
bones. It is natural to expect such locations to deform as if the
tweaks aren't there by default; however currently there is no easy
way to make a bone follow multiple other bones.
This adds a new constraint that implements the math behind the Armature
modifier, with support for explicit weights, bone envelopes, and dual
quaternion blending. It can also access bones from multiple armatures
at the same time (mainly because it's easier to code it that way.)
This also fixes dquat_to_mat4, which wasn't used anywhere before.
Differential Revision: https://developer.blender.org/D3664
The key used by find_operation consists of the operation code,
node name, and an index for array property drivers. All three
elements are required to unambiguously look up a node.
- Use the original ID pointer for lookup in DEG_get_eval_flags_for_id.
- When the flags change after a DEG rebuild, tag the object for update.
- Instead of mixing int and short in different places, use uint32_t.
This fixes text not updating when a Follow Curve reference is set.
- Use smooth normals to displace in Above Surface mode.
- Add an option to align an axis to the normal in the constraint.
I've seen people request the alignment feature, and it seems useful.
For the actual aligning I use the damped track logic.
In order to conveniently keep mesh data needed for normal
computation together, a new data structure is introduced.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D3762
There were a few copies of the same few lines in depsgraph build code,
so it seems to be logical to introduce a function for it, and make it
accessible from C code for completeness.
As an example, register the mask needs of the Data Transfer modifier.
Before it was only doing this for directly linked objects. This was
initially needed to solve fps issues in some of the shots. Now this
fps drop i can no longer reproduce. Was likely needed prior to
modifiers dependencies "inheriting" visibility from the "parent".
This commit makes it so objects which are linked indirectly to the
scene via collections are properly considered visible (or, rather,
evaluatable) by dependency graph.
Solves missing eyelashes and braids issues with 01_035_A.
