The collada export code was directly using `action->curves` in its
export code, which doesn't work with slotted actions. This commit
updates that code to use wrapper functions that provide access to the
correct fcurves regardless of whether the action is slotted or not.
Note that the import code has not yet been updated, and is left for
a future PR.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/128061
It is too easy to accidentally enable skipping the simulation while moving the
node around without noticing. Now it is necessary to pass in a boolean value
from another node to modify the skip value. Existing files that had this
checkbox checked are updated by versioning code.
This implements #127506.
Pull Request: https://projects.blender.org/blender/blender/pulls/127988
Convert the Grease Pencil legacy converter code to the new layered
Action API.
Unfortunately this cannot just work on legacy Actions (and then rely on
the versioning to layered Actions we'll land soon), as the GP conversion
runs as the final step of the versioning process. This cannot be helped,
as the usual versioning is not allowed to create new IDs and this does.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/128064
Supporting selection operators and overlays in sculpt mode is necessary
to support masking operations.
This enables selection drawing in the overlay in sculpt mode,
and ensures all the necessary operators (pick, lasso, circle, box)
handle the differences in modes correctly.
The selection code so far was expecting object mode, so the `vc->obedit`
object was used without further checks. Now the selection code can be
called outside of edit mode, in which case the `vc->obact` object must
be used instead. Similarly edit mode and sculpt mode have separate
`selectmode` flags, so the correct mode property must be used from the
tool settings depending on the object mode. These changes require some
refactoring of unrelated selection code.
Pull Request: https://projects.blender.org/blender/blender/pulls/128040
This is not an officially supported platform, but it was working before
so might as well keep it up to date.
* Tweak logic for various BLENDER_PLATFORM_ARM checks
* Use linux_arm64 name for folders, matching Windows and macOS
* CUDA is enabled, SYCL and HIP are not
* Tested to work on Rocky Linux 8
The Action Constraint would only allow actions that were once assigned
to objects, i.e. with `action->idroot == ID_OB`. This did not take into
account the equally valid `0` case, which is what indicates that this
Action has never been assigned to anything yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/128072
Order of operations was wrong: First, the new tool has to be activated
(or at least identified) before we can tell which tool (or more precise,
which brush type) to update the brush binding for.
This change switches Cycles to an opensource HIP-RT library which
implements hardware ray-tracing. This library is now used on
both Windows and Linux. While there should be no noticeable changes
on Windows, on Linux this adds support for hardware ray-tracing on
AMD GPUs.
The majority of the change is typical platform code to add new
library to the dependency builder, and a change in the way how
ahead-of-time (AoT) kernels are compiled. There are changes in
Cycles itself, but they are rather straightforward: some APIs
changed in the opensource version of the library.
There are a couple of extra files which are needed for this to
work: hiprt02003_6.1_amd.hipfb and oro_compiled_kernels.hipfb.
There are some assumptions in the HIP-RT library about how they
are available. Currently they follow the same rule as AoT
kernels for oneAPI:
- On Windows they are next to blender.exe
- On Linux they are in the lib/ folder
Performance comparison on Ubuntu 22.04.5:
```
GPU: AMD Radeon PRO W7800
Driver: amdgpu-install_6.1.60103-1_all.deb
main hip-rt
attic 0.1414s 0.0932s
barbershop_interior 0.1563s 0.1258s
bistro 0.2134s 0.1597s
bmw27 0.0119s 0.0099s
classroom 0.1006s 0.0803s
fishy_cat 0.0248s 0.0178s
junkshop 0.0916s 0.0713s
koro 0.0589s 0.0720s
monster 0.0435s 0.0385s
pabellon 0.0543s 0.0391s
sponza 0.0223s 0.0180s
spring 0.1026s 1.5145s
victor 0.1901s 0.1239s
wdas_cloud 0.1153s 0.1125s
```
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Co-authored-by: Ray Molenkamp <github@lazydodo.com>
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/121050
Deleting the last key on an F-Curve also deletes that F-Curve, and if
that happened to be the last F-Curve of the Action, the entire Action is
deleted (only for legacy Actions).
Tagging the depsgraph is now only done when the Action itself survives.
Pull Request: https://projects.blender.org/blender/blender/pulls/128067
Rename `action_foreach_fcurve` to `foreach_fcurve_in_action_slot`. This
matches the functionality better, and opens up the floor for an iterator
that actually does loop over all F-Curves in an Action.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/128065
When building proxies at lower than 100% resolution, the video frame
downscaling step was single threaded, as found via #127956.
Make it use the same threaded sws_scale machinery that the usual video
decoding/encoding uses. Video encoding/decoding was only using it for
RGB<->YUV conversions, so source and destination sizes were always matching;
here it needs to have different source and destination sizes though.
Time taken to rebuild 50% proxy for a 4K resolution 1440 frames (1 minute)
long video file, on Ryzen 5950X (Win10/VS2022):
- Blender 4.2: 20.1 sec, CPU usage 30-40%.
- Blender 4.3 main: 13.1 sec (ffmpeg build has been fixed to use SIMD),
CPU usage still 30-40% though.
- This PR: 8.3 sec, CPU usage ~95%.
Pull Request: https://projects.blender.org/blender/blender/pulls/128054
Mainly remove usages of BLI memarena and bitmap, and use owninh C++
containers instead. And replace pointers by references in some of the
internal functions parameters.
Pull Request: https://projects.blender.org/blender/blender/pulls/128041
This does some changes to the ed::greasepencil::ensure_active_keyframe` function.
* The context was only needed to get the scene, pass the scene directly
* Don't use the active layer by default but pass a reference to a
layer instead. This makes it also possible to create keyframes
on multiple layers using a loop.
This adds a new type of zone to Geometry Nodes that allows executing some nodes
for each element in a geometry.
## Features
* The `Selection` input allows iterating over a subset of elements on the set
domain.
* Fields passed into the input node are available as single values inside of the
zone.
* The input geometry can be split up into separate (completely independent)
geometries for each element (on all domains except face corner).
* New attributes can be created on the input geometry by outputting a single
value from each iteration.
* New geometries can be generated in each iteration.
* All of these geometries are joined to form the final output.
* Attributes from the input geometry are propagated to the output
geometries.
## Evaluation
The evaluation strategy is similar to the one used for repeat zones. Namely, it
dynamically builds a `lazy_function::Graph` once it knows how many iterations
are necessary. It contains a separate node for each iteration. The inputs for
each iteration are hardcoded into the graph. The outputs of each iteration a
passed to a separate lazy-function that reduces all the values down to the final
outputs. This final output can have a huge number of inputs and that is not
ideal for multi-threading yet, but that can still be improved in the future.
## Performance
There is a non-neglilible amount of overhead for each iteration. The overhead is
way larger than the per-element overhead when just doing field evaluation.
Therefore, normal field evaluation should be preferred when possible. That can
partially still be optimized if there is only some number crunching going on in
the zone but that optimization is not implemented yet.
However, processing many small geometries (e.g. each hair of a character
separately) will likely **always be slower** than working on fewer larger
geoemtries. The additional flexibility you get by processing each element
separately comes at the cost that Blender can't optimize the operation as well.
For node groups that need to handle lots of geometry elements, we recommend
trying to design the node setup so that iteration over tiny sub-geometries is
not required.
An opposite point is true as well though. It can be faster to process more
medium sized geometries in parallel than fewer very large geometries because of
more multi-threading opportunities. The exact threshold between tiny, medium and
large geometries depends on a lot of factors though.
Overall, this initial version of the new zone does not implement all
optimization opportunities yet, but the points mentioned above will still hold
true later.
Pull Request: https://projects.blender.org/blender/blender/pulls/127331
SEQ_render_is_muted is a fairly expensive, since it has to walk
a linked list of channels to find the one with the given index.
During timeline drawing, this was called for each strip multiple times.
Instead, get that value once per visible strip.
Viewing Sprite Fright Edit v135 whole timeline on Ryzen 5950X
(Win10/VS2022): timeline repaint 7.7ms -> 7.5ms
Pull Request: https://projects.blender.org/blender/blender/pulls/128057
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
