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
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
