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
- Remove 'rotate_m2', unlike 'rotate_m4' it created a new matrix
duplicating 'angle_to_mat2' - now used instead.
(better avoid matching functions having different behavior).
- Add 'axis_angle_to_mat4_single',
convenience wrapper for 'axis_angle_to_mat3_single'.
- Replace 'unit_m4(), rotate_m4()' with a single call to 'axis_angle_to_mat4_single'.
Added conversion to and from exponential map representation. This
representation is useful for interpolation of > 2 quaternions, or in
PD controllers.
Implementation in C functions quat_to_expmap,
quat_normalized_to_expmap, and expmap_to_quat with Python API, unit
tests and documentation.
Added Quaternion.to_exponential_map() and Quaternion(3-vector) to
Python API.
Reviewers: campbellbarton
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1049
Basically, `angle_compat_rad()` was completely broken -
example of result it could produce:
| new angle | compat angle | result
| -0.000000 | 3.141593 | -> 3.141593
... Where 0.0 (or 2 * PI) would be expected!
Issue was in BLI's rotation_between_vecs_to_quat(), which did not handled correctly cases where both vectors are colinear.
Patch by Campbell Barton and me.
Issue originaly tracked down by Yan Shi, many thanks!
was encountered in a Kiribati rig file.
The problem was actually in the matrix to quaternion conversion function. One
problem is that it was using the wrong matrix indices in case of an ill defined
matrix trace. Besides that FLT_EPSILON was too small to detect cases where
float precision becomes a problem.
this matches closer to convention from existing functions - angle_v3v3() angle_normalized_v3v3().
also added assert to ensure argument given to axis_angle_normalized_to_mat3() is in fact normalized.
