Brush and pose asset operators were doing some avoidable roundtrips
through asset types, lookups and rather low level operations. This
indicates that the asset system APIs need some improvements. Moving
lower-level logic there can help avoiding errors, since implementation
details are kept inside the corresponding module.
- Avoid lookups for asset library reference in operator code, make asset
library itself construct it.
- Avoid redundant lookups for asset library definition (was looking up
the asset library definition in the Preferences from the library
reference type, just to turn it into the reference type again).
- Add utility for refreshing loading asset libraries
- Add utility for saving asset catalogs for an asset
- Remove unused function
Copy-paste of keyframes is now slot-aware. See [1] for the design.
[1]: https://developer.blender.org/docs/features/animation/tools/action-editor-copy-paste/
In short:
- Copy-paste still works broadly as it used to. Only the visible
F-Curves are pasted into.
- Slot identifiers matter when copying from multiple slots. When
copying from one slot, they don't.
- Selection of channels (either F-Curves or Slots) determines where
keys get pasted into.
- Pasting will either copy from the slot with the same identifier
(when identifiers matter), or paste whatever was copied (when they
do not).
- If both F-Curves and slots are selected, only the selected F-Curves
get pasted into, and slots without any selected F-Curves are ignored
(i.e. target is only defined by selected F-Curves, or only by
selected slots, never by a mixture).
Fixes#129690
Pull Request: https://projects.blender.org/blender/blender/pulls/133979
Similar to how brush assets are created and managed this
PR allows to export pose assets into a different library.
Because of this there is a limitation to this where each
asset is stored in a separate blend file.
This may be lifted in the future as there are planned changes in
the design phase: #122061
### Create Asset
Now available in the 3D viewport in the "Pose" menu: "Create Pose Asset".
The button in the Dope Sheet will now call this new operator as well.
Clicking either of those will open a popup in which you can:
* Choose the name of the asset, which library and catalog it goes into.
* Clicking "Create" will create a pose asset on disk in the given library.
It is possible to create files into an outside library or add it in the current file.
The latter option does a lot less since it basically just creates the
action and tags it as an asset.
If no Asset Shelf **AND** no Asset Browser is visible anywhere in Blender,
the Asset Shelf will be shown on the 3D viewport from which
the operator was called.
### Adjust Pose Asset
Right clicking a pose asset that has been created in the way described
before will have options to overwrite it.
Only the active object will be considered for updating a pose asset
Available Options (the latter 3 under the "Modify Pose Asset" submenu):
* Adjust Pose Asset: From the selected bones, update ONLY channels that
are also present in the asset. This is the default.
* Replace: Will completely replace the data in the Pose Asset from
the current selection
* Add: Adds the current selection to the Pose Asset. Any already existing
channels have their values updated
* Remove: Remove selected bones from the pose asset
Currently this refreshes the thumbnail. In the case of custom
thumbnails it might not be something want
### Deleting an existing Pose Asset
Right click on a Pose Asset and hit "Delete Pose Asset". Works in the shelf
and in the asset library. Doing so will pop up a confirmation dialog,
if confirming, the asset is gone forever. Deleting a local asset is basically the
same as clearing the asset. This is a bit confusing because you get
two options that basically do the same thing sometimes,
but "Delete" works in other cases as well.
I currently don't see a way around that.
Part of design #131840
Pull Request: https://projects.blender.org/blender/blender/pulls/132747
Use streaming to `std::cout` for debug prints, rather than using
`printf()`. Different compilers disagree on the `printf()` format string
for `int64_t`: GCC thinks it should be `%ld` while Clang says `%lld`,
and either will emit a warning when the other's preference is used.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/133857
Refactor the keyframe copy-paste code to prepare for supporting action slots.
This is a non-functional change, as the slots are stored but otherwise completely ignored. This way the refactor to the new data structure can be reviewed & tested before actually changing the behaviour.
Related: #129690
Pull Request: https://projects.blender.org/blender/blender/pulls/133497
There were three methods with succinct but slightly unclear names:
- Action::slot_move()
- Channelbag::channel_group_move()
- Channelbag::fcurve_move()
The ambiguity is due to other functions with similar names that e.g.
move fcurves *between* Channelbags, etc. Whereas these methods only move
items to other positions within the array they're already in.
To make this clearer, this PR adds `_to_index` to the end of these
array-oriented methods.
Pull Request: https://projects.blender.org/blender/blender/pulls/133730
This updates the Move Channels operator in the Action Editor channel list to
also work with Slots, allowing Slots to be reordered within an Action.
Note that the Move Channels operator already had interesting behavior when
channels are selected in multiple levels of the channel hierarchy (e.g. when
both channel groups and f-curve channels are selected). For Slots, I've chosen
a simpler behavior: if any Slot is moved, all non-Slot channels (i.e. those
lower in the hierarchy) are left alone.
In the future we may want to change channel group rearrangement to work the same
way with respect to f-curve channels, but I've left that alone for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/133328
When moving an object with a motion path and animdata but no assigned
action, and with certain auto-key settings enabled, Blender would crash.
The cause was code that tried to access an action's fcurves without
proper guarding: the guard checked whether an object had animdata, but
not whether it had an action assigned or not, and would happily try to
access that non-existent action's fcurves.
This fixes the crash by also checking if an action is assigned.
Pull Request: https://projects.blender.org/blender/blender/pulls/133552
This changes the `ListBase` argument for certain motion path functions
to `Vector<MPathTarget *>`. (and `Span`)
To better describe what the function is doing,
`animviz_get_object_motionpaths` has been renamed
to `animviz_build_motionpath_targets`.
Since `BLI_freelistN` can no longer be used, I added
`animviz_free_motionpath_targets`.
Note that the Vector is of `MPathTarget *` which
are allocated the C way. Because the `MPathTarget` struct is defined
in the .cc file, that's the only way for it to work atm.
Other refactors may mitigate that in the future, but I wanted to keep
the scope small.
Pull Request: https://projects.blender.org/blender/blender/pulls/133212
This PR adds new RNA properties that deprecate and replace any `sequence` property.
The old prooperties are still there and fully functional, but the description is changed
to indicate that these will be removed in the future and that the new properties should
be used instead.
| Deprecated property | Replacement property |
| --------------------------------- | ----------------------------------- |
| `context.active_sequence_strip` | `context.active_strip` |
| `context.selected_editable_sequences` | `context.selected_editable_strips` |
| `context.selected_sequences` | `context.selected_strips` |
| `context.sequences` | `context.strips` |
| `SequenceEditor.sequences` | `SequenceEditor.strips` |
| `SequenceEditor.sequences_all` | `SequenceEditor.strips_all` |
| `MetaStrip.sequences` | `MetaStrip.strips` |
Previously, rna paths for animation data on strips started with `sequence_editor.sequences`.
This PRadds versioning for the rna paths to make sure to use
the new naming scheme. This does mean that in previous versions of blender,
the animations don't show but the data is not lost (even if the file is saved in the older version).
Also do some cleanup of existing python scripts inside the source to use the
new properties.
Part of #132963.
Pull Request: https://projects.blender.org/blender/blender/pulls/133156
This uses the following accessor methods in more places in more places:
`is_group()`, `is_group_input()`, `is_group_output()`, `is_muted()`,
`is_frame()` and `is_reroute()`.
This results in simpler code and reduces the use of `bNode.type_legacy`.
Pull Request: https://projects.blender.org/blender/blender/pulls/132899
Replace pointer magic with `std::string` and `blender::StringRef`.
The old code modified the RNA path of F-Curves to extract & flip the
bone name. The new code is not modifying any data, at the expense of a
few more copies. Since these strings are not long, and the call to
`BLI_string_flip_side_name()` also makes quite a few copies, the
performance impact should be negligible.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/133005
Simplify `pastebuf_match_path_property()` by reducing cognitive complexity
and using `StringRef::endswith()` instead of pointer arithmetic.
I've also added a few unit test cases that cover some unwanted behavior:
the property name check only checks suffixes, and so copying "….location"
will also paste it to a "….not_actually_location" F-Curve.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/133005
Add a unit test for the bone name flipping function of the keyframe
paste functionality.
The function itself has been changed a little bit, so that it returns a
`std::string` instead of using a `char **` return parameter that needs
explicit freeing at the call site. This made the tests considerably
simpler to write. This change does cause an extra copy of the RNA path,
but that should be refactored away soon.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/133005
- Previously, `change_frame_invoke` always ran
`sequencer_skip_for_handle_tweak` check, even if the user was not
using the sequencer. Now, the check is only done if the user is in the
sequencer, where it is possible for them to tweak strips.
- It is now impossible to change the frame from the sequencer preview,
so remove that logic.
- Also add some explanatory comments for RCS keymap logic in the code.
The new description for `bNode.type_legacy`:
```
/**
* Legacy integer type for nodes. It does not uniquely identify a node type, only the `idname`
* does that. For example, all custom nodes use #NODE_CUSTOM but do have different idnames.
* This is mainly kept for compatibility reasons.
*
* Currently, this type is also used in many parts of Blender, but that should slowly be phased
* out by either relying on idnames, accessor methods like `node.is_reroute()`.
*
* A main benefit of this integer type over using idnames currently is that integer comparison is
* much cheaper than string comparison, especially if many idnames have the same prefix (e.g.
* "GeometryNode"). Eventually, we could introduce cheap-to-compare runtime identifier for node
* types. That could mean e.g. using `ustring` for idnames (where string comparison is just
* pointer comparison), or using a run-time generated integer that is automatically assigned when
* node types are registered.
*/
```
Pull Request: https://projects.blender.org/blender/blender/pulls/132858
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
This renames the struct `Sequence` to `Strip`.
While the motivation for this partially comes from
the "Sequence Design" #131329, it seems like this
is a good refactor whether the design gets implemented
or not.
The `Sequence` represents what users see as strips in the
VSE. Many places in the code already refere to a `Sequence`
as "strip". It's the C-style "base class" of all strip types.
This also renames the python RNA type `bpy.types.Sequence`
to `bpy.types.Strip` which means that this technically breaks
the python API.
Pull Request: https://projects.blender.org/blender/blender/pulls/132179
This code is now only used by annotations but was not updated.
Uses the right properties now and removes the layer mask
one which is not used by annotations.
Pull Request: https://projects.blender.org/blender/blender/pulls/132030
This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
Give the `IDWALK_CB_…` enum an explicit name:
`LibraryForeachIDCallbackFlag`. This way the flags are type-safe, and
it's known where values come from. This is much preferred (at least by
me) to just having `int flags`.
Uses of `0` have been replaced with `IDWALK_CB_NOP` as that has the same
value and is of the right type.
One invalid use of `IDWALK_NOP` was detected by this change, and is
replaced by `IDWALK_CB_NOP`.
This change might be incomplete; I gave the enum a name, fixed the
compiler errors, and then also updated assignments like `int cb_flag =
cb_data->cb_flag`. I might have missed some assignments to `int` though.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131865
This PR improves the animation editor's display of node socket property
animation names, and names from geometry nodes modifier inputs. In both
cases, the names currently displayed are not very useful.
For geometry nodes inputs, the we now look up the name of the the input
rather than just displaying the identifier from the IDProperty name.
For node sockets, we now display the name of the socket instead of just
"Default Value" (which is technically the name of the RNA property).
We also display the label of the node if it's available. We also display
node labels instead of names for node properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/131766
Two commits that basically do the same thing for two `enum`s: give
them a name.
- the `IDWALK_…` enum → `LibraryForeachIDFlag`.
- the `IDWALK_CB_…` enum → `LibraryForeachIDCallbackFlag`.
This way the flags are type-safe, and it's known where values come
from. This is much preferred (at least by me) to just having `int
flags`.
Uses of `0` have been replaced with `IDWALK_NOP` and `IDWALK_CB_NOP`,
as those have the same value and are of the right type.
One invalid use of `IDWALK_NOP` was detected by this change, and is
replaced by `IDWALK_CB_NOP`. And another one in the opposite
direction.
This change might be incomplete; I gave the enum a name, fixed the
compiler errors, and then also updated assignments like `int cb_flag =
cb_data->cb_flag`. I might have missed some assignments to `int`
though.
No functional changes.
----------
I intend to land this PR as its two separate commits. I just put them in the same PR so the buildbot can handle them in one go, and we don't have a stack of highly relatled PRs.
In the future this could also apply to the `IDWALK_RET_…` enum. This one I left out, though, because a proper cleanup there would also have to include their ambiguity on whether they are bitflags (like the enums in this PR) or not. Their values and the code in `BKE_lib_query_foreachid_process()` implies they are bitflags, but in practice they are never or'ed together and just used as discrete values.
Pull Request: https://projects.blender.org/blender/blender/pulls/131803
