| Age | Commit message (Collapse) | Author |
|---|
|
This function returns an array of keyed frames with rounding,
to avoid duplicates caused by subtle floating point difference.
Reviewed By: sybren
Ref D10781
|
|
Approximately 91 spelling corrections, almost all in comments.
Differential Revision: https://developer.blender.org/D10288
Reviewed by Harley Acheson
|
|
|
|
This new discontinuity filter performs actions on the entire Euler
rotation, rather than only on the individual X/Y/Z channels. This makes
it fix a wider range of discontinuities, for example those in T52744.
The filter now runs twice on the selected channels, in this order:
- New: Convert X+Y+Z rotation to matrix, then back to Euler angles.
- Old: Add/remove factors of 360° to minimize jumps.
The messaging is streamlined; it now reports how many channels were
filtered, and only warns (instead of errors) when there was an actual
problem with the selected channels (like selecting three or more
channels, but without X/Y/Z triplet).
A new kernel function `BKE_fcurve_keyframe_move_value_with_handles()` is
introduced, to make it possible to move a keyframe's value and move its
handles at the same time.
Manifest Task: T52744
Reviewed By: looch
Differential Revision: https://developer.blender.org/D9602
|
|
Expand unit test for `BKE_fcurve_active_keyframe_index()` to test edge
cases better.
This also introduces a new test macro `EXPECT_BLI_ASSERT()`, which can be
used to test that an assertion fails successfully.
No functional changes to actual Blender code.
|
|
|
|
Fix unit test failing in debug mode by having more explicit boundary checks
when setting an FCurve's active keyframe.
No functional changes.
|
|
|
|
We already had the ability to bake fcurves but no way to convert the
baked result back without using python. This patch adds and operator
that is available now next to the bake operator in the drop down menu,
Reviewed By: Sybren
Differential Revision: http://developer.blender.org/D6379
|
|
|
|
Selecting an F-Curve handle caused an assertion as well as treating
the key-frame as inactive.
Allow active the keyframe to be active when it's handle is selected,
as is done with bezier curves.
|
|
No functional changes.
Reviewed By: Sybren A. Stüvel
Differential Revision: http://developer.blender.org/D7850
|
|
Restore the old `correct_bezpart()` (pre-rBda95d1d851b4) function as
`BKE_curve_correct_bezpart()`, and use that where the old behaviour was
desired (that is, curve maps like used by the RGB Curves shader node).
The new (post-rBda95d1d851b4) function is also renamed to
`BKE_fcurve_correct_bezpart()` to avoid confusion.
|
|
- BKE_bezt_subdivide_handles -> BKE_fcurve_bezt_subdivide_handles
- binarysearch_bezt_index -> BKE_fcurve_bezt_binarysearch_index
These functions are specific to F-Curves and don't make sense for other
uses of BezTriple (curve-object data for e.g.)
Also:
- Move detailed doxygen comment above code, following code-style.
- Mark bezt_add_to_cfra_elem unused.
|
|
Avoid NULL pointer dereference when checking keyframe selection state in
`BLI_assert()` call.
|
|
Check selection state in `BKE_fcurve_active_keyframe_index()`, and only
return the active keyframe index when that keyframe is actually selected.
This is now also asserted in the `BKE_fcurve_active_keyframe_set()` function,
which is now also used when inserting a keyframe.
|
|
Follow our code style guide by using C-comments for text descriptions.
|
|
In the graph editor there is a panel that says "Active Keyframe" for
numerically editing a keyframe's values, but in the code there is no
concept of the "active keyframe." Since this is a useful concept to
have for some other features anyway, this commit adds an active
keyframe index value to FCurves. It also displays it with a theme
color for the active vertex (which didn't exist before) if the
FCurve is active.
The active keyframe in the graph editor is treated similarly to the
active vertex in the 3D view. It is the keyframe most recently selected
with a single click, and it is always selected.
For now, the only real functional change is that the active keyframe
appears in white and it should be more predictable which keyframe is
being edited in the sidebar panel.
Differential Revision: https://developer.blender.org/D7737
|
|
Apply the De Casteljau algorithm to split the Bèzier curve at the X
coordinate where the new key is inserted, and uses the result to update
both the newly inserted and surrounding handles.
For curves that use Auto keyframes this has been largely addressed by
the new algorithm from D2884. This commit extends this to non-auto
handles.
This code is heavily based on D3172 by Alexander Gavrilov (@angavrilov).
Manifest Task: https://developer.blender.org/T81353
|
|
Cleanup old tracker task format to the new. e.g: [#34039] to T34039
Ref D8718
|
|
|
|
Relax limits of FCurve Bézier handles during evaluation. FCurve handles
can be scaled down to avoid the curve looping backward in time. This
scaling was done correctly but over-carefully, posing unnecessary
limitations on the possible slope of FCurves. This commit changes the
scaling approach such that the FCurve can become near-vertical.
Bump Blender's subversion from 291.0.1 to 291.0.2 to ensure that older
animation files are correctly updated.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D8752
|
|
No functional changes.
|
|
|
|
|
|
With this change, the three .blend read operations: data reading, lib reading
and expanding are more grouped together.
|
|
|
|
This is part of T76372.
|
|
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/blenkernel` module.
No functional changes.
|
|
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
|
|
Clang Tidy reported a couple of false positives. I disabled
those `NOLINTNEXTLINE`.
Differential Revision: https://developer.blender.org/D8199
|
|
|
|
|
|
|
|
|
|
Now callbacks for animdata, nla strip and fcurve are in their own proper
BKE files (mimicking `foreach_id` callback of `IDTypeInfo`).
This commit also fixes some missing handling of ID pointers (text ID and
IDProperties of script fcurve modifier...).
|
|
|
|
When local origins are used or a single control point is selected,
change the handle types from auto to aligned.
|
|
Every code path through the `fcurve_eval_keyframes_interpolate()` function
has a valid `return` statement, but in debug mode GCC still doesn't like it.
|
|
Early returns are used to heavily reduce code indentation and clean up
some code flow.
No functional changes.
|
|
|
|
Previously there were two functions for FCurve extrapolation, one for
before the first keyframe, and the other for after the last. After the
previous cleanup made the variable names consistent, it was clear that
the code was almost identical. The biggest difference was in the sign of
many of the calculations, which was cancelled out by swapping `B-A` to
`A-B`. This showed that the computations are actually the same, and the
only remaining difference was which neighbouring handle to use in case
of Bézier curves.
No functional changes.
# Conflicts:
# source/blender/blenkernel/intern/fcurve.c
|
|
Variables have been renamed so that they refer to the endpoint and its
neighbor (rather than `bezt`, `prevbezt`, or `lastbezt`), and
unnecessary variables have been removed. By returning early the code
flow is also easier to understand.
No functional changes.
|
|
The `fcurve_eval_keyframes` consists of three parts:
- Before the first keyframe
- After the last keyframe
- Between the keyframes
This commit splits the first two parts into separate functions. This is
the first of a series of refactors, which will be committed into smaller
parts so that each is easier to follow & validate.
No functional changes.
|
|
All the driver-specific code in `fcurve.c` has been moved into a new file
`fcurve_driver.c`. The corresponding declarations have been moved from
`BKE_fcurve.h` to `BKE_fcurve_driver.h`.
All the `#include "BKE_fcurve.h"` statements have been investigated and
replaced with `BKE_fcurve_driver.h` where necessary.
No functional changes.
|
|
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
|
|
The `BKE_animsys.h` and `anim_sys.c` files already had a an "AnimData
API" section. The code in that section has now been split off, and
placed into `BKE_anim_data.h` and `anim_data.c`.
All files that used to include `BKE_animsys.h` have been adjusted to
only include the animation headers they need (sometimes none).
No functional changes.
|
|
|
|
While it might be handy to have type-less functionality which is
similar to how C++ math is implemented it can not be easily achieved
with just preprocessor in a way which does not have side-effects on
wrong usage.
There macros where often used on a non-trivial expression, and there
was at least one usage where it was causing an actual side effect/bug
on Windows (see change around square_f(sh[index++]) in studiolight.c).
For such cases it is handy to have a function which is guaranteed to
have zero side-effects. The motivation behind actually removing the
macros is that there is already a way to do similar calculation. Also,
not having such macros is a way to guarantee that its usage is not
changed in a way which have side-effects and that it's not used as an
inspiration for cases where it should not be used.
Differential Revision: https://developer.blender.org/D7051
|
|
Objects."
This reverts commit 7728bfd4c45c634ba6b62e149176425ec5779945.
Although this brings back an inconsistency in the behaviour of
constraints on objects and bones, people were relying on the old
behaviour, and the new behaviour broke their files.
It is still desired to remove this inconsistency, but it will happen
more gradually.
|
