Using clang-tidy "cppcoreguidelines-pro-type-cstyle-cast" to find them.
This PR touches `bf_animrig` & `bf_editor_animation` & `bf_editor_armature`
NOTE: Also some case where untouched (not straightforward) same as
expanded macros (e.g. `LISTBASE` or `GS`)
NOTE: a couple of cases of "inconsistent-declaration-parameter" as well
Pull Request: https://projects.blender.org/blender/blender/pulls/136044
Caused by 6d832ee5b3
The bone names were flipped correctly, however, we were missing the
actual FCurve BezTriple flipping.
This was caused by passing the wrong FCurve into
`do_curve_mirror_flippping` -- this function is checking for existence
of the FCurve in the `KeyframeCopyBuffer`, so we gotta pass
`fcurve_in_copy_buffer` (instead of the new fcu).
Pull Request: https://projects.blender.org/blender/blender/pulls/135381
Copy-paste of keyframes is now slot-aware. See [1] for the design.
[1]: https://developer.blender.org/docs/features/animation/tools/action-editor-copy-paste/
In short:
- Copy-paste still works broadly as it used to. Only the visible
F-Curves are pasted into.
- Slot identifiers matter when copying from multiple slots. When
copying from one slot, they don't.
- Selection of channels (either F-Curves or Slots) determines where
keys get pasted into.
- Pasting will either copy from the slot with the same identifier
(when identifiers matter), or paste whatever was copied (when they
do not).
- If both F-Curves and slots are selected, only the selected F-Curves
get pasted into, and slots without any selected F-Curves are ignored
(i.e. target is only defined by selected F-Curves, or only by
selected slots, never by a mixture).
Fixes#129690
Pull Request: https://projects.blender.org/blender/blender/pulls/133979
Use streaming to `std::cout` for debug prints, rather than using
`printf()`. Different compilers disagree on the `printf()` format string
for `int64_t`: GCC thinks it should be `%ld` while Clang says `%lld`,
and either will emit a warning when the other's preference is used.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/133857
Refactor the keyframe copy-paste code to prepare for supporting action slots.
This is a non-functional change, as the slots are stored but otherwise completely ignored. This way the refactor to the new data structure can be reviewed & tested before actually changing the behaviour.
Related: #129690
Pull Request: https://projects.blender.org/blender/blender/pulls/133497
Replace pointer magic with `std::string` and `blender::StringRef`.
The old code modified the RNA path of F-Curves to extract & flip the
bone name. The new code is not modifying any data, at the expense of a
few more copies. Since these strings are not long, and the call to
`BLI_string_flip_side_name()` also makes quite a few copies, the
performance impact should be negligible.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/133005
Simplify `pastebuf_match_path_property()` by reducing cognitive complexity
and using `StringRef::endswith()` instead of pointer arithmetic.
I've also added a few unit test cases that cover some unwanted behavior:
the property name check only checks suffixes, and so copying "….location"
will also paste it to a "….not_actually_location" F-Curve.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/133005
Add a unit test for the bone name flipping function of the keyframe
paste functionality.
The function itself has been changed a little bit, so that it returns a
`std::string` instead of using a `char **` return parameter that needs
explicit freeing at the call site. This made the tests considerably
simpler to write. This change does cause an extra copy of the RNA path,
but that should be refactored away soon.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/133005
No functional changes intended.
Modify the code so that no `ED_` includes are needed in animrig.
The function `reevaluate_fcurve_errors` was just moved to its only used
place and made static.
For `animdata_fcurve_delete` the `bAnimContext` argument
is no longer needed because it was only used to check if an `FCurve` is
for a driver which you can also get from `FCurve.driver`.
**Note** that this still leaves `../editors/include` in `CMakeLists.txt`
but that is needed for bone colors.
Pull Request: https://projects.blender.org/blender/blender/pulls/130338
The root cause of this bug can be traced to:
- `ANIM_nla_mapping_get(ac, ale)` conditionally returns an `AnimData *adt`.
- This can be `nullptr` in various cases, depending on the editor (in `ac`) and
the type & source of data (in `ale`).
- This `nullptr` has different meanings:
1. There is not enough information to return an `adt` (like `ac` or `ale`
being `nullptr` themselves).
2. NLA time remapping should not be done. For example for NLA control F-Curves
(like animated strip influence), or Grease Pencil (because that doesn't use
the NLA).
- The above-returned `adt` is passed to other functions. Some of them are aware
of the "`nullptr` means no NLA time remapping" scenario, and gracefully handle
it. Other code, however, just gets "an adt" from the caller and handles it as
normal (and likely crashes on `nullptr`). Other cases start out as the first,
but somewhere in the call stack shift over to the second.
The approach taken in this PR to fix the bug is to (generally) stop signaling
"do not use NLA time remapping" via `adt = nullptr`, and instead explicitly
indicate/check whether remapping should be done.
In most cases this means passing a `bAnimListElem *` instead of an `AnimData *`,
because the former has the information needed to determine if time remapping
should be done or not. However, in some cases there is no `bAnimListElem *` to
pass, and instead other information determines whether remapping is needed. In
those cases we add a `bool` parameter or field in the appropriate place so that
calling code can explicitly indicate whether remapping should be done or not.
To accomplish this a variety of functions have been added to help handle things
correctly. Of particular note:
- `AnimData *ANIM_nla_mapping_get(ac, ale)` (that conditionally returned an
`adt`) has been removed entirely in favor of the new
`bool ANIM_nla_mapping_allowed(ale)` function that simply returns whether
nla remapping should be done or not.
- `ANIM_nla_tweakedit_remap(ale, …)` has been added, which wraps
`BKE_nla_tweakedit_remap(adt, …)` and only performs the remapping when
`ANIM_nla_mapping_allowed()` indicates that it's allowed.
- `ANIM_nla_mapping_apply_if_needed_fcurve(ale, …)` has been added, which is an
alternative to `ANIM_nla_mapping_apply_fcurve(adt, …)` that also only performs
the remapping when `ANIM_nla_mapping_allowed()` indicates that it's allowed.
Note that even with this PR there are still a couple of places remaining that
use `adt = nullptr` to indicate "don't remap", because they appear to be correct
and would require larger changes to make explicit. In those cases comments have
been added to explain the situation, with a reference to this PR. In the future
we way want to take the time to change those as well.
Also of minor note: this PR moves the definition of the type `slot_handle_t`
from ANIM_action.hh to BKE_action.hh. This is due to `BKE_nla.hh` (which needs
that definition) now being included directly and indirectly in a lot more
places. Moving the definition to BKE_action.hh prevents all of those new places
from gaining dependencies on the animrig module.
Co-authored-by: Sybren A. Stüvel <sybren@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/130440
No functional changes.
This PR moves the following public functions to animrig:
* sample_fcurve_segment
* bake_fcurve
* bake_fcurve_segments
The `bake_fcurve_segments` also gets a docstring and its comments have been
updated to follow the style guide.
Pull Request: https://projects.blender.org/blender/blender/pulls/120984
While valid, this isn't so common and cppcheck warns about this,
use explicit casts to suppress the warning, also correct "true"
being assigned to a float value.
This PR extends the existing `Ease` operator with a sharpness property.
This means it has two parameters:
* Curve Bend: Define which key to favor. At 0 it's exactly between the two keys.
* Sharpness: Higher values make the change more abrupt.
During modal operation it is possible to switch the slider between those two by pressing `TAB`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117287
There exist a bunch of "give me a (filtered) image pixel at this location"
functions, some with duplicated functionality, some with almost the same but
not quite, some that look similar but behave slightly differently, etc.
Some of them were in BLI, some were in ImBuf.
This commit tries to improve the situation by:
* Adding low level interpolation functions to `BLI_math_interp.hh`
- With documentation on their behavior,
- And with more unit tests.
* At `ImBuf` level, there are only convenience inline wrappers to the above BLI
functions (split off into a separate header `IMB_interp.hh`). However, since
these wrappers are inline, some things get a tiny bit faster as a side
effect. E.g. VSE image strip, scaling to 4K resolution (Windows/Ryzen5950X):
- Nearest filter: 2.33 -> 1.94ms
- Bilinear filter: 5.83 -> 5.69ms
- Subsampled3x3 filter: 28.6 -> 22.4ms
Details on the functions:
- All of them have `_byte` and `_fl` suffixes.
- They exist in 4-channel byte (uchar4) and float (float4), as well as
explicitly passed amount of channels for other float images.
- New functions in BLI `blender::math` namespace:
- `interpolate_nearest`
- `interpolate_bilinear`
- `interpolate_bilinear_wrap`. Note that unlike previous "wrap" function,
this one no longer requires the caller to do their own wrapping.
- `interpolate_cubic_bspline`. Previous similar function was called just
"bicubic" which could mean many different things.
- Same functions exist in `IMB_interp.hh`, they are just convenience that takes
ImBuf and uses data pointer, width, height from that.
Other bits:
- Renamed `mod_f_positive` to `floored_fmod` (better matches `safe_floored_modf`
and `floored_modulo` that exist elsewhere), made it branchless and added more
unit tests.
- `interpolate_bilinear_wrap_fl` no longer clamps result to 0..1 range. Instead,
moved the clamp to be outside of the call in `paint_image_proj.cc` and
`paint_utils.cc`. Though the need for clamping in there is also questionable.
Pull Request: https://projects.blender.org/blender/blender/pulls/117387
Combination of two operators by Ares Deveaux
#106524 and #106523
Introduces a new operator "Scale from Neighbor"
that scales selected keyframe segments from either
the left or right keyframe neighbor.
Pressing "D" during modal operation will switch
from which end of the segment the scaling happens.
This is useful to make a section of animation closer to a pose on either side.
Co-authored-by: Ares Deveaux <aresdevo@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/112387
This is a replacement for the workflow that uses
"Bake Curve" and "Unbake Curve" to quickly generate
dense key data.
Compared to the existing workflow it has the advantage
of allowing the user more control over the key types,
and distance between keys, as well as the frame range affected.
Operator options
* Range: the range that will be baked.
Defaults to the scene range or preview range.
* Step: Distance between keyframes.
Can be used to bake on 2s or even bake to subframes.
* Remove Existing Keys: Boolean option that
if enabled also removes keys outside the specified baking range
* Interpolation Type: Choose a interpolation mode used
for new keys e.g. Constant or Bezier
* Bake Modifiers: If enabled bakes the effect of the
modifier stack to keys and deletes the modifier stack.
If false, the code disables the modifiers before baking,
so the resulting keys will behave as if the modifiers didn't exist
The operator can be found in the Graph Editor under `Channel->Bake Channels`
Part of: #111050
Pull Request: https://projects.blender.org/blender/blender/pulls/111263
No functional changes.
Before this PR the interpolation mode of a new keyframe
was read from the User Preference at the deepest level
where the keyframe is created.
In case where this shouldn't be done, the flag
`INSERTKEY_NO_USERPREF` was passed in.
In this case it would fall back to some default values.
In order to make these low level functions
more flexible, the keyframe settings are now passed in.
I've made a new struct `KeyframeSettings` that holds the
* interpolation
* key type
* handle type
and a function `get_keyframe_settings` that allows
you to quickly get this settings struct.
This is a first step that will allow to pass in the
interpolation mode from python in the future.
Part of #113278
Pull Request: https://projects.blender.org/blender/blender/pulls/115898
No functional changes.
To reduce the argument count of `insert_vert_fcurve`,
the x and y argumentsto define the position
of a keyframe can be merged into a single `float2`
Pull Request: https://projects.blender.org/blender/blender/pulls/115886
No functional changes.
Renaming the following functions
`ANIM_remove_empty_action_from_animdata` and
`ANIM_fcurve_delete_from_animdata`
to
`animdata_remove_empty_action` and
`animdata_fcurve_delete`
The `ANIM` prefix was no longer needed since the code is now in
a namespace. In order to make the function name consistent with
the functions in `fcurve.cc` the thing it modifies is now at the
start of the function name
Pull Request: https://projects.blender.org/blender/blender/pulls/114584
No functional changes.
Move the following functions
`ANIM_fcurve_delete_from_animdata` and
`ANIM_remove_empty_action_from_animdata`
to
`ANIM_animdata.hh` / `animdata.cc`
in animrig
This removes some includes to `ED_anim_api.hh`
from animrig
Pull Request: https://projects.blender.org/blender/blender/pulls/114581
No functional changes.
Move the functions
`insert_vert_fcurve` and
`insert_bezt_fcurve`
from `ED_keyframing.hh` / `keyframing.cc`
to `ANIM_fcurve.hh` / `fcurve.cc`
in animrig
Pull Request: https://projects.blender.org/blender/blender/pulls/114570
The issue was that the code filtered for selected channels,
while the expectation was that it would only filter for selected keys.
This PR changes the behavior of the operator in the following way:
* when "Clean Channels" is **disabled**, it will clean only selected keyframes, regardless of the channel selection
* when "Clean Channels" is **enabled**, it will clean selected channels regardless of keyframe selection
The same logic was applied to the Graph Editor code.
It only makes a difference in the case when "Clean Channels" is enabled.
That is because channels were automatically selected when a key was selected.
In addition to that I moved the menu entry for "Clean Channels" to the channel menu
to reduce confusion.
Another solution would have been to make the Dope Sheet select channels
when keys are selected. This might still be done in the future, but I think the
only correct fix is to change the actual operator behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/113335
This patch has been originally authored by Ares Deveaux #106520
I am just finishing it up.
This is a new operator for the Graph Editor.
It shifts the value of the keys in time,
while keeping the actual key positions in the same place.
It supports wrapping, so when offsetting beyond the range
of the F-Curve it will take values from the other end,
but offset in y-value so there is no jump.
This works best with dense key data.
Co-authored-by: Ares Deveaux <aresdevo@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/110540
After Renaming "Bake Curve" to "Samples to Keys" in #111049,
the name of the `GRAPH_OT_sample` operator needed renaming.
That is because the word "sample" is now used to describe FCurve
data in an uneditable state.
Rename to `GRAPH_OT_bake_keys` since baking is the term
used in animation to describe the action of creating dense key data.
Pull Request: https://projects.blender.org/blender/blender/pulls/112148
This patch has been originally authored by Ares Deveaux #106526
Scale the selected key segments to their average
Unlike just scaling using the transform tools, this scales to the average of each individual F-Curve segment.
Co-authored-by: Ares Deveaux <aresdevo@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/111744
There are a couple of functions that create rna pointers. For example
`RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those
take an output parameter `r_ptr` as last argument. This patch changes
it so that the functions actually return a` PointerRNA` instead of using
the output parameters.
This has a few benefits:
* Output parameters should only be used when there is an actual benefit.
Otherwise, one should default to returning the value.
* It's simpler to use the API in the large majority of cases (note that this
patch reduces the number of lines of code).
* It allows the `PointerRNA` to be const on the call-site, if that is desired.
No performance regression has been measured in production files.
If one of these functions happened to be called in a hot loop where
there is a regression, the solution should be to use an inline function
there which allows the compiler to optimize it even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/111976
This is a combination of two PRs from Ares Deveaux: #106521 and #106522
This adds a new operator that allows shearing keys
based on the position of the segment ends.
By pressing `D` while the operator is in modal you can
switch if the operator takes the left or the right segment end as a reference.
Co-authored-by: Ares Deveaux <aresdevo@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/111735
