The poll function was accidentally changed to return false when no
object is selected or the active object is not one of the special types
checked by the function. Reverted to return true in those cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/128110
Use the `animrig::legacy::channel_groups_all()` function to get action
groups in a way that's compatible with both legacy and layered Actions.
No functional changes for legacy Actions.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/128088
In `BKE_action.hh`, update the Action Group related functions, so that
either they are legacy-only or can handle layered Actions as well.
Legacy-only functions not only are documented as such, but also assert
that the given Action is a legacy one.
No functional changes for legacy Actions.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/128088
Add slotted/layered Action support to `get_active_actiongroup()` and
`set_active_action_group()`.
Note that there is still a bunch of code around that directly manipulates
the action group flags, instead of using these functions. That's for
another commit to address.
This commit also introduces the functions `action_treat_as_legacy()` and
`channel_groups_all(action)` utility functions in the `animrig::legacy`
namespace.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/128084
For most cases where the iteration index is needed, a For Each zone is the
better than using a Repeat zone. It's easier to use and more optimizable.
However, in some cases a Repeat zone is actually the right solution and the
index often useful in such cases too.
Pull Request: https://projects.blender.org/blender/blender/pulls/127521
Currently code to find symmetrical vertices is duplicated
a couple times-- in the expand operator and in the flood
fill API. This commit removes the symmetry processing from
the flood fill API, which arguably shouldn't need to know
about symmetry options in the first place.
Pull Request: https://projects.blender.org/blender/blender/pulls/127804
Color primvars/attributes were historically treated as a special case
for both import and export. This was mostly done to align with how
painting and viewport display works in Blender. Export would generally
ignore color attributes except when they were found on a Mesh's Point or
FaceCorner domains. And import went out of its way to map incoming color
primvars to the FaceCorner domain in more situations than necessary.
To facilitate better roundtripping in Blender<=>USD workflows, and to
reduce code duplication, this PR teaches the common attribute utilities
how to handle color types. The color attributes will now work on all
relevant Mesh and Curve domains.
There were tests in place for this already but they were set to verify
the inverse state, i.e. the technically broken state, until this could
be fixed.
There remains one special case: "displayColor" primvars and attributes.
The "displayColor" is a special primvar in USD and is the de-facto way
to set a simple viewport color in that ecosystem. It must also be a
color3f type. In order to not regress import, if a "displayColor"
primvar is found on the Face domain we will map it to FaceCorner instead
so it can be displayed in the viewport; which has been the case for the
past several releases. We can drop this special-case if/when Blender can
display Face colors through the Viewport Shading "Attribute" color type.
Additionally, Blender will export this, and only this, color attribute
as a color3f.
Note: As was the case prior to this PR, the following 2 discrepancies
still prevent "perfect" round-trips:
- USD does not have an equivalent to Blender's byte colors; they are
treated as float during IO
- Blender does not have an equivalent to USD's color3 types; they are
treated as color4 during IO
Pull Request: https://projects.blender.org/blender/blender/pulls/127784
This makes the input field much wider. I enabled this for most string sockets
except for a few where it is important to see the label even if the user has
inserted a string already (usually because there is more than one string input).
Pull Request: https://projects.blender.org/blender/blender/pulls/127992
This refactor changes many nodes to set socket availability in the node
declaration instead of using the more generic `bNodeType::updatefunc`.
This fixes issues where sockets that should be unavailable in evaluated data are
actually available. Also it moves us closer to a state where the generic update
function is not necessary anymore. The update function being so generic makes it
hard to integrate it well into the high level tree update code, because
"anything could happen" in that callback.
Pull Request: https://projects.blender.org/blender/blender/pulls/127845
This commit adds the Mask from Boundary operator, which creates or
otherwise modifies a mask based on the the mesh boundary or the face
set boundaries of the mesh.
Conceptually, it behaves similarly to the corresponding automasking
options and the existing Mask from Cavity operator. When applying this
setting, it either uses the global scene value, the brush specific
value, or the operator-defined values. As such, it is exposed in the
existing automasking menus and inside the main Mask menu in Sculpt mode.
Based on this [1] RCS request.
[1] https://blender.community/c/rightclickselect/DYKy/
Pull Request: https://projects.blender.org/blender/blender/pulls/127787
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.
