One of the multiple code paths converting deprecated IPOs to modern
Actions/FCurves was for some reason not ensuring that the ID had a valid
AnimationData...
Instead of assigning Actions by direct pointer manipulation (and the
corresponding juggling of user counts), call `animrig::assign_action()`
and `animrig::unassign_action()`.
These functions not only correctly handle user counts, but also ensure
that slot assignments & user tracking works. The former always happens,
the latter only when building with experimental features enabled.
Because (un)assigning slotted Actions need the animated ID (instead of
just the `AnimData *`), more functions now require an `OwnedAnimData`.
Note that there is still some user count juggling. This is caused by
`BKE_id_new()`, and by extension `BKE_action_add`, returning an ID with
user count = 1, even though that ID is not yet used. A todo task #128017
has been made to change `BKE_action_add()` so that the Action it returns
can be directly fed into `animrig::assign_action()`.
This PR updates the following areas:
- Creating a node group by grouping animated nodes, as this has to move
the animation data. This PR just handles the assignment of a new
Action.
- Temporary Action creation for ungrouping node groups.
- Versioning of pre-2.5 animation data.
No functional changes.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/128026
Instead of simply reassigning the `adt->action` and `adt->tmpact` pointers,
the code now uses the `animrig::assign_action()` and `assign_tmpaction()`.
This way the slot user maps should be properly updated.
Pull Request: https://projects.blender.org/blender/blender/pulls/128030
This way we'll get a compiler warning when a new brush type is added,
and not handled in the switch. Plus a runtime warning when an invalid
value is cast to the enum. Both can help catching errors.
When I was learning VSE code, MAXSEQ constant (a preprocessor define!) was
confusing. It makes it sound like it is "max sequences", but it is actually
"max channels". So rename it to SEQ_MAX_CHANNELS and make it C++ constexpr int
instead of preprocessor macro.
Pull Request: https://projects.blender.org/blender/blender/pulls/128024
This function adds a key into multiple layers. This is more efficient than
inserting a single key multiple times in a loop, because the drawing
array has to be resized one-by-one.
In this function, the resizing happens at once.
Pull Request: https://projects.blender.org/blender/blender/pulls/127930
Part of #118145.
This commit removes the `PBVHVertRef` abstraction and changes the last
remaining usage of it. The `raycast_node` API has been turned into a
static function and the corresponding typed APIs exposed for direct
usage.
Pull Request: https://projects.blender.org/blender/blender/pulls/127933
Design: https://projects.blender.org/blender/blender/issues/126032
The brush assets project merged all brush based tools into a single, "Brush"
tool. After feedback, we want to bring back some of the previous brush based
tools. For example in grease pencil draw mode, not having an eraser or fill tool
available, and having to go through all the brush assets instead made the
workflow more cumbersome, and features less discoverable (an eraser tool in the
toolbar is quite easy to find, a brush deep down in the asset library may not
be).
With this commit we can add back some tools for specific brush types in sculpt &
paint modes. The follow up commit will start with the eraser and fill tools for
grease pencil draw mode, but more tools in other modes are expected to follow.
For every brush type that has a tool in the toolbar, the last used brush is
remembered. This is the biggest part of the changes here.
Brush asset popups will only show the brushes supported by the active tool for
now. The permanent asset shelf region displays all brushes. Activating a brush
that isn't compatible with the current tool will also activate the general
"Brush" tool, but while the brush tool is active we never switch to another one
(e.g. activating an eraser brush will keep the "Brush" tool active). All this
might change after further feedback.
Pull Request: https://projects.blender.org/blender/blender/pulls/125449
Previously, it was only possible to bake to disk with geometry nodes. This patch
adds support for storing the baked data directly in the .blend file.
By default, new bakes are stored in the .blend file now. Whether a new bake
should be packed or stored on disk can be configured in two places: in the
properties of the bake node and in the bake panel of the modifier. These
settings don't affect existing bakes, only the next bake.
To unpack or pack an individual bake, there is a new operator button next to the
bake button. The icon and the label below indicate where the bake is currently
stored. The label now also contains the size of the bake.
To unpack or pack all bakes, the `File > External Data > Pack Resources / Unpack
Resources` operators can be used. The unpack operator also has a new title that
mentions the number if individual files separate from the number of bakes. This
works better than just listing a number of files because a bake can consist of
many files.
Pull Request: https://projects.blender.org/blender/blender/pulls/124230
This commit adds low-level logic in BKE to support three behaviors in
case of name conflict when renaming an ID:
1. Always tweak new name of the renamed ID (never modify the other ID
name).
2. Always set requested name in renamed ID, modifying as needed the
other ID name.
3. Only modify the other ID name if it shares the same root name with the
current renamed ID's name.
It also adds quite some changes to IDTemplate, Outliner code, and
RNA-defined UILayout code, and the lower-level UI button API, to allow
for the new behavior defined in the design (i.e. option three from above list).
When renaming from the UI either 'fails' (falls back to adjusted name) or forces
renaming another ID, an INFO report is displayed.
This commit also fixes several issues in existing code, especially
regarding undo handling in rename operations (which could lead to saving
the wrong name in undo step, and/or over-generating undo steps).
API wise, the bahavior when directly assigning a name to the `ID.name`
property remains unchanged (option one from the list above). But a new
API call `ID.rename` has been added, which offers all three behaviors.
Unittests were added to cover the new implemented behaviors (both at
BKE level, and the RNA/Py API).
This commit implements #119139 design.
Pull Request: https://projects.blender.org/blender/blender/pulls/126996
Deleting ID would systematically call `BKE_main_collection_sync_remap`,
which would invalidate all collection caches. This should only be needed
when deleting a Scene, Collection or Object ID.
Pull Request: https://projects.blender.org/blender/blender/pulls/127866
Follow up to 5d40992fe8.
In the PBVH API, some contexts that take a `float *` parameter named
`depth` use it purely as a return value, other places, however, read
from and write to this parameter.
In the former case, this commit either adds or keeps the `r_` prefix, in
the latter, this commit ensures the parameter has no prefix to avoid
misleading future readers.
Pull Request: https://projects.blender.org/blender/blender/pulls/127886
Currently the `sum_group_sizes` call used to count the number
of elements in GPU vertex buffers for each PBVH node stands out
in profiles, taking a few percent of the total time when building
PBVH GPU data. Since the number of corners in a node doesn't
change, it's simpler to just store it in the node. We could
eventually cache it somewhere else too, if there was a benefit
to not storing it in the node itself.
A set of general tidying steps prior to making some PBVHVertRef changes
* Add const where possible
* Add r_ prefix for return parameters
* Use pass-by-reference instead of pointer for some return parameters
* Use std::array's .size() operator for some iteration bounds
* Use float3 for some variables
Pull Request: https://projects.blender.org/blender/blender/pulls/127832
This adds a new `BKE_id_name` function. It should be used in places where we
currently do something like `id.name + 2`.
This patch just adds the function and uses them in a small subset of possible
cases. Given that there are >700 cases that need to be replaced, I'd rather to
that in chunks instead of all at once.
Pull Request: https://projects.blender.org/blender/blender/pulls/127410
Skip the evaluation of the Action constraint when no Action is set.
Before, the constraint would run an entire animation data evaluation
cycle on a fake object, with the given (but NULL) Action. Now it's just
skipped.
Add some F-Curve getter functions that work in all these situations:
- Built without experimental features.
- Built with experimental features, and called with legacy Action.
- Built with experimental features, and called with layered Action.
No functional changes, just useful tools for migrating to the new
Actions API.
Ref: #120406
Pull Request: https://projects.blender.org/blender/blender/pulls/127841
Revert part of 9530852347 as that did not
take into account that the `max` property may actually be smaller than
the `min` property.
I've also taken the liberty to document this fact in some comments.
The fix for the crash when `min == max` is still in place.
This requires writing selection attributes to a different domain than
the Point domain.
Note that for assigning/removing from vgroups the `adapt_domain`
function is used implicitly by always looking up attributes from the
Point domain: ".selection" may be stored on Curves and will
automatically be adapted to points. For select-by-vgroup `adapt_domain`
cannot be used because the selection has to be "greedy" (one point
selects the whole curve).
Pull Request: https://projects.blender.org/blender/blender/pulls/127799
Saving for the first time or using save-as printed a summary, e.g.
`Total files 0 | Changed 0 | Failed 0`
When path operations were added it was only accessed from the UI,
where reporting a summary makes sense. Having the summary reported when
path manipulation is done as part of another action isn't useful.
It's also not clear what the summary relates to.
Now the summary is only shown in operator reports.
std::sort() requires a strict weak ordering, i.e. `x < x` must be false. Therefore `id_order_compare(ID *a, ID *b)` must return false for `a.name == b.name`
Pull Request: https://projects.blender.org/blender/blender/pulls/127794
Also return a pointer from `Layer::duplicate_with_shallow_strip_copies()`
rather than a reference, since it doesn't maintain ownership of the
returned item.
This updates the layered action data model to store strip data differently. Specifically:
- `Strip` is now just a single, POD type that only stores the data common to all
strips, such as start/end frames.
- The data that might be of a completely different nature between strips (e.g.
keyframe data vs modifier data) is now stored in arrays on the action itself.
- `Strip`s indicate their type with an enum, and specify their data with an
index into the array on the action that stores data for that type.
This approach requires a little more data juggling, but has the advantage of
making `Strip`s themselves super simple POD types, and also opening the door to
trivial strip instancing later on: instances are just strips that point at the
same data.
The intention is that the RNA API remains the same: from RNA's perspective there
is no data storage separate from the strips, and a strip's data is presented as
fields and methods directly on the strip itself. Different strip types will be
presented as different subtypes of `ActionStrip`, each with their own fields and
methods specific to their underlying data's type. However, this PR doesn't
implement that sub-typing, leaving it for a future PR. It does, however, put the
fields and methods of the one strip type we have so far directly on the strip,
which avoids changing the APIs we have so far.
This PR implements the bulk of this new approach, and everything should be
functional and working correctly. However, there are two TODO items left over
that will be implemented in forthcoming PRs:
- Type refinement in the RNA api. This PR actually removes the existing type
refinement code that was implemented in terms of the inheritance tree of the
actual C++ types, and this will need to be reimplemented in terms of the new
data model. The RNA API still works without the type refinement since there
are only keyframe strips right now, but it will be needed in preparation for
more strip types down the road.
- Strip data deletion. This PR only deletes data from the strip data arrays when
the whole action is deleted, and otherwise just accumulates strip data as more
and more strips are added, never removing the data when the corresponding
strips get removed. That's fine in the short term, especially since we only
support single strips right now. But it does need to be implemented in
preparation for proper layered actions.
Pull Request: https://projects.blender.org/blender/blender/pulls/126559
Code would try to use a random ID as a legacy curve one, without any
check on the actual ID type. When trying to open
`tests/data/io_tests/blend_big_endian/2.30/dolphin.blend` recently added
to our collection of regression tests, this ended up 'converting' a
shapekey into a legacy curve ID, leading to invalid memory access
detected by ASAN.
