Don't template size for matrix is_negative. These are causing random
build failures on the Windows buildbot.
Note that these already have the assumption of 3D coordinates baked
in. For 2D or 4D coordinates the implementation would have to be
different. So templating these for arbitrary dimensions does not
make much sense.
Pull Request: https://projects.blender.org/blender/blender/pulls/134137
Previously, there was a `StringRef.copy` method which would copy the string into
the given buffer. However, it was not defined for the case when the buffer was
too small. It moved the responsibility of making sure the buffer is large enough
to the caller.
Unfortunately, in practice that easily hides bugs in builds without asserts
which don't come up in testing much. Now, the method is replaced with
`StringRef.copy_utf8_truncated` which has much more well defined semantics and
also makes sure that the string remains valid utf-8.
This also renames `unsafe_copy` to `copy_unsafe` to make the naming more similar
to `copy_utf8_truncated`.
Pull Request: https://projects.blender.org/blender/blender/pulls/133677
Since one user-defined conversion operator is allowed during implicit conversion,
and after this conversion here is a constructor which can accept result
of conversion, there was a backdoor for a vector types to up-cast their
dimensions via cast to pointer type of a component of a vector. Since it was
implicit and non-intentional it led to buffer overflows.
Pull Request: https://projects.blender.org/blender/blender/pulls/132927
The core issue was that the geometry batch cache (e.g. `MeshBatchCache` or
`PointCloudBatchCache`) was dependent on the object. This is problematic when
the the same geometry is used with multiple different objects because the cache
can't be consistent with all of them.
Fortunately, the only thing that was retrieved from the object was the number of
material slots, so if that can be avoided we should be fine. We can't just use
the number of material slots stored on the geometry because that may have no
material slots but still has material indices which are overridden on the object
level.
The solution is to take make the number of materials for a geometry only
dependent on the actual `material_index` attribute and not on the number of
available slots. More specifically, we find the maximal referenced material
index and handle that many materials. This number does not depend on how many
material slots there are on the object, but it still allows the object to
override materials slots that the mesh references.
A downside is that the maximum material index has to be computed which often
requires an iteration over the mesh. Fortunately, we can cache that quite easily
and the computation can be done in parallel. Also we are probably able to
eagerly update the material index in many cases when it's set instead of
computing it lazily. That is not implemented in this patch though.
The largest part of the patch is making the maximal material index easily
available on all the geometry types. Besides that, the material API is slightly
replaced and the drawing code now makes use of the updated API.
Pull Request: https://projects.blender.org/blender/blender/pulls/133498
Before, it was only possible to apply modifiers through a multires modifier if
they were deform-only. The Geometry Nodes modifier is of course not deform-only.
However, often one can build a node setup, that only deforms and does nothing
else.
To make it possible to apply the Geometry Nodes modifier in such cases the
following things had to be done:
* Update `BKE_modifier_deform_verts` to work with modifiers that implement
`modify_geometry_set` instead of `deform_verts`.
* Add error handling for the case when `modify_geometry_set` does more than just
deformation.
* Allow the Geometry Nodes modifier to be applied through a multi-res modifier.
Two new utility types (`ArrayState` and `MeshTopologyState`) have been
introduced to allow for efficient and accurate checking whether the topology has
been modified. In common cases, they can detect that the topology has not been
changed in constant time, but they fall back to linear time checking if it's not
immediately obvious that the topology has not been changed.
This works with the example files from #98559 and #97603.
Pull Request: https://projects.blender.org/blender/blender/pulls/131904
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
