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
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
Store the 'expanded/collapsed' state of the bone collection tree view in
the DNA data of the bone collections themselves. This way the tree state
is restored when loading the file.
This commit also adds some code to the abstract tree view classes, for
supporting synchronisation of the extended/collapsed state between it
and external data. It follows the same approach as the handling of the
active element.
RNA wrappers have been added to make it possible for Python code to
expand/collapse parts of the tree.
Library overrides are supported for this property, so the
expanded/collapsed state of linked armatures can be locally saved. If
there is no override, the `is_expanded` property is still editable;
changes will not be saved to file in that case, though.
Pull Request: https://projects.blender.org/blender/blender/pulls/116940
This significantly simplifies memory management, mostly by avoiding
the need to free the memory manually. It may also improve performance,
since std::string has an inline buffer that can prevent heap
allocations and it stores the size.
Pull Request: https://projects.blender.org/blender/blender/pulls/117695
After removing a bone collection that was marked as 'solo', refresh
the armature's 'solo active' flag. The deleted bone collection might have
been the last solo'ed one.
Add the 'solo' flag to bone collections, effectively adding another
layer of visibility controls.
If there is _any_ bone collection with this flag enabled, only this
collection (and others with this flag enabled) will be visible.
In RNA, the following properties are exposed:
- `bone_collection.is_solo`: writable property to manage the solo flag.
- `armature.is_solo_active`: read-only property that is `True` when any
bone collection has `is_solo = True`.
The RNA property `bone_collection.is_visible_effectively` now also takes
the solo flag into account.
Pull Request: https://projects.blender.org/blender/blender/pulls/117414
