This implements bundles and closures which are described in more detail in this
blog post: https://code.blender.org/2024/11/geometry-nodes-workshop-october-2024/
tl;dr:
* Bundles are containers that allow storing multiple socket values in a single
value. Each value in the bundle is identified by a name. Bundles can be
nested.
* Closures are functions that are created with the Closure Zone and can be
evaluated with the Evaluate Closure node.
To use the patch, the `Bundle and Closure Nodes` experimental feature has to be
enabled. This is necessary, because these features are not fully done yet and
still need iterations to improve the workflow before they can be officially
released. These iterations are easier to do in `main` than in a separate branch
though. That's because this patch is quite large and somewhat prone to merge
conflicts. Also other work we want to do, depends on this.
This adds the following new nodes:
* Combine Bundle: can pack multiple values into one.
* Separate Bundle: extracts values from a bundle.
* Closure Zone: outputs a closure zone for use in the `Evaluate Closure` node.
* Evaluate Closure: evaluates the passed in closure.
Things that will be added soon after this lands:
* Fields in bundles and closures. The way this is done changes with #134811, so
I rather implement this once both are in `main`.
* UI features for keeping sockets in sync (right now there are warnings only).
One bigger issue is the limited support for lazyness. For example, all inputs of
a Combine Bundle node will be evaluated, even if they are not all needed. The
same is true for all captured values of a closure. This is a deeper limitation
that needs to be resolved at some point. This will likely be done after an
initial version of this patch is done.
Pull Request: https://projects.blender.org/blender/blender/pulls/128340
The current logic disables WITH_CYCLES_ONEAPI_BINARIES when ocloc is not
found, which is fine, but prevented building for other non-Intel SYCL
targets without (unnecessary) ocloc.
The fix here is to remove spir64_gen target when
WITH_CYCLES_ONEAPI_BINARIES is disabled, instead of forcing only spir64.
Found while investigating #136359.
Steps to reproduce:
- Switch 3D View in Layout workspace to Texture Nodes Editor
- Set the Texture Type selector to Line Style
- Press New
- Notice how no Texture tab appears in the Properties, even though there
is a texture user on the frestyle line set now.
Pull Request: https://projects.blender.org/blender/blender/pulls/136621
This allow to store the full object ID inside a `uint32`
buffer. This allows to get the per object data in deferred
passes and avoid to store object data inside the Gbuffer.
This data is only written if needed.
This had to modify the implementation of subpass input
for all backend to be able to bind layered texture.
This currently work because only the layer 0 is bound to the
framebuffer. This is fragile but I don't see a good builtin way
to fix it.
Rel #135935
#### Tasks
- [x] Replace light linking bits in Gbuffer
- [x] Replace Object ID in GBuffer for SSS
- [x] Conditional storage
- [x] Dummy storage if not needed
Pull Request: https://projects.blender.org/blender/blender/pulls/136428
In edit mode, positions of selected points is not shown in transform
side panel. Following existing logic, now introduced
`TransformMedian_GreasePencil`, `TransformMedian_Curves` to track the
median of selected points of grease pencil and Curves respectively.
Resolves#136332
Pull Request: https://projects.blender.org/blender/blender/pulls/136592
When the user filters channels by name, collapsed channel groups weren't getting
filtered properly.
For example, consider the following situation:
- You have a channel group "Transforms" with the F-Curve "X Location" under it.
- You use the name filtering feature with the string "Z".
The single F-Curve under the group will get filtered out by the string, and thus
should be hidden. That also means that the group, now with no visible f-curves,
should also no longer be displayed.
With this bug, if the channel was expanded then this filtering still proceeded
correctly, and both the f-curve and the group were hidden. However, if the group
was *collapsed* then the group would *not* get filtered out, which is incorrect.
The underlying cause is that an early-out "we found an un-filtered fcurve,
that's all the info we need with these flags!" clause in the f-curve filtering
code was happening too early, so it wasn't accounting for name-based filtering.
This PR fixes the issue by moving that early-out code to *after* the name-based
filtering so that it's properly accounted for.
Pull Request: https://projects.blender.org/blender/blender/pulls/136929
The issue was that the offset would offset by a different
amount depending on the scale property.
This is a regression from the legacy behavior,
and also harder to control in general.
The versioning code only touches FCurves that are not marked
as "legacy" because the legacy noise didn't have that issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/136502
The `Use Uniform Width` option did not work the intended way.
Like the comment and the manual says it should "enforce uniform
stroke width by averaging radius".
Instead (as far as I understand) it was simply checking if the stroke had
radii that were all within some margin from one another and then
returning the first radius if that was the case.
There were two other issues:
1. The widths were not computed correctly, multiplying the pixel size
instead of dividing it.
2. The epsilon to compare the radii was a bit too high (factoring in the
first issue, this actually never returned a value).
This now computes the widths in screen space and then returns the mean.
Pull Request: https://projects.blender.org/blender/blender/pulls/136903
Improve the number of images that are requested in the swapchain. For
mailbox presentation mode we select tripple buffering. For V-Sync
presentation mode we select double buffering.
In future we might want to make the presentation mode and swapchain
images dynamic based on the actual action that the user is performing.
When doing action that benefit from low latency (paint cursor) we should
select mailbox, otherwise we can use fifo to reduce CPU/GPU usage and
safe some energy usage along the way. See #136923 for design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/136922
Previously when an action was baked, the slot name was not retained.
This causes problems when switching between actions because the slot
will not automatically be assigned.
This is now fixed by ensuring that the name of the last assigned slot
is used to create the new slot.
Pull Request: https://projects.blender.org/blender/blender/pulls/136814
When file with legacy GP is opened in newer version, dopesheet
channel color is not transferred, they appear dark instead. To
fix this, copy color value from legacy GP layers in versioning code.
Pull Request: https://projects.blender.org/blender/blender/pulls/136876
Partial redrawing of the 3d viewport has not worked since the transition
to 2.8. Despite this, we still calculate the paint BVH bounds of the
affected area.
To avoid this wasted work and simplify the code, we remove the related
functions. Further work to enable partial redraws would not necessarily
be integrated in the same way. Additionally, a minor speedup of 1.05x
(1.00ms to 0.95ms) can be observed with this commit when performing
weight painting on a mesh with 2 million elements.
Similar to #136471
Pull Request: https://projects.blender.org/blender/blender/pulls/136912
When sculpting high-res meshes, the total number of nodes in the BVH
tree can get quite high and — especially when the brush radius is low —
comparable to the number of vertices influenced by the brush. Under
these conditions, algorithms that run on each node of the BVH,
especially if single-threaded, can become a bottleneck. This issue is
particularly prominent in multires, where the leaf limit is 2500.
The main culprit is `BKE_pbvh_redraw_BB`, which is used when flushing an
update to calculate the redraw bounds. Because partial drawing is
currently broken, and because a future reimplementation of partial
drawing is unlikely to adopt the existing approach, this PR removes the
partial drawing logic from `flush_update_step`.
This patch provides a speedup ranging from 1.25x to 1.45x, depending on
the brush size, when sculpting a small portion of a multires mesh with
roughly 8.1 million faces and 12.6 million vertices using the draw
brush.
Pull Request: https://projects.blender.org/blender/blender/pulls/136471
After creating a new scene in a separate window when performing UI
tests, the respective view layer for the window may not be updated
immediately in the event loop.
Previously, this was mitigated with a single `yield` statement that
would delay processing by a single tick. To fix this issue, this commit
adds the capability to yield for a specific `timedelta` and waits this
amount of time for the two affected tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/136012
* Change #define constant value to static constexpr
* Adds const where possible
* Uses reference instead of pointer where possible
* Uses `float3` instead of raw float array where possible
* Uses std::optional to indicate value that may be null
* Reduces scope of variables where possible
* Uses `std::array` instead of raw arrays where possible
* Combines assignment and declaration where possible
* Lengthens some names from single letters
Pull Request: https://projects.blender.org/blender/blender/pulls/135486
Changes only noticeable to pen users, this PR changes the status bar
information while pressing down on the corner zones but before moving
more than the threshold to start. Split-specific is not shown until
the threshold is met. Most mouse users are dead-still at this point,
but pen users have more movement which currently causes a status bar
change.
Pull Request: https://projects.blender.org/blender/blender/pulls/136900
Mistake in 4d7274b7f4.
The Previous code:
```
float(*deformedVerts)[3] = *deformcos;
float(*origVerts)[3] = static_cast<float(*)[3]>(MEM_dupallocN(deformedVerts));
```
Didn't create a copy of the positions for the `deformedVerts` variable.
It's meant to modify the input position array. It was probably done that way
since dealing with pointers to pointers in C was annoying. With `Array`,
it's not annoying anymore, we can just use that directly.
When the evaluated mesh doesn't have an edit mesh that corresponds
to the original edit mesh, don't use evaluated deformed positions, just
use the mesh's original positions instead.
It's better for performance to use a single thread pool for all areas of
Blender, and this gets us closer to that.
Bullet, Quadriflow, Mantaflow and Ceres still contain OpenMP code, but it
was already disabled.
On macOS, our OpenMP libraries are no longer compatible with the latest
Xcode 16.3. By removing OpenMP we no longer have to solve that problem.
OpenMP was disabled for bpy module builds on Windows ARM64, which also no
longer needs to be solved.
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
Only the parallel sparse matrix code was updated. This is used by e.g.
LSCM and ABF unwrap, and performance seems about the same or better.
Parallel GEMM (dense matrix-matrix multiplication) is used by libmv,
for example in libmv_keyframe_selection_test for a 54 x 54 matrix.
However it appears to harm performance, removing parallelization makes
that test run 5x faster on a Apple M3 Max.
There has been no new Eigen release since 2021, however there is active
development in master and it includes support for a C++ thread pool for
GEMM. So we could upgrade, but the algorithm remains the same and
looking at the implementation it just does not seem designed for modern
many core CPUs. Unless the matrix is much larger, there's too much thread
synchronization overhead. So it does not seem useful to enable that
thread pool for us.
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
To make adding a dependeny on TBB easier.
Additional changes:
* Using LIB for libmv tests, as it now brings in includes
* Removing Eigen header listing in iTaSC
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
GPU_DEPTH_NONE leads to issues with Intel GPU drivers on Windows
where camera gizmos cannot be shifted. glGetQueryObjectuiv for
GL_SAMPLES_PASSED seems to return zero in all cases.
This might be due to undefined behavior of OpenGL when the depth
test is disabled and rendering to a depth render target-only
framebuffer. Using GPU_DEPTH_ALWAYS fixes the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/136607
Previously pressing `c` to cut through mesh will only update knife cuts
when mouse is moved again, this means if you press `c` at the end of
mouse stroke, it will not update cuts and you end up still only cutting
front faces. This fix makes it that the toggle refreshes knife cuts
immediately.
Pull Request: https://projects.blender.org/blender/blender/pulls/136870
`win->ime_data` could be non-null when it's read from a file, and
subsequent dependence of this value would crash on interface handlers.
Now always clear it when ghost window is ensured after reading the file.
The actual reset is put in `wm_window_ensure_eventstate`, since it's
also conceptually a part of "event state".
Pull Request: https://projects.blender.org/blender/blender/pulls/136833
Under some circumstances the `value_task` run by node tree updates
needs access to a node group topology cache. Unlike the `usage_task`
it was not ensuring the cache for the node group, so a stale cache
could be used (triggers assert).
Pull Request: https://projects.blender.org/blender/blender/pulls/136878
This was an issue previously not noticed. There were two bugs:
- When an out of range index was somehow detected, line art discards the
entire stroke after the point, which causes remaining point positions
to be invalid. In fact the index should never go out of range unless
total points in the scene exceeds `size_t`.
- Line art point index is global, not local to objects, previously the
"object starting index" was not subtracted from the final point index
when transferring weights, this will lead to incorrect weight being
transferred/discarded.
Now both problems have been properly taken care of.
Pull Request: https://projects.blender.org/blender/blender/pulls/136869
