This affects the edit-mode copy/paste operators as well as the sculpt
mode _Clone_ tool. These copy and paste to/from the clipboard, but were
not applying the layer transform in the process. All curves were stored
in their respective local layer space. Since everything gets merged
these transforms get lost when storing to the clipboard.
Pasting curves from the clipboard was also not applying the target layer
transform. Also the clipboard content was getting pasted into every
editable drawing.
Now clipboard curves are always stored in world space. Pasting only
happens on the active layer, and the active layer inverse transform is
applied so visual transform of curves shouldn't change through copy and
paste.
Pull Request: https://projects.blender.org/blender/blender/pulls/127917
When having two objects selected that use the same action,
the Graph Editor would effectively show the same FCurve on 2 channels.
When building the `TransData` array the code would iterate
all channels though not checking for duplicate FCurves.
As a result when transforming keys, the `TransData`
array would contain the same entry twice.
That would break the logic introduced in c6c7d3d8c4 which
builds a Map of the `float *` that needs
updating and the index of that data in the array.
Only the first index of the `TransData` array would be updated since the
Map can only contain a certain value once.
The fix is to ensure that entries in the `TransData` array are unique.
This is done in the construction of the array.
Pull Request: https://projects.blender.org/blender/blender/pulls/127911
The Symmetrize Action operator also updates Action Constraints, and even
alters its Action to have identical (but mirrored) F-Curves for the bones.
This now uses the new API for layered Actions, (hopefully) correctly
storing the F-Curves and Action Groups.
I suspect there is still a bug in there, but that's now equally there for
legacy & layered Actions.
Pull Request: https://projects.blender.org/blender/blender/pulls/128039
`BKE_fcurves_filter()` was only used by the Symmetrize Armature
operator, when dealing with Action Constraints on the bones.
`BKE_fcurves_filter()` is now removed, and has been replaced by the new
`animrig::fcurve_find_in_action_slot_filtered()`. It's functionally
pretty much the same, except that it returns a `Vector<FCurve *>`
instead of manipulating a `ListBase` parameter.
Because it's now implemented using an iterator in
`ANIM_action_iterators.hh` it didn't feel right to keep the function in
BKE.
No functional changes.
This adds a gradient tool allowing the user to specify a gradient by dragging from a start to a end point.
This behaves the same as most gradient tool in other softwares.
Pull Request: https://projects.blender.org/blender/blender/pulls/120121
The issue was that the `grease_pencil_foreach_id` did not walk
the parent object pointers which meant they were pointing
to garbage memory.
The fix makes sure to walk all the parent pointers.
Fix the code that decides whether to create a new F-Curve in a legacy or
layered style. The old code went for layered if:
- The experimental feature is enabled AND the Action is already layered.
The new code goes for layered if:
- The experimental feature is enabled AND the Action is empty, OR
- The Action is already layered.
Pull Request: https://projects.blender.org/blender/blender/pulls/128036
Replace those calls to `BKE_fcurve_find()` that are searching in the
curves of an Action with their corresponding call in `animrig`:
- `animrig::fcurve_find_in_action()` when it should really search
through the entire Action,
- `animrig::fcurve_find_in_action_slot()` when only the F-Curves for a
specific slot should be searched, or
- `animrig::fcurve_find_in_assigned_slot()` same as above, searching
through the action slot that is assigned to the given ADT.
This also makes `animrig::fcurve_find_in_action()` compatible with both
layered and legacy Actions.
This makes the naming a bit closer to the `BKE_fcurve_find()` function,
and opens op the naming for two upcoming functions
`fcurve_find_in_action_slot` and `fcurve_find_in_assigned_slot`.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/128036
GPU resources created during Light probe bake job were added to discard pool, but the pool itself was never notified by worker thread to release resources.
Bake job creates dedicated `GPUContext` for its needs and later deletes it within the same thread.
Pull Request: https://projects.blender.org/blender/blender/pulls/127977
Remove the declaration of `blender::animrig::legacy::action_has_fcurves()`.
Its implementation was never committed to `main`, and the declaration also
shouldn't have.
No functional changes.
Removes two levels of indirection when updating descriptor sets.
These are the easy ones to remove. Others will be removed in
a future PR.
This is part of reworking of how descriptor sets are used.
This PR Mostly reduces complexity.
Pull Request: https://projects.blender.org/blender/blender/pulls/127915
Because we're moving to layered actions, which don't store their
fcurves in a list base, we need to update the places that assume the old
listbase-based structure.
This commit addresses the low-hanging fruit where code was previously
using the `LISTBASE_FOREACH` macro on a listbase of fcurves and it was
fairly obvious how to correctly update the code with minimal changes.
Other cases that either weren't immediately obvious or required
non-trivial code changes (or both) have been left for future PRs.
Additionally, uses of the list base that didn't use `LISTBASE_FOREACH`
were not investigated as part of this PR, whether trivial to update or
not.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/127920
Partially revert [0] which replaced BMBVHTree with SnapObjectContext.
While SnapObjectContext is a comprehensive method of performing
ray-casts, the purpose of edge-slide visibility checks is mainly to
exclude back-facing vertices.
Using SnapObjectContext has some down-sides that include iterating
over all dupli-instances for every vertex, details in code-comments.
Resolve be restoring simpler self-occlusion check.
[0]: 2d50a41d77
Ref !128016
lib override and add asset operation appears in nested context menu.
They are incorrectly exposed when right clicked on an operator in
context menu. So don't expose then when opening nested context menu on
operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/126927
- Use `lookup_or_add_for_write_only_span` in more places
- Use `copy_from` when reading in positions for the few readers where
this wasn't already being done
- Remove manual memory management when processing corner normals
Pull Request: https://projects.blender.org/blender/blender/pulls/128043
Sculpt mode in Grease Pencil should not use the origin point of
`DrawingPlacement` and only apply the plane projection to relative
offsets.
A new variant of the `foreach_editable_drawing` function is introduced
that provides a `DeltaProjectionFunc` instead of `DrawingPlacement`.
This projection callback takes a layer-space position and a screen-space
delta and returns a layer-space position with the constrained delta
applied. The projection function is based on the tools settings'
"lock axis", like `DrawingPlacement`, but ignores the origin point.
Exception is the smoothing tool, which does not restrict movement along
the lock axis. This can be implemented if desired, but for a
non-directional tool it seems the lock axis isn't very meaningful.
Pull Request: https://projects.blender.org/blender/blender/pulls/128022
Caused by c2dd238ba1.
Moving the BVH (and sadly returning it by value currently)
causes issues in debug builds because the `prim_indices_`
references in the nodes becomes invalid. The simplest fix
is to just not use an inline buffer so the array's data pointer
doesn't change when `Tree` moves.
Caused by incorrectly using mutable `ListBase` iterator, which caused
adding same strip to meta twice. This caused `next` and `prev` fields
to be set to same value resulting in infinite loop in next iterator.
Since multiple strips can be removed from list in one iteration, collect
these into `VectorSet` and move them in separate for loop.
Also do cache invalidation while strips are in original `seqbase`,
otherwise it can skip invalidation of strips downstream.
Pull Request: https://projects.blender.org/blender/blender/pulls/127951
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...
Remove the unnecessary "enabled/disabled" toggle in the struct.
That's unnecessary because they're practically always recalculated
anyway. Also remove outdated comments and move documentation
to the header.
Use the API added in d15681a459. Also use multithreading
for the position restore and avoid processing the entire mesh when only
parts of it were changed.
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
Fix two bugs by replacing direct assignment to `adt->action` with a call
to `animrig::assign_action()`:
- If a related Action was found, its user count was not incremented.
- If a new Action is created, its `idroot` was not properly set.
Pull Request: https://projects.blender.org/blender/blender/pulls/128030
The `animrig::assign_action(action, id)` function now takes a `bAction`
pointer (instead of its C++ wrapper `animrig::Action`). This makes it
easier to call from code that just deals with the DNA/C struct.
Also an override was added that takes an `OwnedAnimData` struct instead
of just the ID. This saves the lookup of the AnimData, to be used in cases
where the caller already has it.
Pull Request: https://projects.blender.org/blender/blender/pulls/128030
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
Finding which F-Curve (if any) drives the blend factor or volume of a strip is
fairly expensive (it has to search all the curves to find the one matching the
name). Speed that up by:
- Doing the f-curve lookups in parallel for all the visible strips,
- The found curve is stored in StripDrawContext, so this also avoids finding
the "volume" curve twice for the same strip (once for waveform, once for
fcurve overlay).
Viewing Sprite Fright Edit v135 whole timeline on Ryzen 5950X (Win10/VS2022):
timeline repaint 18.5ms -> 7.7ms
Pull Request: https://projects.blender.org/blender/blender/pulls/128015
De-interleaved vertex buffers offsets the attribute in the buffer to
the de-interleaved position. The vertex attribute offset is limited by a
constrained and would raise an error when the buffers just a bit larger.
*VUID-VkVertexInputAttributeDescription-offset-00622*: offset must
be less than or equal to `VkPhysicalDeviceLimits::maxVertexInputAttributeOffset`
This PR fixes this by offsetting the buffer in stead of the attribute.
Offsetting buffers is limited by the amount of memory.
Pull Request: https://projects.blender.org/blender/blender/pulls/128031
Provide building block support for integer operations.
Manipulation of integer based data should not be limited to using float math nodes.
Using float math comes with accuracy issues for larger integers and requires unnecessary
type conversions.
The node also adds some integer specific operations like GCM and LCD.
Pull Request: https://projects.blender.org/blender/blender/pulls/110735
The reroute node used to be a bit special in the sense that its data type was
only stored in the sockets. However, typically, the ground truth data should be
stored in the node storage and then the socket types are derived from that.
For users, there should not be a noticable difference. However, from Python
it's not possible to modify the socket type directly on the socket anymore.
This is forbidden for other built-in nodes already too.
Instead, one can use the new `reroute_node.socket_idname` property to change
the type of a node. This internally also recreates the sockets with the correct
type.
Pull Request: https://projects.blender.org/blender/blender/pulls/121146
When a linked/overridden collection is child of a local collection,
object/collection level visibility toogles can be edited of library data
if shift clicked on local collection's properties. To fix this, skip further
recursive calls when the property is not editable.
Pull Request: https://projects.blender.org/blender/blender/pulls/128011
