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.
Previously, the node would always evaluate the input field on the
entire geometry domain. This is good when most indices will be
accessed afterwards. However, it is quite a bad when only a single
index is used. Now the field is only evaluated for that one index.
Since a year and a half ago we've been switching to a new way to
represent what sockets a node should have called "declarations"
that's easier to use, clearer, and more flexible for upcoming
features like dynamic socket counts or generic type sockets.
All builtin nodes with a static set of sockets have switched, but one
missing area has been group nodes and group input/output nodes. These
nodes have **dynamic** declarations which change based on their
properties or the group they're inside of. This patch addresses that,
in preparation for using the same dynamic declaration feature for
simulation nodes.
Generally there shouldn't be user-visible differences, but one benefit
is that user-created socket descriptions are now visible directly in
the node editor for group nodes and group input/output nodes.
The commit contains a few changes:
- Add a node type callback for building dynamic declarations with
different arguments
- Add an `Extend` socket declaration for the "virtual" sockets used
for connecting new links
- A similar `Custom` socket declaration is used for addon-defined socket
- Simplify the node update loop to use the declaration to build update
sockets
- Replace the "group update" functions with the declaration building
- Move the node group input/output link creation to link drag operator
- Make the field status part of group node declarations
(not for group input/output nodes though)
- Some fixes for declarations to make them update and build properly
Differential Revision: https://developer.blender.org/D16850
Previously transforming and translating meshes (used by the object info
and transform geometry nodes) was single threaded. Now use the same
code path as other geometry types which already includes multithreading.
I observed a 5x performance improvement for a 4 million vert mesh on a
Ryzen 7950x.
Previously, `ParamsBuilder` lazily allocated an array for an
output when it was unused, but the called multi-function
wanted to access it. Now, whether the multi-function supports
an output to be unused is part of the signature. This way, the
allocation can happen earlier when the parameters are build.
The benefit is that this makes all methods of `MFParams`
thread-safe again, removing the need for a mutex.
Currently you can retrieve a mutable array from a const CustomData.
That makes code unsafe since the compiler can't check for correctness
itself. Fix that by introducing a separate function to retrieve mutable
arrays from CustomData. The new functions have the `_for_write`
suffix that make the code's intention clearer.
Because it makes retrieving write access an explicit step, this change
also makes proper copy-on-write possible for attributes.
Notes:
- The previous "duplicate referenced layer" functions are redundant
with retrieving layers with write access
- The custom data functions that give a specific index only have
`for_write` to simplify the API
Differential Revision: https://developer.blender.org/D14140
Avoid using components that can contain null pointer.
Getting attibute should avoid trying to do it for a null mesh.
This fix bypasses working with components.
Differential Revision: https://developer.blender.org/D16997
The crease custom data layer was added to a mutable version of the mesh,
but that wasn't used in the rest of the operation. Also the layer wasn't
retrieved properly with write access from the custom data API (fixed
separately as part of D14140). Also clean up a bit by retrieving
attributes from the mesh directly and by tweaking naming a bit.
- `Interpolate Domain` -> `Evaluate on Domain`
- `Field at Index` -> `Evaluate at Index`
These names, discussed in recent geometry nodes submodule meetings,
describe actions rather than nouns, which is generally how nodes are
supposed to be named. The names are consistent, which is helpful
because they're similar conceptually. They also don't require knowledge
of the field concept, which we generally try to keep out of the UI in
favor of more beginner-friendly concepts.
We hope to add the ability to search for nodes with multiple
names for 3.5, so the old names can still have search items.
This patch is a response to T101313.
Adds a selection to the Store Named Attribute node.
If the attribute does not exist unselected parts
are filled with zero values. Otherwise, only the
selected parts are filled.
Differential Revision: https://developer.blender.org/D16237
The mesh positions are now a span, but the convex hull didn't copy
the custom data layout to the new mesh since it assumed it didn't
need to. Moving UV maps to a generic attribute triggers this difference
in the test results.
It doesn't really make sense for the convex hull node to copy the
source mesh custom data layout at all anyway, but do it anyway
to avoid having to change the tests right now.
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
