This can be useful when going from a selection of curves to the corresponding
selection of points.
The simple implementation given here should work quite well in the majority of
cases. There is still optimization potential for some cases involving masks with
many gaps. The implementation is also single threaded for now. Using
multi-threading is possible, but should ideally be done in some way to still
lets us exploit the fact that the index ranges are already in sorted order.
Pull Request: https://projects.blender.org/blender/blender/pulls/133323
This patch automatically grays out input values which can't affect the output
currently. It works with inputs of group nodes, geometry nodes modifiers and
node tools.
To achieve this, it analyses the node tree and partially evaluates it to figure
out which group inputs are currently not linked to an output or are disabled by e.g.
some switch node.
Original proposal: https://devtalk.blender.org/t/dynamic-socket-visibility/31874
Related info in blog post:
https://code.blender.org/2023/11/geometry-nodes-workshop-november-2023/#dynamic-socket-visibility
Follow up task for designing a UI that allows hiding sockets: #132706
Limitations:
* The inferencing does not update correctly when a socket starts being
animated/driven. I haven't found a good way to invalidate the cache in a good
way reliably yet. It's only a very short term problem though. It fixes itself
after the next modification of the node tree and is only noticeable when
animating some specific sockets such as the switch node condition.
* Whether a socket is grayed out is not exposed in the Python API yet. That will
be done separately.
* Only a partial evaluation is done to determine if an input affects an output.
There should be no cases where a socket is found to be unused when it can actually
affect the output. However, there can be cases where a socket is inferenced to be used
even if it is not due to some complex condition. Depending on the exact circumstances,
this can either be improved or the condition in the node tree should be simplified.
Pull Request: https://projects.blender.org/blender/blender/pulls/132219
The MSVC 2022 optimizer generates bad code for perlin_fractal_distorted
when perlin_fbm gets inlined leading to incorrect results and failing
tests that rely on perlin noise. For now just disable inlining for this
function for msvc2022 until we can get the compiler fixed.
This fixes the following failing tests on MSVC 2022:
- geo_node_curves_deform_curves_on_surface
- geo_node_geometry_delete_geometry_propogate_corner_attribute
- geo_node_utilities_field_on_domain_demo
Pull Request: https://projects.blender.org/blender/blender/pulls/133130
ID names of images that included slashes would attempt to write
save the image in a sub-directory based on those slashes.
Also add notes to clarify the intended use of "safe" path functions.
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
Before, it was only possible to clear the entire cache at once or to rely on
automatic clearing when it gets full. This patch adds the ability to remove
cached data based on a predicate function.
This is useful for #124369 for partially invalidating the cache for some files.
Pull Request: https://projects.blender.org/blender/blender/pulls/132605
Decimate used `is_quad_convex_v3` to check if faces should be converted
to quads, adjust the epsilon since small faces were being skipped.
Ref: !132342
Regression in [0] which re-introduced #2931.
Accessing environment variables must always null check the result.
Resolve by checking the result as well as replacing $HOME
access with a function that falls back to `passwd::pw_dir`.
Also add code-comments to to clarify the current behavior.
[0]: b308b360eb
This adds a new `Map.lookup_try` method that returns a `std::optional<Value>`
for a given key. If the key is not in the map, `std::nullopt` is returned. If it
is in the map, then a copy of the value is returned. Note that the copy is
necessary because `std::optional` can't contain reference types.
This method helps a lot in #132219 to reduce boilerplate.
Pull Request: https://projects.blender.org/blender/blender/pulls/132278
This optimizes the move-constructor for `blender::Vector` when all of the
following are true:
* The source and destination vector have exactly the same type.
* The stored type is trivial.
* The inline buffer is `<= 32` bytes large (this value is a heuristic that could
be changed).
The basic idea of the optimization is that under these circumstances one can
just copy the entire inline-buffer over instead of only copying it partially
based on the vector size. While that can mean that more bytes have to be copied,
the machine code that does the copying can be more efficient due to less
branching and the hardcoded size.
The performance impact is quite measurable. Note that the speedup depends on how
many elements are in vector and thus how many elements of the inline buffer are
used. The following table shows the move construction performance of a
`Vector<void *, 4>`. Starting at 5 elements, the performance doesn't change much
anymore, because the inline buffer is just ignored.
| Elements | Old | New |
|----------|------|------|
| 0 | 20.3 | 14.6 |
| 1 | 22.7 | 21.5 |
| 2 | 36.4 | 21.6 |
| 3 | 36.4 | 21.5 |
| 4 | 36.5 | 21.6 |
| 5 | 21.4 | 21.1 |
| 6 | 21.3 | 21.1 |
| 7 | 21.4 | 21.1 |
| 8 | 21.5 | 21.0 |
| 9 | 21.4 | 20.9 |
| 10 | 21.3 | 20.9 |
The binary size stays effectively unchanged (< 2kb change).
Pull Request: https://projects.blender.org/blender/blender/pulls/131841
Caused by 024d7d12e2.
I forgot that the BVH cache value isn't reset to default if it isn't
shared, which can happen after remeshing in some cases. To fix this,
switch to unique_ptr which handles ownership properly on assignment,
removing this class of bug from this code.
Pull Request: https://projects.blender.org/blender/blender/pulls/132040
Previously, calling `clear()` on `Map`, `Set` or `VectorSet` would remove all
elements but did not free the already allocated capacity. This is fine in most
cases, but has very bad and non-obvious worst-case behavior as can be seen in
#131793. The issue is that having a huge hash table with only very few elements
is inefficient when having to iterate over it (e.g. when clearing).
There used to be a `clear_and_shrink()` method to avoid this worst-case
behavior. However, it's not obvious that this should be used to improve
performance.
This patch changes the behavior of `clear` to what `clear_and_shrink` did before
to avoid accidentally running in worst-case behavior. The old behavior is still
available with the name `clear_and_keep_capacity`. This is more efficient if
it's known that the hash-table is filled with approximately the same number of
elements or more again.
The main annoying aspect from an API perspective is that for `Vector`, the
default behavior of `clear` is and should stay to not free the memory. `Vector`
does not have the same worst-case behavior when there is a lot of unused
capacity (besides taking up memory), because the extra memory is never looked
at. `std::vector::clear` also does not free the memory, so that's the expected
behavior. While this patch introduces an inconsistency between `Vector` and
`Map/Set/VectorSet` with regards to freeing memory, it makes them more
consistent in that `clear` is the better default when reusing the data-structure
repeatedly.
I went over existing uses of `clear` to see if any of them should be changed to
`clear_and_keep_capacity`. None of them seemed to really benefit from that or
showed that it was impossible to get into the worst-case scenario. Therefore,
this patch slightly changes the behavior of these calls (only performance wise,
semantics are exactly the same).
Pull Request: https://projects.blender.org/blender/blender/pulls/131852
`OtherInlineBufferCapacity <= InlineBufferCapacity` implies
`size <= InlineBufferCapacity` and can be done at compile time.
So if that is true already (as it commonly is), the `else` branch
is not necessary. This can improve performance in theory, although
I couldn't measure that in practice.
Additionally, this change also reduces the binary size (because of the
omitted else branch). Since this code is inlined fairly often, the impact
is measurable: the binary size is reduced by 50kb.
This enables moving elements form one vector to another.
Usually this is being doing by extending a vector with the content
from the secondary vector and then clearing the secondary vector.
However sometimes this being performed to transfer ownership of managed elements,
if elements are copied from the secondary vector, but not cleared, this could
lead to 2 vectors to share ownership of objects.
Pull Request: https://projects.blender.org/blender/blender/pulls/131560
In Blender 4.2 in Grease Pencil draw mode it was possible to
erase strokes using box and lasso gestures.
Under the hood, these were just using the selection operators
that had special deletion handling if the object was in draw mode.
Rather than hacking this into the selection operations, this adds
two new operators:
* `grease_pencil.erase_lasso`
* `grease_pencil.erase_box`
When using one of the erase operations with auto-key, the previous
keyframe will be duplicated to the current frame (for the drawings
that are affected by the eraser).
They are mapped to the same shortcuts than the selection
operators in Blender 4.2.
* Lasso erase: `Ctrl`+`Alt`+`RMB`.
* Box erase: `B`.
This is part of #130518.
Pull Request: https://projects.blender.org/blender/blender/pulls/131504
This patch adds an option to use the new perlin noise as a noise function for the FCurve modifier.
That fixes the issue of the old noise function which could produce values outside the -0.5/0.5 range (For a strength of 1).
The old way is still preserved and will be automatically used for old files.
Because of the different noise function, I've added two more parameters to the noise modifier.
The default values for those parameters are chosen to be as close to the original noise modifier as possible.
However the match is not 1:1
## Depth
With the new noise, the parameters for "Lacunarity" and "Roughness" are available to the user.
By default they are set in such a way that changing the "Depth" results in a similar noise pattern.
## Offset and Scale
The offset and scale parameters now behave differently. Before they would also shift the phase in some way, now all they do is shift or scale the noise.
## Amplitude
The biggest difference is in the amplitude of the noise.
Overall the amplitude is a lot smaller in general than with the legacy noise, but it does fix the issue of the amplitude reaching outside the -0.5/0.5 range.
By shifting the phase I was able to find points where the amplitude reaches 0.5 but never above that.
Pull Request: https://projects.blender.org/blender/blender/pulls/129535
These functions showed up in a profile of a geometry nodes setup
using BVH sampling. They are so simple that function call overhead
is likely to be significant, and giving the compiler a view of what they
do is also likely to be helpful.
The BLI bicubic interpolation function with border boundary is wrong
around edges. It returns zero, where interpolated values should exist.
This is due to a wrong early exit condition, where only a 2x2 window is
assumed instead of the 4x4 window considered by bicubic interpolation.
To fix this, assume a 2 pixel region in the early exit condition for
both directions.
Pull Request: https://projects.blender.org/blender/blender/pulls/131320
The BLI wrapmode variant of nearest interpolation for border boundary is
wrong for coordinates between [-1, 0]. That's because the negative
comparison in wrap_coord is done on the integer rounded coordinates,
which will be zero in this case, so the condition will not fail. To fix
this, do the comparison on the original coordinates instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/131306
This applies the fix from 98334b8f7d to the c++ implementation.
Two notes:
* We need to work towards unifying these implementations which would have avoided this bug.
* In the C++ implementation, one can't use `math::dot` and `math::normalize` for quaternions
where this function is implemented, because of include dependency order.
Both these things should be resolved, but right now correctness has priority for me.
Pull Request: https://projects.blender.org/blender/blender/pulls/131296
