Avoid running a Python unit test for layered Actions in non-experimental
builds.
Due to a misunderstanding, enabling the user preference for the 'Slotted
Actions' experimental feature is still possible on release builds, which
caused this test to fail on non-experimental builds (because it's
intentionally missing a chunk of experimental code).
No functional changes to Blender itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/128483
Add support for `rna_struct.keyframe_insert(…, group="name")` parameter,
when inserting keys into a layered Action.
This simply was never implemented, and the default channel group name
was always used.
Pull Request: https://projects.blender.org/blender/blender/pulls/128383
Clean up a keyframe insertion unit test I just committed, as it had some
commented-out code that shouldn't have been commented out. The test
logic could also be simplified, as the complexity was necessary for
replaying the broken test case, but not necessary for testing the actual
underlying behaviour.
No functional changes.
Ref: 2dba943341ce7a7706c3865b4b7b1cfc5d6bb746
Pull Request: https://projects.blender.org/blender/blender/pulls/128379
Calling `action.fcurves.clear()` would clear the F-Curves, but didn't
update the F-Curve groups. This meant that the groups data still had their
original length & offsets into the F-Curves array, causing subsequent
F-Curve creation to crash Blender.
The unit test for this also covers the previous commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/128375
This changes the behavior when deleting the last key of an FCurve on layered actions.
Previously the FCurve would continue to exist, whereas now it is deleted.
This makes it consistent with legacy actions.
I modified the "Clear Keyframes" operator in this PR as well to make it work with layered actions.
Pull Request: https://projects.blender.org/blender/blender/pulls/125327
This commit changes the keying code to deselect keyframes when inserting new keys.
This has been discussed in the Animation & Rigging module meeting [1].
There is also an RCS post about that [2].
Doing this brings key creation in line with object creation,
where only the newly created object is selected.
There has been a previous attempt [3] to do a similar thing.
### Changes
When inserting keys by pressing `I` in the viewport or choosing a keying set,
all keys of the `Action` get deselected before inserting new keys.
New keys are selected by default.
Python RNA functions are **NOT** affected, meaning addons using
those functions will not deselect any keys by default.
The developer has to choose to do so.
To make that easier, there is a new RNA function on the action
`deselect_keys`
[1]: https://devtalk.blender.org/t/2024-05-02-animation-rigging-module-meeting/34493#patches-review-decision-time-5
[2]: https://blender.community/c/rightclickselect/K0hbbc
[3]: https://archive.blender.org/developer/D11623
Pull Request: https://projects.blender.org/blender/blender/pulls/121908
Just for the `pyrna_struct_keyframe_insert()` function, reduce the
reporting level of keyframe insertion failures from `RPT_ERROR` to
`RPT_WARNING`. This prevents the conversion of these reports to a Python
exception.
`CombinedKeyingResult::generate_reports()` now accepts an option
argument `report_level`, so that the caller is in control over the type
of reports it generates.
Previously only errors were converted to exceptions; warnings were
implicitly cleared and never displayed. To avoid these 'keyframe
insertion failure' reports from becoming invisible, the
`pyrna_struct_keyframe_insert()` function now sends any warnings to
stdout (unless there were errors, in which case the old
error-to-exception behaviour is still there).
Pull Request: https://projects.blender.org/blender/blender/pulls/122827
The new keyframing functions introduced in #113504
didn't call the functions to decompose the NLA stack.
In practice this meant that when inserting keys into strip
that is under an additive strip, it would take the result of the additive Strip and
bake it back into the base. This would double the transform.
The fix is to call `BKE_animsys_nla_remap_keyframe_values`.
Unfortunately to do so, I had to pass through a few more
arguments to the keyframing functions.
Also adds unit tests to cover the caused bug.
Pull Request: https://projects.blender.org/blender/blender/pulls/118053
Caused by #113504
While basic cycle aware keying works, there is a special case
when inserting the first key. In that case, after the key has been inserted,
it is duplicated and moved around so the FCurve range from
first to last key is exactly the range of the action.
It also auto-creates the Cycle modifier on the FCurve .
Fix the issue by calling the function that does the key duplication
and cover with unit tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/116943
Splits the flag `..._FLAG_INSERTNEEDED` between autokey and
manual keying. The fact that this flag was shared between the two
systems has been the cause of issues in the past. It wouldn't
let you insert a keyframe even though you explicitly used an operator
to do so.
In order to be clearer what options are used where, the user preferences
have been reordered.
By default "Only Insert Needed" will be enabled for auto-keying, but not for manual keying.
The versioning code will enable both if it was enabled previously.
# Code side changes
The keying system has flags that define the behavior
when keys are inserted. Some of those flags were shared
between keying and auto-keying. Some were only used for
auto-keying.
To clarify that, prefix flags that used exclusively in one or the other
system with `AUTOKEY`/`MANUALKEY`
Also the flag name on the user preferences and the tool settings was renamed.
Previously it was called `autokey_flag`. To indicated that it is not only used
for autokeying, rename it `keying_flag`.
Fixes: #73773
Pull Request: https://projects.blender.org/blender/blender/pulls/115525
This PR changes two things
Move setup/cleanup code into `setUp`/`tearDown`
Change the `_fcurve_paths_match` to raise an error instead of returning a bool.
That makes it easier to see what the actual error is.
Pull Request: https://projects.blender.org/blender/blender/pulls/116816
Add unit tests for the user preference option "Insert Needed"
Basic tests for objects and bones that check if autokeying in
combination with "Insert Needed" only
* keys all location channels on the first key
* keys only the modified channel on the second key
It is supposed to add only keyframes that have been affected
by the used transform operation.
E.g. translating an object will only add keys on translation keys.
The behavior of keying all property array channels first, and then
only add keys on values that have actually changed may change
in the future. Ideally it would only key actual changes to begin
with. But there is no way to do this right now.
Pull Request: https://projects.blender.org/blender/blender/pulls/116419
In preparation to the upcoming refactor of the keying set code,
extend the unit tests with more sophisticated
tests for "Insert Available".
This PR tests
* key available using the preference setting with autokeying on an object and a bone
* key available using the keyingset "Available"
Pull Request: https://projects.blender.org/blender/blender/pulls/116327
When animators want to key something in the viewport,
the code needs to know *which properties* should be keyed of that selected thing.
So far that was done with keying sets, and a pop-up that let's
you choose the keying set to use. You can get rid of the popup by
choosing a keying set ahead of time. But that is also not always desirable.
That pop-up is quite confusing and gives way too many options.
To simplify this process this PR adds a User Preference option to choose one or more of:
* Location
* Rotation
* Scale
* Rotation Mode
* Custom Properties
Now whenever the `I` key is pressed in the viewport,
and no keying set is enabled, it reads the preferences for which channels to insert.
# User Facing changes
* The popup will not be shown when pressing the hotkey,
but you can still explicitly use keying sets by going to the menu
* Which channels are keyed is defined by a User Preference setting under animation
* when a keying set is used explicitly, the User Preference settings are ignored
Part of #113278
Pull Request: https://projects.blender.org/blender/blender/pulls/113504
Cover the current behavior of keyframe insertion with unit tests,
so the changes planned in #113278 are less likely to break things.
Unit tests added:
InsertKeyTest
very basic test to ensure keying things by
name or with a keying set adds the right keys
VisualKeyingTest
check if visual keying produces the
correct keyframe values
CycleAwareKeyingTest
check if cycle aware keying remaps
the keyframes correctly and adds fcurve modifiers
Pull Request: https://projects.blender.org/blender/blender/pulls/114465
