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
