| Age | Commit message (Collapse) | Author |
|---|
|
This patch fixes T63794 by updating duplicated bones' custom handle references
to point to the new armature's bones.
The problem occurs because B-Bones of a duplicated armature keep pointing to
the old armature's bones. The references are cleared upon entering Edit Mode
because there are no matching `EditBone` for such bones, and `find_ebone_link`
just returns `NULL` in such cases.
Reviewers: mont29, angavrilov
Maniphest Tasks: T63794
Differential Revision: https://developer.blender.org/D4726
|
|
|
|
|
|
As far as I can tell, there is no technical reason why the B-Bone
segment thickness scaling can't be separated into two axes. The
only downside is the increase in complexity of the B-Bone settings,
but this is inevitable due to the increase in flexibility.
Updating the file is somewhat complicated though, because F-Curves
and drivers have to be duplicated and updated to the new names.
Reviewers: campbellbarton
Subscribers: icappiello, jpbouza
Differential Revision: https://developer.blender.org/D4716
|
|
|
|
Now that B-Bone shape data is kept in bPoseChannel_Runtime, the
armature level cache only holds one quaternion value per bone.
It can also be moved to runtime, and the structure removed.
This has an additional effect that, as far as I can tell, now
the Armature modifier can run as soon as all of the bones it
actually needs are done, thus making T59848 a purely depsgraph
level problem.
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
Negate the second derivative, because it's effectively stepping back.
|
|
Use doxy references to function and enums,
also correct some names which became out of sync.
|
|
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
|
|
They are pointless copies from pchan->runtime by now.
|
|
Various dependency graph problems can cause obsolete data to reach the
armature modifier, so add checks to reduce the chance of crashing.
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
|
|
Was done everywhere except bPoseChannel.
|
|
Most of this code is deprecated for many years already and does not
work at all in Blender 2.8.
Reviewers: brecht, aligorith
Differential Revision: https://developer.blender.org/D4271
|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
|
|
That way it is obvious when we are using default ID copy behaviour, and
when we are using advanced/specialized ones.
|
|
Time to follow conventions for that one as well.
|
|
This was used in *one* place only... much better to have a dedicated
helper for that kind of things. ;)
|
|
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.
|
|
Part of D4277 by @sobakasu
|
|
|
|
This line looks a mistake and it's not needed.
|
|
Needed for clang formatting to workaround bug/limit, see: T53211
|
|
|
|
|
|
Helps separate variable names from descriptive text.
Was already used in some parts of the code,
double space and dashes were used elsewhere.
|
|
Applying the effect of bone parent is much more complicated than
simple matrix multiplication because of the various flags like
Inherit Scale. Thus it is reasonable to provide access to this
math from Python for complicated rest pose related manipulations.
The simple case of this is handled by Object.convert_space, so
the new method is only needed for complex tasks.
Differential Revision: https://developer.blender.org/D4053
|
|
|
|
|
|
Use BKE_pchan_bbone prefix.
|
|
B-Bone shape is a non-trivial computation, so access to
the results would be useful for Python scripts working with
B-Bones, e.g. rig generation.
This exposes both final segment matrices, and the tangent
vectors computed from the custom handle bones.
Since the handle tangents use the axis+roll orientation math
of edit bones, add matrix conversion static methods to Bone.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D3983
|
|
Computing the shape of a B-Bone is a quite expensive operation, and
there are multiple constraints that can access this information in
a variety of useful ways. This means computing the shape once per
bone and saving it is good for performance.
Since the shape may depend on the position of up to two other bones,
often in a "cyclic" manner, this computation has to be a separate
node with its own dependencies.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D3975
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
@jpbouza was rather upset these were made read-only, and unlike
parents, it's not that hard to allow changing these Bone fields:
all is needed is to carefully refresh the matching fields in the
relevant bPoseChannel objects and properly tag update.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3870
|
|
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D3802
|
|
|
|
This also fixes a stability problem with the start handle
due to an incorrect matrix multiplication order.
|
|
Both original handle types are based on location, and Absolute uses it
in a weird way: the Start handle uses the head, while End uses the tail.
This makes controlling the shape of the B-Bone via control bone rotation
really non-intuitive, especially if trying to add a single control for
the tangent in the middle of a B-Bone chain.
To remedy this, add a new custom handle type that uses the orientation
of the control bone, while completely ignoring location. It is even
possible to control both ends of one B-Bone with the same handle bone,
resulting in an S shape.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3769
|
|
Specifically, it should always use the position of the custom handle
bone head, even when affecting the handle at the tail of the main bone,
and shouldn't apply the special handling for joining two B-Bones.
This handle type was unusably broken before a bug fix included in
recent changes, so it should be safe to break backward compatibility.
|
