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.
This also fixes alignment issues in many editors.
E.g. the frame numbers were badly aligned to the grid lines
in the timeline.
Checkout the images in D4681 for more examples.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4681
No functional change, this adds LIB definition and args to cmake files.
Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS'
since there are many platforms/configurations that could break when
changing linking order.
Manually add and enable WITHOUT_SORTED_LIBS to try building
without sorted libs (currently fails since all variables are empty).
This check will eventually be removed.
See T46725.
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
Instead of making the entire body of the function conditional, it now
returns early, unindenting the entire function and preventing the reader
from searching for a non-existent `else` clause.
No semantic changes.
The `BLI_path_frame_strip` function was completely broken, unless the
number of digits in the sequence number was the same as the length of
the extension. In other words, it would work fine for `file.0001.abc` (4
digit `0001` and 4 char `.abc`), but other combinations would truncate
to the shortest (`file.001.abc` would become `file.###.ab` and
`file.00001.a` would become `file.##.a`). The dependency between the
sequence number and the file extension is now removed.
The behaviour has changed a little bit in the case where there are no
numbers in the filename. Previously, `path="filename.abc"` would result
in `path="filename.abc"` and `ext=""`, but now it results in
`path="filename"` and `ext=".abc"`. This way `ext` always contains the
extension, and the behaviour is consistent regardless of whether there
were any numbers found.
Furthermore, I've removed the `bool set_frame_char` parameter, because
it was unclear, probably also buggy, and most importantly, never used.
I've also added a unit test for the `BLI_path_frame_strip` function.
Some users of the 3D versions were storing 2D data in it.
Using a 3D tree for 2D data adds a spatially redundant branch
every 3rd level, as well as some extra memory use, best avoid this.
This moves logic into kdtree_impl.h which is included in a source
file that defines the number of dimensions - so we can easily support
different numbers of dimensions as needed
(currently 3D and 4D are supported).
Macro use isn't so nice but avoids a lot of duplicate code.
Logic to for boids to avoid head-on collisions was in BLI_kdtree.
Move this into a callback which is now defined in boids.c
so the kdtree code can be kept generic.
