This changes the following keyframing functions to return
`SingleKeyingResult`, which is in turn used for better failure
reporting in the higher-level functions that call them:
- `KeyframeStrip::keyframe_insert()`
- `insert_vert_fcurve()`
As a side effect, this also means that
`rna_KeyframeAnimationStrip_key_insert()` can no longer return an
`FCurve *`, and now instead returns a bool indicating success.
This is part of an ongoing progressive refactor to improve error
messages and failure handling in the keyingframing code.
Pull Request: https://projects.blender.org/blender/blender/pulls/121517
No functional changes expected.
This PR moves the enums
`eModifyKey_Modes` and `eModifyKey_Returns` to animrig
as enum classes.
Functions that take or return that value were also modified.
Pull Request: https://projects.blender.org/blender/blender/pulls/121132
A unit test file was still using `out`, short for 'output', which was the
original name for what later became 'binding'. This is now updated, and
the variables are now named appropriately.
Pull Request: https://projects.blender.org/blender/blender/pulls/121273
Add an RNA enum property `AnimData.animation_binding` that lists all the
bindings available in `AnimData.animation`.
The list of bindings is filtered to only contain the bindings suitable
for the animated ID. This prevents assigning a 'camera' binding to a
mesh.
Un-assigning is done via an operator, represented as an 'X' button in
the interface.
The enum property contains up to two special items:
- "New" to create a new binding for the ID.
- "(none/legacy)" to indicate that this ID doesn't have a binding
assigned. This one is conditional, and only appears when it is
necessary.
These two special items are experimental, and mostly exist because we're
still evaluating things and building a better UI. It is intended that
the binding selector will become as close to the ID selector as
possible.
-----------
Note that this PR also contains #121268 as it builds up from that one, and I didn't want to wait with testing on the buildbot until that one lands.
The new Baklava panel:
Pull Request: https://projects.blender.org/blender/blender/pulls/121269
This cleans up some of the Animation/Binding API, and adds a distinction
between a binding's "name" and its "display name".
`name`: internal name that is unique within the `Animation`. As such, it
is also the key into the `anim.bindings` collection.
- To ensure the uniqueness, `name` is always prefxed with the ID
identifier, like `OBCube` and `CACamera`.
- A binding that was not created to animate a specific ID will be
called `XXBinding`.
`name_display`: display name that strips the first two characters, so in
the above examples would be `Cube`, `Camera`, and `Binding`.
### RNA setter behaviour
`name`: always sets the name, emitting a warning when the name's prefix
doesn't match the ID type of the Binding. This implicitly changes the
display name (as they are two views into the same string).
`name_display`: sets `name = prefix_for_ID_type + name_display`. So even
when the old name was `QQSomethingWeird`, setting `binding.name_display
= "NewName"` would effectively set `binding.name = "OBNewName"`
(assuming it was already bound to some object earlier).
Bindings now also **always have a name**. Previously it was possible to
create bindings named `""`, but that's no longer possible.
Bindings used to be **renamed automatically** when they were first
assigned, for example from `XXBinding` to `OBCube`. This behaviour has
been removed, as it could potentially cause confusion.
Pull Request: https://projects.blender.org/blender/blender/pulls/120941
No functional changes.
The enum entries of `BakeCurveRemove` used to
start with `REMOVE` which just doubled that word.
Removing that simplifies the enum entries.
This has been brought up by @dr.sybren in #120984
Pull Request: https://projects.blender.org/blender/blender/pulls/121258
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
This fixes an issue with the error messages that keying
can produce where they couldn't be translated.
To make translation possible, two things changed:
* use of `RPT_`
* simplified string formatting
Pull Request: https://projects.blender.org/blender/blender/pulls/121112
No functional changes.
This PR moves the `ANIM_get_keyframing_flags` function to
animrig as `get_keyframing_flags`.
The docstring has been fixed since it was out of date.
Pull Request: https://projects.blender.org/blender/blender/pulls/121120
The insert key function in `animrig/keyframing.cc` took a `ReportList`
argument which it used to print messages in case of failures.
Instead this now returns a `CombinedKeyingResult` and the caller is
responsible for creating reports out of that.
To make that simpler the `ID` argument has been changed from a pointer to a reference.
The calling functions now make sure that it's not a `nullptr`.
This has the effect that there will be less messages printed in the Info panel when e.g. inserting keys with a keyingset.
This still doesn't make an error message pop up though.
Related to #119776
Pull Request: https://projects.blender.org/blender/blender/pulls/120784
Add minimal support for the `Animation` data-block to the anim filtering
code. This means:
- F-Curves in the `Animation` data-block are shown in the Dope Sheet and
Graph Editor.
- The `Animation` is shown underneath each animated data-block, just
like an `Action` would be.
- Contrary to Actions, the expanded/collapsed state is stored on
`id->adt` and not on `Animation`. Because an `Animation` is intended
to be used by multiple data-blocks, they each should have their own
flag for this.
- In the filtering code, this PR adds the 'fillanim' channel type. This
is simply mimicking the name from the Action's 'fillact' type.
Limitations:
- Deleting of F-Curves is explicitly blocked, as that'll be introduced
in a later PR. The block prevents Blender from crashing.
- The Dope Sheet doesn't have an Animation mode yet, that'll be for a
later PR too.
Pull Request: https://projects.blender.org/blender/blender/pulls/120654
Bone collections are drawn in the new tree view by accessing properties
from `armature.collections_all[...]`, which means that drivers and
fcurves also target those. This is now taken into account when updating
the bone collection name.
For context: in Blender 4.0 the UIList used `.collections[...]` instead,
for which renaming was already handled properly.
Pull Request: https://projects.blender.org/blender/blender/pulls/120517
The data in CombinedKeyingResult was using BLI's Array type, which
heap allocates. However, we know the array size at compile time,
and therefore can use std::array instead, as suggested in Array's
documentation. This makes CombinedKeyingResult a
plain-old-data class.
Pull Request: https://projects.blender.org/blender/blender/pulls/120425
With this PR, when pressing `I` in the viewport and the code
is unable to insert **ANY** keyframes, the user will be presented
with a single message detailing exactly why it has failed.
This PR promotes the functionality introduced in
#117449 into the header file so it can be used elsewhere.
The `CombinedKeyingResult` class is returned
from `insert_key_action` and `insert_key_rna`, and
used to produce a single report from the operator if it
failed to insert any keyframes.
In order to easily create a report from a `CombinedKeyingResult`
the function `generate_keyframe_reports_from_result`
has been moved into the class as `generate_reports`.
In addition to that the `UNABLE_TO_INSERT_TO_NLA_STACK` result
has been added. This notifies the user if keyframe insertion is not
possible due to NLA stack settings.
Pull Request: https://projects.blender.org/blender/blender/pulls/119201
Use the `Animation` data-block to find F-Curves, for drawing the
background color of properties in the GUI (green for 'animated', yellow
for 'keyed on this frame', etc.).
This assumes (correctly) that the `Animation` is limited to a single
layer with a single strip. As such, there is only one set of F-Curves
for every animated ID, which means that the correct F-Curve will be
found. This will need adjustment when the same property can have
multiple F-Curves (due to layers) or when an F-Curve may not be
applicable for each point in time (due to the use of finite strips).
Pull Request: https://projects.blender.org/blender/blender/pulls/118677
Include Animation data-block handling in Blender's animation evaluation
stack. If an `Animation` is assigned to an `ID`, it will take precedence
over the NLA and/or any `Action` that might be assigned as well.
For more info, see #113594.
Pull Request: https://projects.blender.org/blender/blender/pulls/118677
Allow inserting keys into Keyframe strips (which is the only type of
strip that is currently implemented).
Note that the data model is currently limited to a single layer, with a
single infinite strip. Because of this, the strip will not be shown in
any UI, as there is no way to manipulate it anyway.
Note that the inserted keys are not yet evaluated, so the animation
isn't visible in the 3D viewport yet. That's for an upcoming commit.
For more info, see #113594.
Pull Request: https://projects.blender.org/blender/blender/pulls/118677
Expand the `AnimData` struct with an `Animation *` + an
`binding_stable_index` field, and properly handle those relations.
This also adds functionality for actually pointing animated IDs to
`Animation` data-blocks, and automatically hooking up the relevant
`Binding`.
The Depsgraph code is extended to take these new relations into account,
but doesn't trigger any animation evaluation yet.
For more info, see #113594.
Pull Request: https://projects.blender.org/blender/blender/pulls/118677
Add code (including RNA wrappers) for:
- Creating, removing, and accessing `Animation` data-blocks.
- Creating and removing layers, strips, and bindings on those `Animation`
data-blocks.
- Accessing those via RNA.
Note that this does not include assignment to any animated data-block,
so it is of limited practical use.
For more info, see #113594.
Pull Request: https://projects.blender.org/blender/blender/pulls/118677
Instead of using `short key_type`, use `eBezTriple_KeyframeType key_type`,
so that it's clear which type it is, and so that a `switch()` can cause
compiler warnings when it's incomplete.
This also adds missing `case`s to `switch`es where necessary, in a way
that doesn't affect the outcome. There is one change that looks like it
is a functional change, but it should provide the same result:
```diff
- size -= 0.8f * key_type;
+ size *= 0.8f;
```
Since `size = 12` and in this case `key_type = 3`, the numerical values
are the same, but now the code is consistently multiplying and thus should
scale properly.
Furthermore some overly obvious comments are removed and some missing
`const` keywords have been added.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/120178
No functional changes.
The function `get_keyframe_values` existed twice.
Once in a legacy state, which also did NLA logic.
And also in a new implementation where it only returned keyframe values.
This PR removes the legacy function and moves the NLA logic to a separate function.
Pull Request: https://projects.blender.org/blender/blender/pulls/119798
The issue was that the `PointerRNA` passed to `BKE_animsys_get_nla_keyframing_context`
needs to point to an `ID` which wasn't the case when keying bones.
That is because internally the `FCurve` path is used to resolve the property.
This can only work from the `ID` because the `FCurve` path is always stored relative to that.
While the function doesn't fail when the property can't resolve the path, it won't actually do
the remapping when passing it to `BKE_animsys_nla_remap_keyframe_values` later.
Pull Request: https://projects.blender.org/blender/blender/pulls/120008
No functional changes intended.
The `insert_keyframe` function had a `bAction` argument that could be
a `nullptr`. If it was a `nullptr` it would be queried from the `ID`.
However in all cases where it is passed it is also gotten from the `ID`, making
the argument redundant.
This PR removes the argument to simplify the function.
Pull Request: https://projects.blender.org/blender/blender/pulls/119742
When bone collection is moved to root collection by drag-drop,
visibility of dropped collection is lost. This is due to missing flags
for the root bone collection which cleared `BONE_COLLECTION_ANCESTORS_VISIBLE`
flag of dropped bcol.
Pull Request: https://projects.blender.org/blender/blender/pulls/119366
The keyframing functions up to this point created many
messages through the `ReportList` about what went wrong
when inserting keys.
This has 2 issues:
* Everyone that wants to insert keyframes needs to have
a `ReportList` which comes from `bContext`
* The keyframing functions are very verbose.
Providing the user with errors when there is actually nothing wrong.
To combat that, return a status enum from functions that deal
with a single FCurve.
Functions that deal with more than one FCurve collect those statuses
into a new class `CombinedKeyingResult`
Based on that we can create a single well worded error message,
instead of potentially flooding the user with individual messages.
The downside is that some info is lost, e.g. we do not
know which exact FCurve has failed.
This will show a formatted error when inserting keys with a keying
set or when pressing `I` over the property to keyframe.
But not when pressing `I` in the viewport. The latter can be fixed in a later patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/117449
Introduce new DNA for the `Animation` data-block and its sub-data.
This includes the blenkernel code for reading & writing to blend files,
and for memory management (freeing, duplicating). Minimal C++ wrappers
are included, with just the functionality needed for blenkernel to do
its job.
The Outliner code is extended so that it knows about the new data-type,
nothing more.
For more info, see issue #113594.
Pull Request: https://projects.blender.org/blender/blender/pulls/119077
No functional changes.
This PR replaces the uses of the C-style `BLI_BITMAP`
with `blender::BitVector` in `keyframing.cc`.
Note that in `BKE_animsys_nla_remap_keyframe_values` I had to
add code that maps from one to the other because I don't feel
comfortable ripping out the `BLI_BITMAP` from
`NlaEvalChannelSnapshot->remap_domain`
Pull Request: https://projects.blender.org/blender/blender/pulls/118957
Crash happens in `action_group_colors_set_from_posebone` /
`ANIM_bonecolor_posebone_get` on a `bPoseChannel` without a `bone`.
If I am not mistaken a new `bPoseChannel` (e.g. after duplication) will
only get its `bone` after leaving editmode.
So in a way the situation is similar to 2a8ce1f121
Behavior of `animchan_sync_group` is not reliable in a way that getting
a `bPoseChannel` from an `bActionGroup` will guarantee these are really
corresponding. So usually, if you dulplicate/symmetrize a bone, there
would be no corresponding `bActionGroup` and nothing would happen
really. But you could for example group fcurves from `Bone` under a
group called `Bone.001` and vice versa. This is totally allowed to do.
In this case, `animchan_sync_group` is doing nothing totally helpful, so
it could find the "wrong" `bPoseChannel`. And it could try
`action_group_colors_set_from_posebone` with that `bPoseChannel` which
still does not have a `bone` and then crash.
So now only do this if we have a valid `bone`.
Pull Request: https://projects.blender.org/blender/blender/pulls/118676
The depsgraph CoW mechanism is a bit of a misnomer. It creates an
evaluated copy for data-blocks regardless of whether the copy will
actually be written to. The point is to have physical separation between
original and evaluated data. This is in contrast to the commonly used
performance improvement of keeping a user count and copying data
implicitly when it needs to be changed. In Blender code we call this
"implicit sharing" instead. Importantly, the dependency graph has no
idea about the _actual_ CoW behavior in Blender.
Renaming this functionality in the despgraph removes some of the
confusion that comes up when talking about this, and will hopefully
make the depsgraph less confusing to understand initially too. Wording
like "the evaluated copy" (as opposed to the original data-block) has
also become common anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118338
The `object_to_world` and `world_to_object` matrices are set during
depsgraph evaluation, calculated from the object's animated location,
rotation, scale, parenting, and constraints. It's confusing and
unnecessary to store them with the original data in DNA.
This commit moves them to `ObjectRuntime` and moves the matrices to
use the C++ `float4x4` type, giving the potential for simplified code
using the C++ abstractions. The matrices are accessible with functions
on `Object` directly since they are used so commonly. Though for write
access, directly using the runtime struct is necessary.
The inverse `world_to_object` matrix is often calculated before it's
used, even though it's calculated as part of depsgraph evaluation.
Long term we might not want to store this in `ObjectRuntime` at all,
and just calculate it on demand. Or at least we should remove the
redundant calculations. That should be done separately though.
Pull Request: https://projects.blender.org/blender/blender/pulls/118210
