Add a per node type callback for creating node add search operations,
similar to the way link drag search is implemented (11be151d58).
Currently the searchable strings have to be separate items in the list.
In a separate step, we can look into adding invisible searchable text
to search items if that's still necessary.
Resolves#102118
Pull Request #104794
This reverts commit 19222627c6.
Something went wrong here, seems like this commit merged the main branch
into the release branch, which should never be done.
This reverts commit 68181c2560.
I merged 3.6 into 3.5 by mistake. Basically I had a PR against main,
then changed it in the last minute to be against 3.5 via the
web-interface unaware that I shouldn't do it without updating the
patch.
Original Pull Request: #104889
Note that the node group has its sockets names
translated, while the built-in nodes don't.
So we need to use data_ for the built-in nodes names,
and the sockets of the created node groups.
Pull Request #104889
When the attribute doesn't exist, the node should give the default
of 12, as defined by the accessor method for `bke::CurvesGeometry`.
Pull Request #104674
Curve type counts are updated eagerly but it was missing in this
node leading to a crash further down the line where the counts
were expected to be correct.
Previously, the node used the "true" normal of every looptri. Now it uses the
"loop normals" which includes e.g. smooth faces and custom normals. The true
normal can still be used on the points by capturing it before the Distribute node.
We do intend to expose the smooth normals separately in geometry nodes as well,
but this is an important first step.
It's also necessary to generate child hair between guide hair strands that don't
have visible artifacts at face boundaries.
For perfect backward compatibility, the node still has a "Legacy Normal" option
in the side bar. Creating the exact same behavior with existing nodes isn't
really possible unfortunately because of the specifics of how the Distribute
node used to compute the normals using looptris.
Pull Request #104414
This just adds `threading::parallel_for` and `threading::parallel_invoke` in a few
places where it can be added trivially. The run time of the `separate_geometry`
function changes from 830 ms to 413 ms in my test file.
Pull Request #104563
Add a new node that groups faces inside of boundary edge regions.
This is the opposite action as the existing "Face Group Boundaries"
node. It's also the same as some of the "Initialize Face Sets"
options in sculpt mode.
Discussion in #102962 has favored "Group" for a name for these
sockets rather than "Set", so that is used here.
Pull Request #104428
As described in #95966, replace the `ME_EDGEDRAW` flag with a bit
vector in mesh runtime data. Currently the the flag is only ever set
to false for the "optimal display" feature of the subdivision surface
modifier. When creating an "original" mesh in the main data-base,
the flag is always supposed to be true.
The bit vector is now created by the modifier only as necessary, and
is cleared for topology-changing operations. This fixes incorrect
interpolation of the flag as noted in #104376. Generally it isn't
possible to interpolate it through topology-changing operations.
After this, only the seam status needs to be removed from edges before
we can replace them with the generic `int2` type (or something similar)
and reduce memory usage by 1/3.
Related:
- 10131a6f62
- 145839aa42
In the future `BM_ELEM_DRAW` could be removed as well. Currently it is
used and aliased by other defines in some non-obvious ways though.
Pull Request #104417
Straightforward port. I took the oportunity to remove some C vector
functions (ex: copy_v2_v2).
This makes some changes to DRWView to accomodate the alignement
requirements of the float4x4 type.
This implements two optimizations:
* If the duplication count is constant, the offsets array can be
filled directly in parallel.
* Otherwise, extracting the counts from the virtual array is parallelized.
But there is still a serial loop over all elements in the end to compute
the offsets.
Straightforward port. I took the oportunity to remove some C vector
functions (ex: `copy_v2_v2`).
This makes some changes to DRWView to accomodate the alignement
requirements of the float4x4 type.
This declaration change tells the evaluation system that the radius
field is evaluated on the input geometry. Which in turn means that
attributes referenced by the radius field should be propagated to
the geometry.
In the node groups for T103730, the "Points of Curve" node is often used to
retrieve the root point of every curve. Since the curve point offsets array
already contains that data directly, we can detect this as a special case and
avoid all the other work.
Differential Revision: https://developer.blender.org/D17128
The node does not support blurring booleans, but that was not handled
property in link drag search.
Differential Revision: https://developer.blender.org/D17139
In 7536abbe16 changes make possible to input field as Count field.
But changes of declaration probably was forgotten. So now this input
can take field and node will be work. But input link was red. This
patch resolves this issue.
Differential Revision: https://developer.blender.org/D17131
When the sort weights are a single value, they have no effect,
so sorting the relevant indices for the element will be wasted work.
The sorting is expensive compared to the rest of the node. In my
simple test of the points of curve node, it became 6 times faster
when the weights are a single value.
`remember_deformed_curve_positions_if_necessary` has to be called before
topology changing operations on curves. Otherwise the crazy-space data
is invalid.
The call to BKE_volume_grid_openvdb_for_write() was accidentally removed
in D15806. This adds it to BKE_volume_grid_transform_matrix_set() to
avoid that it happens again when that function is used.
Differential Revision: D16949
This improves performance in cases where the Set Position node is "turned off"
by passing `false` into the selection input.
It's possible that the node still takes some time in this case currently, because
it is destructing the input fields which may reference geometries that need
to be destructed as well. We could potentially change this node (and others)
so that the field inputs are only requested when the selection is not a
constant `false`.
This adds a new `Interpolate Curves` node. It allows generating new curves
between a set of existing guide curves. This is essential for procedural hair.
Usage:
- One has to provide a set of guide curves and a set of root positions for
the generated curves. New curves are created starting from these root
positions. The N closest guide curves are used for the interpolation.
- An additional up vector can be provided for every guide curve and
root position. This is typically a surface normal or nothing. This allows
generating child curves that are properly oriented based on the
surface orientation.
- Sometimes a point should only be interpolated using a subset of the
guides. This can be achieved using the `Guide Group ID` and
`Point Group ID` inputs. The curve generated at a specific point will
only take the guides with the same id into account. This allows e.g.
for hair parting.
- The `Max Neighbors` input limits how many guide curves are taken
into account for every interpolated curve.
Differential Revision: https://developer.blender.org/D16642
Based on discussion about T102962, rename the "Face Set Boundaries" node
to "Face Group Boundaries" and the Accumulate Field node's "Group Index"
socket to "Group ID". This convention of "__ Group" and "Group ID" will
be used more in other nodes in the future.
This commit doesn't affect forwards or backwards compatibility.
The same logic from D17025 is used in other places in the curve code.
This patch uses the class for the evaluated point offsets and the Bezier
control point offsets. This helps to standardize the behavior and make
it easier to read.
Previously the Bezier control point offsets used a slightly different standard
where the first point was the first offset, just so they could have the same
size as the number of points. However two nodes used a helper function
to use the same `OffsetIndices` system, so switch to that there too.
That requires removing the subtraction by one to find the actual offset.
Also add const when accessing data arrays from curves, for consistency.
Differential Revision: https://developer.blender.org/D17038
There is a utility method on `CurvesGeometry` to build a map of the
curve for each point. Use that in two more places and make sure its
implementation is multithreaded, which gives a slight speedup
in a simple test file.
This abstraction is rarely used. It could be replaced by some more
general "query" API in the future. For now it's easier to just compare
pointers in the Set Position node where this was used.
This is possible now, because mesh positions are stored as flat `float3`
arrays (previously, they were stored as `MVert` with some other data
interleaved).
This changes how we access the points that correspond to each curve in a `CurvesGeometry`.
Previously, `CurvesGeometry::points_for_curve(int curve_index) -> IndexRange`
was called for every curve in many loops. Now one has to call
`CurvesGeometry::points_by_curve() -> OffsetIndices` before the
loop and use the returned value inside the loop.
While this is a little bit more verbose in general, it has some benefits:
* Better standardization of how "offset indices" are used. The new data
structure can be used independent of curves.
* Allows for better data oriented design. Generally, we want to retrieve
all the arrays we need for a loop first and then do the processing.
Accessing the old `CurvesGeometry::points_for_curve(...)` did not follow
that design because it hid the underlying offset array.
* Makes it easier to pass the offsets to a function without having to
pass the entire `CurvesGeometry`.
* Can improve performance in theory due to one less memory access
because `this` does not have to be dereferenced every time.
This likely doesn't have a noticable impact in practice.
Differential Revision: https://developer.blender.org/D17025
Give the "Value" input a higher search weight than the "Index"
input, since it's more likely that users will want to connect to
that. Based on feedback from Simon Thommes.
