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
This was noted in code comments and checked in Python documentation
generation but not at build time.
Since these enums are identifiers that end up included in various places
enforce the `rna_enum_*_items` convention which was noted as
the convention but not followed strictly.
Partially reverts [0], avoids having to deal with multiple prefix types.
[0]: 3ea7117ed1
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
This PR blends the selected keyframes to an ease-in or ease-out curve.
The difference to the existing ease slider is that this one blends,
while the other snaps to the ease curve
Co-authored-by: Ares Deveaux <aresdevo@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/110566
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
The same issue for Smooth (Gaussian) which was reported in #109799 also affects the Butterworth filter.
When keys were not exactly on the frame, but offset even by minimal values the filter would introduce stepping.
Fix it by using `round()` instead of `(int)` when calculating the index to the filtered values array
Pull Request: https://projects.blender.org/blender/blender/pulls/110060
When keys were not perfectly on the frame, the index logic
would fail and duplicate data across 2 frames.
Using `round()` solves this. It does not add subframe support though.
Pull Request: https://projects.blender.org/blender/blender/pulls/110059
