Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
The root cause of this bug can be traced to:
- `ANIM_nla_mapping_get(ac, ale)` conditionally returns an `AnimData *adt`.
- This can be `nullptr` in various cases, depending on the editor (in `ac`) and
the type & source of data (in `ale`).
- This `nullptr` has different meanings:
1. There is not enough information to return an `adt` (like `ac` or `ale`
being `nullptr` themselves).
2. NLA time remapping should not be done. For example for NLA control F-Curves
(like animated strip influence), or Grease Pencil (because that doesn't use
the NLA).
- The above-returned `adt` is passed to other functions. Some of them are aware
of the "`nullptr` means no NLA time remapping" scenario, and gracefully handle
it. Other code, however, just gets "an adt" from the caller and handles it as
normal (and likely crashes on `nullptr`). Other cases start out as the first,
but somewhere in the call stack shift over to the second.
The approach taken in this PR to fix the bug is to (generally) stop signaling
"do not use NLA time remapping" via `adt = nullptr`, and instead explicitly
indicate/check whether remapping should be done.
In most cases this means passing a `bAnimListElem *` instead of an `AnimData *`,
because the former has the information needed to determine if time remapping
should be done or not. However, in some cases there is no `bAnimListElem *` to
pass, and instead other information determines whether remapping is needed. In
those cases we add a `bool` parameter or field in the appropriate place so that
calling code can explicitly indicate whether remapping should be done or not.
To accomplish this a variety of functions have been added to help handle things
correctly. Of particular note:
- `AnimData *ANIM_nla_mapping_get(ac, ale)` (that conditionally returned an
`adt`) has been removed entirely in favor of the new
`bool ANIM_nla_mapping_allowed(ale)` function that simply returns whether
nla remapping should be done or not.
- `ANIM_nla_tweakedit_remap(ale, …)` has been added, which wraps
`BKE_nla_tweakedit_remap(adt, …)` and only performs the remapping when
`ANIM_nla_mapping_allowed()` indicates that it's allowed.
- `ANIM_nla_mapping_apply_if_needed_fcurve(ale, …)` has been added, which is an
alternative to `ANIM_nla_mapping_apply_fcurve(adt, …)` that also only performs
the remapping when `ANIM_nla_mapping_allowed()` indicates that it's allowed.
Note that even with this PR there are still a couple of places remaining that
use `adt = nullptr` to indicate "don't remap", because they appear to be correct
and would require larger changes to make explicit. In those cases comments have
been added to explain the situation, with a reference to this PR. In the future
we way want to take the time to change those as well.
Also of minor note: this PR moves the definition of the type `slot_handle_t`
from ANIM_action.hh to BKE_action.hh. This is due to `BKE_nla.hh` (which needs
that definition) now being included directly and indirectly in a lot more
places. Moving the definition to BKE_action.hh prevents all of those new places
from gaining dependencies on the animrig module.
Co-authored-by: Sybren A. Stüvel <sybren@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/130440
In the Dope Sheet, show regular keyframes for GreasePencil object data.
The GPv3 transition missed a few cases in the animation
channel/filtering code to add the channels from regular Actions on
GreasePencil data blocks.
Pull Request: https://projects.blender.org/blender/blender/pulls/129807
This commit takes the 'Slotted Actions' out of the experimental phase.
As a result:
- All newly created Actions will be slotted Actions.
- Legacy Actions loaded from disk will be versioned to slotted Actions.
- The new Python API for slots, layers, strips, and channel bags is
available.
- The legacy Python API for accessing F-Curves and Action Groups is
still available, and will operate on the F-Curves/Groups for the first
slot only.
- Creating an Action by keying (via the UI, operators, or the
`rna_struct.keyframe_insert` function) will try and share Actions
between related data-blocks. See !126655 for more info about this.
- Assigning an Action to a data-block will auto-assign a suitable Action
Slot. The logic for this is described below. However, There are cases
where this does _not_ automatically assign a slot, and thus the Action
will effectively _not_ animate the data-block. Effort has been spent
to make Action selection work both reliably for Blender users as well
as keep the behaviour the same for Python scripts. Where these two
goals did not converge, reliability and understandability for users
was prioritised.
Auto-selection of the Action Slot upon assigning the Action works as
follows. The first rule to find a slot wins.
1. The data-block remembers the slot name that was last assigned. If the
newly assigned Action has a slot with that name, it is chosen.
2. If the Action has a slot with the same name as the data-block, it is
chosen.
3. If the Action has only one slot, and it has never been assigned to
anything, it is chosen.
4. If the Action is assigned to an NLA strip or an Action constraint,
and the Action has a single slot, and that slot has a suitable ID
type, it is chosen.
This last step is what I was referring to with "Where these two goals
did not converge, reliability and understandability for users was
prioritised." For regular Action assignments (like via the Action
selectors in the Properties editor) this rule doesn't apply, even though
with legacy Actions the final state ("it is animated by this Action")
differs from the final state with slotted Actions ("it has no slot so is
not animated"). This is done to support the following workflow:
- Create an Action by animating Cube.
- In order to animate Suzanne with that same Action, assign the Action
to Suzanne.
- Start keying Suzanne. This auto-creates and auto-assigns a new slot
for Suzanne.
If rule 4. above would apply in this case, the 2nd step would
automatically select the Cube slot for Suzanne as well, which would
immediately overwrite Suzanne's properties with the Cube animation.
Technically, this commit:
- removes the `WITH_ANIM_BAKLAVA` build flag,
- removes the `use_animation_baklava` experimental flag in preferences,
- updates the code to properly deal with the fact that empty Actions are
now always considered slotted/layered Actions (instead of that relying
on the user preference).
Note that 'slotted Actions' and 'layered Actions' are the exact same
thing, just focusing on different aspects (slot & layers) of the new
data model.
The "Baklava phase 1" assumptions are still asserted. This means that:
- an Action can have zero or one layer,
- that layer can have zero or one strip,
- that strip must be of type 'keyframe' and be infinite with zero
offset.
The code to handle legacy Actions is NOT removed in this commit. It will
be removed later. For now it's likely better to keep it around as
reference to the old behaviour in order to aid in some inevitable
bugfixing.
Ref: #120406
Rename 'Binding' to 'Slot'. The old term was causing all kind of
confusion, and 'slot' was considered to be a better term for the
intended functionality.
This commit breaks existing blend files that were using the new layered
Action for their animation. The animation data will be lost due to the
rename, as there is no versioning code or DNA renaming logic. At this
time the new system is still marked as experimental, so shouldn't be
used for anything serious anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/124170
In the Action mode of the Dope Sheet, show the Bindings, optionally
showing all Bindings in that Action. This also works when different
data-block types are animated from the same Action.
Bindings are selectable in the Action editor with box/range select.
Since there is no use for an 'active Binding' yet, this has not been
implemented, and as a result, clicking on a Binding does nothing.
Note on 'Binding' vs 'Slot': this code change was created before the
decision to change the name from 'Bindings' to 'Slots'. To avoid
confusion, and to keep this PR in sync with the code changes, it still
uses the term 'binding'. Renames of 'Binding' to 'Slot' in the code will
happen after this PR lands.
Pull Request: https://projects.blender.org/blender/blender/pulls/122672
Add new ID_IS_EDITABLE macro that checks if the ID can be edited in the
user interface. Replace usage of ID_IS_LINKED where it is used with this
meaning.
Also add a corresponding ID.is_editable property for Python.
This prepares for the ability to edit some linked datablocks for brush
assets.
Pull Request: https://projects.blender.org/blender/blender/pulls/121838
The new/experimental, layered `Animation` data-block is merged with the
existing `bAction` data-block.
The `Animation` data-block is considerably newer than `bAction`, so the
supporting code that was written for it is also more modern. When moving
that code into `bAction`, I chose to keep the modernity where possible,
and thus some of the old code has been updated as well. Things like
preferring references over pointers.
The `Animation` data-block is now gone from DNA, the main database, etc.
As this was still an experimental feature, there is no versioning code
to convert any of that to Actions.
The DNA struct `bAction` now has a C++ wrapper `animrig::Action`, that
can be obtained via `some_action->wrap()`.
`animrig::Action` has functions `is_empty()`, `is_action_legacy()`, and
`is_action_layered()`. They **all** return `true` when the Action is
empty, as in that case none of the data that makes an action either
'legacy' or 'layered' is there.
The 'animation filtering' code (for showing things in the dope sheet,
graph editor, etc) that I wrote for `Animation` is intentionally kept
around. These types now target 'layered actions' and the
already-existing ones 'legacy actions'. A future PR may merge these two
together, but given how much work it was to add something new there, I'd
rather wait until the dust has settled on this commit.
There are plenty of variables (and some comments) named `anim` or
`animation` that now are of type `animrig::Action`. I haven't renamed
them all, to keep the noise level low in this commit (it's already big
enough). This can be done in a followup, non-functional PR.
Related task: #121355
Pull Request: https://projects.blender.org/blender/blender/pulls/121357
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
Add a new keyframe type named 'generated', which is meant to indicate
that the key was set by some automated tool (like an add-on), rather
than manually by an animator.
This is meant for tooling that needs to create keys in a repeatable way.
With this new key type, the tool can know which keys it generated
before, and thus those can be removed and re-generated.
Pull Request: https://projects.blender.org/blender/blender/pulls/120564
The theme has a color for each keyframe type. This is exposed in RNA and
the preferences UI as an RGB color, so without alpha channel. The code
that loads the color from the theme, however, does include that
unsettable alpha channel, though.
In practice this doesn't cause issues, as the versioning code ensures
that the default colors are stored with `alpha=uint8_t(255)`. While
developing, however, this caused me considerable headscratching, as I
was missing that little bit of versioning code, which means that the
default color was set to all-zeroes, and thus had a zero alpha.
This is now resolved by altering the drawing code to only load the RGB
component from the theme. This way only the user-settable bytes are
loaded, while the alpha component is handled a different way (setting it
to an absolute value, instead of multiplying the theme value).
No user-perceivable changes, just some developer comfort.
Pull Request: https://projects.blender.org/blender/blender/pulls/120311
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
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
# Issue
Having a lot of keys in your scene can dramatically slow down the Dope Sheet.
That is because everytime the Dope Sheet is redrawn,
the Keylists have to be recomputed.
In the case of the summary channel, that means going through
all keyframes of all the `FCurves` and adding them to the keylist.
That eats up 95% of the time it takes to draw a frame.
# This PR
It's not a perfect solution, rather it solves the performance issue
for the case when you are not displaying all keys.
Instead of going through all the keys, only add the
keys visible in the view to the keylist.
This speeds up the Dope Sheet significantly
depending on the zoom level.
This also improves the responsiveness when selecting and transforming keyframes.
# Performance changes
The function measured is `ED_channel_list_flush`
which is responsible for building the keylists and drawing them.
The test setup contains 62 bones with all
10 channels keyed (location, rot quaternion, scale) on 6000 frames.
So 3.720.000 keys. The heavier the dataset the bigger the performance impact.
The data was recorded with only the Dope Sheet open, and 3 channels visible
* Summary
* Object
* Action
The more channels are visible, the greater the performance gain. This can be seen in the video.
| visible range | before | after |
| - | - | - |
| 200f | 250ms | 10ms |
| 400f | 250ms | 18ms |
| 3000f | 250ms | 130ms |
| 6000f | 250ms | 250ms |
Pull Request: https://projects.blender.org/blender/blender/pulls/114854
No functional changes.
While looking at the Dope Sheet drawing code to see if it
can be made faster I came across a bunch of functions with confusing names.
This PR tries to address that by:
* removing the `ED_` prefix from static functions
* adding it to non static functions
* renaming `AnimKeylistDrawListElem` to `ChannelListElement`
* renaming `AnimKeylistDrawList` to `ChannelDrawList`
* all `draw_..._channel` renamed to `ED_add_..._channel`
since the function itself doesn't actually do any drawing
* generally simplifying the function names
Pull Request: https://projects.blender.org/blender/blender/pulls/111510
Update of the following operators to take into account
grease pencil frames :
* SCREEN_OT_keyframe_jump, which jumps to the average
position of the selected frames, and
* ACTION_OT_frame_jump, which jumps to the previous/next
frame in the active channel.
Pull Request: https://projects.blender.org/blender/blender/pulls/111476
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
This patch adds layer widgets in the grease pencil layer channels of the grease pencil dopesheet.
It adds RNA + getter function for the `use_onion_skinning` at layer level.
It also sets the offset of the channel, and the color of grease pencil data-block channels.
Pull Request: https://projects.blender.org/blender/blender/pulls/110991
This patch includes keyframes for both the summary channel, and grease pencil data-block channels.
It also includes selection in these channels, in the same modes as the ones implemented for grease pencil keyframes.
Pull Request: https://projects.blender.org/blender/blender/pulls/110962
