For copy-on-write, we want to share attribute arrays between meshes
where possible. Mutable pointers like `Mesh.mvert` make that difficult
by making ownership vague. They also make code more complex by adding
redundancy.
The simplest solution is just removing them and retrieving layers from
`CustomData` as needed. Similar changes have already been applied to
curves and point clouds (e9f82d3dc7, 410a6efb74). Removing use of
the pointers generally makes code more obvious and more reusable.
Mesh data is now accessed with a C++ API (`Mesh::edges()` or
`Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`).
The CoW changes this commit makes possible are described in T95845
and T95842, and started in D14139 and D14140. The change also simplifies
the ongoing mesh struct-of-array refactors from T95965.
**RNA/Python Access Performance**
Theoretically, accessing mesh elements with the RNA API may become
slower, since the layer needs to be found on every random access.
However, overhead is already high enough that this doesn't make a
noticible differenc, and performance is actually improved in some
cases. Random access can be up to 10% faster, but other situations
might be a bit slower. Generally using `foreach_get/set` are the best
way to improve performance. See the differential revision for more
discussion about Python performance.
Cycles has been updated to use raw pointers and the internal Blender
mesh types, mostly because there is no sense in having this overhead
when it's already compiled with Blender. In my tests this roughly
halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million
face grid).
Differential Revision: https://developer.blender.org/D15488
This patch moves material indices from the mesh `MPoly` struct to a
generic integer attribute. The builtin material index was already
exposed in geometry nodes, but this makes it a "proper" attribute
accessible with Python and visible in the "Attributes" panel.
The goals of the refactor are code simplification and memory and
performance improvements, mainly because the attribute doesn't have
to be stored and processed if there are no materials. However, until
4.0, material indices will still be read and written in the old
format, meaning there may be a temporary increase in memory usage.
Further notes:
* Completely removing the `MPoly.mat_nr` after 4.0 may require
changes to DNA or introducing a new `MPoly` type.
* Geometry nodes regression tests didn't look at material indices,
so the change reveals a bug in the realize instances node that I fixed.
* Access to material indices from the RNA `MeshPolygon` type is slower
with this patch. The `material_index` attribute can be used instead.
* Cycles is changed to read from the attribute instead.
* BMesh isn't changed in this patch. Theoretically it could be though,
to save 2 bytes per face when less than two materials are used.
* Eventually we could use a 16 bit integer attribute type instead.
Ref T95967
Differential Revision: https://developer.blender.org/D15675
The case when the query uv is almost on an edge but outside of any
triangle was handled before. Now the case where the query uv is
almost on an edge but inside more than one triangle is handled as well.
Using the same `GeometryComponentFieldContext` for all situations,
even when only one geometry type is supported is misleading, and mixes
too many different abstraction levels into code that could be simpler.
With the attribute API moved out of geometry components recently,
the "component" system is just getting in the way here.
This commit adds specific field contexts for geometry types: meshes,
curves, point clouds, and instances. There are also separate field input
helper classes, to help reduce boilerplate for fields that only support
specific geometry types.
Another benefit of this change is that it separates geometry components
from fields, which makes it easier to see the purpose of the two concepts,
and how they relate.
Because we want to be able to evaluate a field on just `CurvesGeometry`
rather than the full `Curves` data-block, the generic "geometry context"
had to be changed to avoid using `GeometryComponent`, since there is
no corresponding geometry component type. The resulting void pointer
is ugly, but only turns up in three places in practice. When Apple clang
supports `std::variant`, that could be used instead.
Differential Revision: https://developer.blender.org/D15519
When the curve type attribute doesn't exist, there is no reason to
create an array for it only to fill the default value, which will add
overhead to subsequent "add" operations. I added a "get_if_single"
method to virtual array to simplify this check. Also use the existing
functions for filling curve types.
Differential Revision: https://developer.blender.org/D15560
The `DefaultMixer` for mixing generic data types has some issues:
1. The full buffer is always zeroed, even if only some is used.
2. Finalizing also works on all values, even if only some are used.
3. "mixing" doesn't allow setting the first value, requiring that
everything is cleared beforehand.
This commit adds the following functionality:
1. Constructor with the specified `IndexMask` for preliminary zeroing.
2. `set` method to overwrite the value.
3. `finalize` with the specified mask to process a subset of values.
This is useful in situations where you want to use the
DefaultMixer without having to overwrite all the values many times.
A performance improvement was observed for NURBS curve evaluation and
attribute interpolation from the point to curve domain of about 15% and
35% respectively (100,000 curves).
Differential Revision: https://developer.blender.org/D15434
This adds three new nodes:
* `Shortest Edge Paths`: Actually finds the shortest paths.
* `Edge Paths to Curves`: Converts the paths to separate curves.
This may generate a quadratic amount of data, making it slow
for large meshes.
* `Edge Paths to Selection`: Generates an edge selection that
contains all edges that are part of a path. This can be used
with the Separate Geometry node to only keep the edges that
are part of a path. For large meshes, this approach can be
much faster than the `Edge Paths to Curves` node, because
less data is created.
Differential Revision: https://developer.blender.org/D15274
UV maps that are used for surface attachment must not have overlapping
uv islands, because then the same uv coordinate would correspond to
multiple surface positions.
Ref T99936.
Previously, curves sculpt tools only worked on original data. This was
very limiting, because one could effectively only sculpt the curves when
all procedural effects were turned off. This patch adds support for curves
sculpting while looking the result of procedural effects (like deformation
based on the surface mesh). This functionality is also known as "crazy space"
support in Blender.
For more details see D15407.
Differential Revision: https://developer.blender.org/D15407
This commit removes the use of PolySpline for resampling curves and
replaces it with the length parameterization utility for that purpose.
I didn't test performance, but I would expect the shrinking to be
slightly faster because I reused some arrays to avoid allocating
them for every curve. I noted some potential improvements in
the "add curves" function.
Differential Revision: https://developer.blender.org/D15342
This commit ports the fillet curves node to the new curves data-block,
and moves the fillet node implementation to the geometry module to help
separate the implementation from the node.
The changes are similar to the subdivide node or resample node. I've
resused common utilities where it makes sense, though some things like
the iteration over attributes can be generalized further. The node
is now multi-threaded per-curve and inside each curve, and some buffers
are reused per curve to avoid many allocations.
The code is more explicit now, and though there is more boilerplate to
pass around many spans, the more complex logic should be more readable.
Differential Revision: https://developer.blender.org/D15346
These mutable pointers present problems with ownership in relation to
proper copy-on-write for attributes. The simplest solution is to just
remove them and retrieve the layers from `CustomData` when they are
needed. This also removes the complexity and redundancy of having to
update the pointers as the curves change. A similar change will apply
to meshes and point clouds.
One downside of this change is that it makes random access with RNA
slower. However, it's simple to just use the RNA attribute API instead,
which is unaffected. In this patch I updated Cycles to do that. With
the future attribute CoW changes, this generic approach makes sense
because Cycles can just request ownership of the existing arrays.
Differential Revision: https://developer.blender.org/D15486
Previously, things like materials, symmetry, and selection options
stored on `Curves` weren't copied to the result in nodes like the
subdivide and resample nodes. Now they are, which fixes some
unexpected behavior and allows visualization of the sculpt mode
selection.
In the realize instances and join nodes the behavior is the same as
for meshes, the parameters are taken from the first (top) input.
I also refactored some functions to return a `CurvesGeometry` by-value,
which makes it the responsibility of the node to copy the parameters.
That should make the algorithms more reusable in other situations.
Differential Revision: https://developer.blender.org/D15408
Currently, there are two attribute API. The first, defined in `BKE_attribute.h` is
accessible from RNA and C code. The second is implemented with `GeometryComponent`
and is only accessible in C++ code. The second is widely used, but only being
accessible through the `GeometrySet` API makes it awkward to use, and even impossible
for types that don't correspond directly to a geometry component like `CurvesGeometry`.
This patch adds a new attribute API, designed to replace the `GeometryComponent`
attribute API now, and to eventually replace or be the basis of the other one.
The basic idea is that there is an `AttributeAccessor` class that allows code to
interact with a set of attributes owned by some geometry. The accessor itself has
no ownership. `AttributeAccessor` is a simple type that can be passed around by
value. That makes it easy to return it from functions and to store it in containers.
For const-correctness, there is also a `MutableAttributeAccessor` that allows
changing individual and can add or remove attributes.
Currently, `AttributeAccessor` is composed of two pointers. The first is a pointer
to the owner of the attribute data. The second is a pointer to a struct with
function pointers, that is similar to a virtual function table. The functions
know how to access attributes on the owner.
The actual attribute access for geometries is still implemented with the `AttributeProvider`
pattern, which makes it easy to support different sources of attributes on a
geometry and simplifies dealing with built-in attributes.
There are different ways to get an attribute accessor for a geometry:
* `GeometryComponent.attributes()`
* `CurvesGeometry.attributes()`
* `bke::mesh_attributes(const Mesh &)`
* `bke::pointcloud_attributes(const PointCloud &)`
All of these also have a `_for_write` variant that returns a `MutabelAttributeAccessor`.
Differential Revision: https://developer.blender.org/D15280
Allow for a small epsilon to improve handling of uvs that are on edges.
Generally, when using reverse uv sampling, we expect that the sampling
is supposed to succeed.
This commit moves the subdivide curve node implementation to the
geometry module, changes it to work on the new curves data-block,
and adds support for Catmull Rom curves. Internally I also added
support for a curve domain selection. That isn't used, but it's
nice to have the option anyway.
Users should notice better performance as well, since we can avoid
many small allocations, and there is no conversion to and from the
old curve type.
The code uses a similar structure to the resample node (60a6fbf5b5)
and the set type node (9e393fc2f1). The resample curves node can be
restructured to be more similar to this soon though.
Differential Revision: https://developer.blender.org/D15334
This refactor had two main goals:
* Simplify the sampling code by using an algorithm with fewer special cases.
* Generalize the sampling to support non-sorted samples.
The `SampleSegmentHint` optimization was inspired by `ValueAccessor` from
OpenVDB and improves performance 2x in my test cases.
Differential Revision: https://developer.blender.org/D15348
