This is in preparation of new object types. This only changes mesh_eval, we
may do the same for mesh_deform_eval and other areas in the future if there is
a need for it.
Differential Revision: https://developer.blender.org/D6695
This fixes {T70269}.
Before this commit there was complicated code to try and compute the
correct parent inverse matrix for the 'Child Of' and 'Object Solver'
constraints outside the constraint evaluation. This was done mostly
correctly, but did have some issues. The Set Inverse operator now defers
this computation to be performed during constraint evaluation by just
setting a flag. If the constraint is disabled, and thus tagging it for
update in the depsgraph is not enough to trigger immediate evaluation,
evaluation is forced by temporarily enabling it.
This fix changes the way how the inverse matrix works when some of the
channels of the constraint are disabled. Before this commit, the channel
flags were used to filter both the parent and the inverse matrix. This
meant that it was impossible to make an inverse matrix that would
actually fully neutralize the effect of the constraint. Now only the
parent matrix is filtered, while inverse is applied fully. As a result,
pressing the 'Set Inverse' matrix produces the same transformation as
disabling the constraint. This is also reflected in the changed values
in the 'Child Of' unit test.
This change is not backward compatible, but it should be OK because the
old way was effectively unusable, so it is unlikely anybody relied on
it.
The change in matrix for the Object Solver constraint is due to a
different method of computing it, which caused a slightly different
floating point error that was slightly bigger than allowed by the test,
so I updated the matrix values there as well.
This patch was original written by @angavrilov and subsequently updated
by me.
Differential Revision: https://developer.blender.org/D6091
This un-indents the `childof_evaluate()` function by one level, making it
easier to add new functionality in an upcoming commit.
No functional changes.
The Alembic importer now works with local coordinates. Previously, the
importer converted transformations from Alembic to world coordinates
before processing them further; this processing often included
re-converting to local coordinates. This change made it possible to
remove some code that assumed that a child transform was only read after
its parent transform.
Blender's Alembic code follows the Maya convention, where in the zero
orientation the camera looks forward instead of down. This extra
rotation is now handled more consistently, and now also properly handles
children of cameras. This fixes T73269.
Unit tests were added to at least ensure that the importer and exporter
are compatible with each other, and that static and animated camera
transforms are handled in the same way.
Don't use BKE_view_layer_context_active_PLACEHOLDER which is marked
as "never use this".
In fact, it isn't needed to lookup for camera in the tracking function
at all: camera object is always explicitly passed to it.
Constraint stack similarly to modifier stack is fully operate on what
have been given to it, without requesting original or evaluated IDs.
Validness of datablocks passed to constraint stack are to be handled
on dependency graph/evaluation stream levels.
Currently the action channels are applied after the existing
transformation, as if the action controlled a child of the
bone. This is not very natural, but more importantly, the
transform tools are not designed to work conveniently with an
additional 'pseudo-child' transformation, resulting in effects
like an unexpected pivot location.
Implementing a Before mode that integrates the action channels
as if applied to a parent allows using the special transform
tool code intended for dealing with such constraints.
Note that in either mode, Action constraints should be added
in reverse order, putting a new constraint before the existing
ones that the Action was keyframed to work together.
In order to implement the option, extract a utility from
the Copy Transform constraint code for combining transforms
with special anti-shear scale handling that matches the
Aligned Inherit Scale mode.
The Before mode also requires switching the constraint to
the Local owner space, while the After mode can still use the
World space for efficiency as before. Since the constraint
doesn't have an Owner space option in the UI, this has to be
handled in an RNA setter.
For full backward compatibility, the original simple matrix
multiplication mode is preserved as the third option, but it
is not recommended due to creating shear.
Differential Revision: https://developer.blender.org/D6297
Most of the time Stretch To is used in actual rigs, like BlenRig
or Rigify, in combination with Damped Track to handle rotation
before the stretch, because it produces rotations more appropriate
for organic deformation, and doesn't flip because of internal
gimbal lock.
The prevalence of this pattern suggests that Stretch To should
support that kind of rotation directly as an option.
Differential Revision: https://developer.blender.org/D6134
Combine computing `size` and normalizing the matrix, invert the
direction of `vec` to avoid negating it later, use `rescale_m4`
instead of matrix multiplication to scale the final result.
Differential Revision: https://developer.blender.org/D6134
In 2011 special handling was introduced, apparently for no other
reason than to address a complaint in T25707 that World and Local
space are equivalent for objects without parent. This causes issues
and confusion, as mentioned in rB599c8a2c8e4.
This special meaning of Local Space is not documented in the manual,
and is not known to experienced riggers, so removing it should not
be a problem.
Differential Revision: https://developer.blender.org/D6095
Allow selecting how the new location/rotation/scale is combined with
the existing transformation. This is most useful for rotation, which
has multiple options, and scale, which previously could only replace.
Allow combining location, rotation and scale at the same time,
using one constraint. The mixing modes are based on matrix
multiplication, but handle scale in a way that avoids creating
shear.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5640
Upon close inspection, the way the Offset mode works in the
Copy Rotation constraint makes no sense, and in fact, destroys
the rotation of its owner unless either it's single axis, or
the order is set specifically to `ZYX Euler`.
Since it can't simply be changed because of backward compatibility
concerns, replace the checkbox with a dropdown that provides a set
of new modes that actually make sense.
Specifically, add a mode that simply adds Euler components together,
and two options that use matrix multiplication in different order.
The Python use_offset property is replaced with compatibility stubs.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5640
For reasons similar to drivers, it should be possible to set an
explicit Euler rotation order in constraints that use Euler angles.
The Transform constraint in a way approaches drivers in its use,
in that it effectively alters channels using values of other
channels after applying a fixed form mathematical expression.
For this reason, instead of just specifying the euler order for
its inputs, it uses the same enum as driver variables. However
Quaternion components are converted to a weighted pseudo-angle
representation as the rest of the constraint UI expects angles.
Uniform scale is superior to non-uniform scale in that it works with
parenting without causing shear. Thus it is a valid desire in some
cases to turn arbitrary scale into guaranteed uniform scale.
Implementing this in the Copy Scale constraint allows one for instance
to 'inherit scale as uniform' by disabling Inherit Scale, and using
Copy Scale from parent with Offset and Make Uniform.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5614
This option from the very beginning of its existence needed more work
to make it work correct and this was never done.
This option was working fine during continuous playback, when there
are no skipped frames, but it was failing when AV-sync of framedrop
was enabled.
It was never working correct when jumping between frames, including
rendering on a farm which usually does frame-range based rendering.
With copy-on-write things became even more tricky, since the "stuck"
flag was never preserved between re-evaluations.
Fixes T65683: Sticky Option in Floor Constraint for Bones Not Working
Better to make internal code naming match official/UI naming to some
extent, this will reduce confusion in the future.
This is 'breaking' scripts and files that would use that feature, but
since it is not yet officially supported nor exposed in 2.80, as far
as that release is concerned, it is effectively
a 'no functional changes' commit.
This also makes `IDP_CopyProperty` the "opposite"
of `IDP_FreeProperty`, which is what I'd expect.
Two refactoring steps:
* rename IDP_FreeProperty to IDP_FreePropertyContent
* new IDP_FreeProperty function that actually frees the property
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4872
This constraint requires full bone data to evaluate, so it can't
use the generic single target matrix system. Calculating it is
thus useless waste of CPU time.
Since scale is multiplicative, the appropriate way to partially copy
it is to use power. However, the influence slider of constraints uses
linear interpolation. Thus, there is no way to correctly split scale
via constraints without adding this feature.
In addition, this allows inverting scale by using negative powers,
fulfilling the function of Copy Rotation's Invert checkboxes.
Add a new option that makes the Spline IK solver apply volume
preservation on top of the original scaling, considering the
pre-IK scale of the bone as the goal volume to be preserved.
This basically works similar to the Stretch To constraint, and
allows easily rigging a stretchy chain that uniformly follows
its parent's scaling.
Since the Stretch To behavior is more familiar, the new option
is on by default for newly created Spline IK constraints.
After a lot of thinking about this, I decided that all operation modes
that I've tried over the past couple of years, including the original
2.79 one, have their uses after all. Thus the only reasonable solution
is to add yet another option.
The modes are:
- Strict: The current 2.80 mode, which overrides the original scaling
of the non-free axes to strictly preserve the volume. This is the most
obvious way one would expect a 'Maintain Volume' constraint to work.
- Uniform: The original 2.79 mode, which assumes that all axes have been
scaled the same as the free one when computing the volume. This seems
strange, but the net effect is that when simply scaling the object
uniformly with S, the volume is preserved; however, scaling the non-
free axes individually allows deviating from the locked volume.
This was obviously intended as a more or less convenient UI tool.
- Single Axis: My own variant of the intent of the Uniform scale, which
does volume-preserving if the object is scaled just on the Free axis,
while passing the non-free axis scaling through. I.e. instead of
uniform S scaling, the user has to scale the object just on its
primary axis to achieve constant volume. This can allow reducing the
number of animation curves when only constant volume scaling is needed,
or be an easier to control tool inside a complex rig.
* The cache file datablock is now evaluated as part of the dependency graph,
creating/freeing the Alembic file handle matching the current frame.
Modifiers and constraints depend on this evaluation.
* Cache file handles and readers now only exist on COW datablocks, never the
original ones.
* Object data paths are flushed back to the original for the user interface.
* The cache file keeps a list of all readers associated with its handle, and
automatically frees them when the handle is freed. This kind of sharing of
data across datablocks is weak but we have no better mechanism for it.
Fix T62720: Alembic sequences not working and crashing
Differential Revision: https://developer.blender.org/D4774
Previously Spline IK provided only two choices: either scale the
length of the bone chain to fit the length of the curve, or don't
scale the bone in the Y dimension at all (ignoring effects of
actually fitting to the curve due to curvature and curve object
scale).
This patch adds a new option to use the pre-IK Y scale of the
bones to adjust their length when fitted to the curve, allowing
individual posing control over the length of the segments.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4687
Previously B-Bone deformation mapped every vertex to just one
B-Bone segment. This results in abrupt transformation differences
between the sides of each threshold plane, reducing the quality
of B-Bone deformation and making the use of shape keys impractical.
This commit replaces this approach with a linear blend between
the two closest segment transformations, effectively representing
the B-Bone as two weight-blended plain bones for each vertex.
In order to distribute the interpolation more evenly along the
bone, segment matrices for deformation are now computed at points
between the segments and at the ends of the B-Bone. The computation
also uses the true tangents of the Bezier curve for the orientation.
The nodes at the end of the bone require some special handling to
deal with zero-length Bezier handles caused by a zero ease value.
The Copy Transforms constraint now also smoothly interpolates
rotation and scaling along the bone shape when enabled.
The initial version of the patch was submitted by @Sam200.
Differential Revision: https://developer.blender.org/D4635
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
This commit makes it so curve path parent solving accepts an explicit
arguments for both time and curve speed flag, making it so we don't
have to mock around with scene's frame.
One unfortunate issue still is that if the instancing object is used
for something else, we might be running into a threading conflict.
Possible solution would be to create a temp copy of an object, but
then it will be an issue of preventing drivers from modifying other
datablocks.
At least the original issue is fixed now, and things behave same as
in older Blender version. Additionally, the global variable which
was defining curve speed flag behavior is gone now!
There were at least three copies of those:
- OB_RECALC* family of flags, which are rudiment of an old
dependency graph system.
- PSYS_RECALC* which were used by old dependency graph system
as a separate set since the graph itself did not handle
particle systems.
- DEG_TAG_* which was used to tag IDs.
Now there is a single set, which defines what can be tagged
and queried for an update. It also has some aggregate flags
to make queries simpler.
Lets once and for all solve the madness of those flags, stick
to a single set, which will not overlap with anything or require
any extra conversion.
Technically, shouldn't be measurable user difference, but some
of the agregate flags for few dependency graph components did
change.
Fixes T58632: Particle don't update rotation settings
