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
Rename `BoneCollection::is_visible_effectively()` to
`is_visible_with_ancestors()`. Soon a "solo" flag will be introduced,
and the effective visibility of the bone collection will depend on that
too. This particular function doesn't take that into account, though,
and thus needs a rename.
Note that this does NOT rename the RNA property
`is_visible_effectively`. That will be updated when the "solo" flag is
introduced to also take that into account.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/117414
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
No functional changes.
In #116823 the function `remap_driver_frame` was moved,
but the name doesn't exactly correspond to what the function is doing.
Since it evaluates the driver, with different parameters, it is now called
`evaluate_driver_from_rna_pointer`.
We could maybe remove the function because it is only called once.
Pull Request: https://projects.blender.org/blender/blender/pulls/117294
No functional changes expected.
Before this PR the keyframing code was aware of driver specifics
and changed the frame where a key is inserted to the current driver value.
This is now changed so that the calling code needs to know where on the
FCurve the key should be inserted. This removes the need for the
`INSERTKEY_DRIVER` flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/116823
Fix an issue where, after deleting the active bone collection, the
incorrect bone collection became the active one.
The solution was to store the active bone collection index before
deletion, instead of after.
When autokeying a property with a driver, the code added
the keyframe into the drivers FCurve.
Judging by the code the intention was to be able to quickly
set up driven keys by modifying the driven value and have that
reflected in the driver curve.
However that idea was blocked by the fact that you can't actually
change the value of a property that is driven.
In addition to that it's quite unexpected and the result is hardly
communicated to the user.
The solution is to not insert keyframes to drivers using the
autokeying system.
Also Fixes#95866
This was discussed in the A&R module meeting
https://devtalk.blender.org/t/2024-01-11-animation-rigging-module-meeting/32888#patch-review-decision-time-5
and the consensus was the feature to set up driven keys would be great,
but since it's not working at all currently it's better to get rid of the bugs.
Pull Request: https://projects.blender.org/blender/blender/pulls/116927
The previous commit introduced a new `RPT_()` macro to translate
strings which are not tooltips or regular interface elements, but
longer reports or statuses.
This commit uses the new macro to translate many strings all over the
UI.
Most of it is a simple replace from `TIP_()` or `IFACE_()` to
`RPT_()`, but there are some additional changes:
- A few translations inside `BKE_report()` are removed altogether
because they are already handled by the translation system.
- Messages inside `UI_but_disable()` are no longer translated
manually, but they are handled by a new regex in the translation
system.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
`armature.collections.move(x, y)` now retains the active collection. Due to
the move, the active collection index can change. The index is now updated
to accomodate for this.
Ensure that the active bone collection doesn't change, when adding a new
bone collection via low-level functions (for example
`armature.collections.new()` in Python).
The change to the active bone collection happened because adding a new
child may change the index of the active bone collection.
Instead of moving bone collections by absolute index, they can now be
moved by manipulating `.child_number`. This is the relative index of the
bone collection within the list of its siblings.
This replaces the much more cumbersome `collections.move_to_parent()`
function. Since that function is now no longer necessary (it's been
replaced by assignment to `.parent` and `.child_number`), it's removed
from RNA. Note that this function was never part of even a beta build of
Blender.
The `expect_bcolls()` function now no longer calls the `EXPECT_EQ` macro,
but returns a `testing::AssertionResult` instead. The function call does
need to be wrapped in an `EXPECT_TRUE()` call now, but that also means that
any failure message points directly to the call site.
Bone collection visibility now respects their hierarchy.
A bone collection is only visible when it is marked as visible and all
its ancestors (so parents, greatparents, etc.) are visible. Root bone
collections have no ancestors by definition, and only consider their own
visibility.
The effective ancestors' visibility is stored on each bone collection,
in its `BONE_COLLECTION_ANCESTORS_VISIBLE` flag. This makes it possible
to determine the effective visibility from just the flags of the bone
collection itself.
The `BONE_COLLECTION_ANCESTORS_VISIBLE` flag is now stored, with the
other flags, in `BoneCollection::flags`. This means that it's stored in
DNA, even though it's derived data and should actually be stored in a
runtime struct. However, `BoneCollection` doesn't have any runtime
struct yet, and I don't feel that the introduction of this flag is a
good enough reason to introduce that just yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/116784
Rename `ANIM_bonecoll_is_visible(armature, bone)` to
`ANIM_bone_in_visible_collection(armature, bone)`, as that reflects the
actual functionality.
No functional changes.
Bundling many tests in a single binary reduces build time and disk space
usage, but is less convenient for running individual tests command line
as filter flags need to be used.
This adds WITH_TESTS_SINGLE_BINARY to generate one executable file per
source file. Note that enabling this option requires a significant amount
of disk space.
Due to refactoring, the resulting ctest names are a bit different than
before. The number of tests is also a bit different depending if this
option is used, as one uses gtests discovery and the other is organized
purely by filename, which isn't always 1:1.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114604
Make it possible to nest bone collections. The data structure on the
armature is still a flat array. It is organised as follows:
- Sibling collections (i.e. ones with the same parent) are stored
sequentially in the array.
- Each bone collection keep track of the number of children, and the
index of the first child.
- Root collections (i.e. ones without parent) are stored as the first
elements in the array.
- The number of root collections is stored on the Armature.
This commit also contains the following:
- Replaced the flat UIList of bone collections with a tree view.
- Updated the M/Shift+M operators (move/assign to collection) to work
with hierarchical bone collections.
- Updated RNA interface to expose only root collections at
`armature.collections`. All collections are available on
`armature.collections.all`, and children at `bonecollection.children`.
- Library override support. Only new roots + their subtrees can be added
via overrides.
See https://projects.blender.org/blender/blender/issues/115934
Co-authored with @nathanvegdahl and @nrupsis.
Pull Request: https://projects.blender.org/blender/blender/pulls/115945
Rename `bonecoll_find_index` to `armature_bonecoll_find_index` (because
it takes a `bArmature*` parameter), and move it from a static function into
the `blender::animrig` namespace. It will be used externally in upcoming
commits.
No functional changes.
Move some of the functionality of `ANIM_armature_runtime_refresh()` into
a function of its own (`ANIM_armature_bonecoll_active_runtime_refresh()`).
It will be called from another place as well in upcoming commits.
No functional changes.
The return value of `get_rotation_mode_path` was stored in a
`blender::StringRef` which caused the memory of the string to
be freed to early.
Fix by returning a `blender::StringRef`
Interestingly this seems to be only an issue on ASAN builds.
Pull Request: https://projects.blender.org/blender/blender/pulls/116434
Editability checks shouldn't just check for linked data & library
overrides, but also for the type of library override. A "system
override" should still not be editable by users.
This fixes#115310: Bone collections can be added to system-overridden
(i.e. non-user-editable) armatures
The issue occurs when auto-keyframe AND "Only Insert Needed" enabled.
And only when no keyframes have been added yet.
Before the commit that caused the issue, moving an object with `G` would
create only location keyframes. After it would key all.
That is because that commit removed the logic that checks the
`eTfmMode` (Transform mode). That only works as long as there are already
keyframes on the object/bone because the logic needs an
existing value to compare against. In the case where the first keyframe is set,
it would always key everything.
The fix is to bring back the logic that checks the Transform mode and pass
a `Span` of rna paths to the autokeyframe function. This restores the behavior.
This still has the issue that "Only Insert Needed" behaves differently if
keys exist vs inserting the first keys. While this isn't ideal, I don't see a way
to get values of an object/bone before and after the transformation.
We might be able to fix this in a future PR, but for now we restore the
old behavior.
Caused by #115522
Pull Request: https://projects.blender.org/blender/blender/pulls/116219
No functional changes.
Move the function ED_id_action_ensure to animrig,
and rename it to `id_action_ensure`.
This is in order to reduce references from animrig
to the editor code.
Pull Request: https://projects.blender.org/blender/blender/pulls/116101
