| Age | Commit message (Collapse) | Author |
|---|
|
Replace `mesh_attributes`, `mesh_attributes_for_write` and the point
cloud versions with methods on the `Mesh` and `PointCloud` types.
This makes them friendlier to use and improves readability.
Differential Revision: https://developer.blender.org/D15907
|
|
Follows existing naming for the most part, also use "num" as a suffix
in some instances (following our naming conventions).
|
|
Use `verts` instead of `vertices` and `polys` instead of `polygons`
in the API added in 05952aa94d33eeb50. This aligns better with
existing naming where the shorter names are much more common.
|
|
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 (e9f82d3dc7ee, 410a6efb747f). 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 is a cleanup required before refactoring the view layer syncing
process {T73411}.
* Remove FIRSTBASE.
* Remove LASTBASE.
* Remove BASACT.
* Remove OBEDIT_FROM_WORKSPACE.
* Replace OBACT with BKE_view_layer_active_object.
* Replace OBEDIT_FROM_VIEW_LAYER with BKE_view_layer_edit_object.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15799
|
|
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 purpose of `NodeTreeRef` was to speed up various queries on a read-only
`bNodeTree`. Not that we have runtime data in nodes and sockets, we can also
store the result of some queries there. This has some benefits:
* No need for a read-only separate node tree data structure which increased
complexity.
* Makes it easier to reuse cached queries in more parts of Blender that can
benefit from it.
A downside is that we loose some type safety that we got by having different
types for input and output sockets, as well as internal and non-internal links.
This patch also refactors `DerivedNodeTree` so that it does not use
`NodeTreeRef` anymore, but uses `bNodeTree` directly instead.
To provide a convenient API (that is also close to what `NodeTreeRef` has), a
new approach is implemented: `bNodeTree`, `bNode`, `bNodeSocket` and `bNodeLink`
now have C++ methods declared in `DNA_node_types.h` which are implemented in
`BKE_node_runtime.hh`. To make this work, `makesdna` now skips c++ sections when
parsing dna header files.
No user visible changes are expected.
Differential Revision: https://developer.blender.org/D15491
|
|
|
|
In all these cases, it was clear that the layer values were set right
after the layer was created anyway. So there's no point in using
calloc or setting the values to zero first.
See 25237d2625078c6d for more info.
|
|
|
|
When allocating new `CustomData` layers, often we do redundant
initialization of arrays. For example, it's common that values are
allocated, set to their default value, and then set to some other
value. This is wasteful, and it negates the benefits of optimizations
to the allocator like D15082. There are two reasons for this. The
first is array-of-structs storage that makes it annoying to initialize
values manually, and the second is confusing options in the Custom Data
API. This patch addresses the latter.
The `CustomData` "alloc type" options are rearranged. Now, besides
the options that use existing layers, there are two remaining:
* `CD_SET_DEFAULT` sets the default value.
* Usually zeroes, but for colors this is white (how it was before).
* Should be used when you add the layer but don't set all values.
* `CD_CONSTRUCT` refers to the "default construct" C++ term.
* Only necessary or defined for non-trivial types like vertex groups.
* Doesn't do anything for trivial types like `int` or `float3`.
* Should be used every other time, when all values will be set.
The attribute API's `AttributeInit` types are updated as well.
To update code, replace `CD_CALLOC` with `CD_SET_DEFAULT` and
`CD_DEFAULT` with `CD_CONSTRUCT`. This doesn't cause any functional
changes yet. Follow-up commits will change to avoid initializing
new layers where the correctness is clear.
Differential Revision: https://developer.blender.org/D15617
|
|
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
|
|
Problem with e3a6a2f41284f90b010.
|
|
|
|
OpenVDB crashes when the determinant of the grid transformation is
too small. The solution is too detect when the determinant is too small
and to replace the grid with an empty one. If possible the translation
and rotation of the grid remains unchanged.
Differential Revision: https://developer.blender.org/D15806
|
|
|
|
|
|
The triangulate node is not supposed to take shape keys into account.
This was likely a mistake in rBabf30007abdac2a5bf3a1.
|
|
|
|
Differential Revision: https://developer.blender.org/D15705
|
|
|
|
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D15630
|
|
|
|
Mistake in c8ae1fce6024556b72c.
|
|
Fixes the typo in the struct `DefaultPropatationMixerStruct`.
|
|
|
|
Also add an error message for when the node is used on non-curves
objects, since there's nothing in the UI to show why it doesn't work
except for that. And also use quotes when referring to attribute names.
|
|
|
|
|
|
|
|
|
|
There was already a utility to retrieve the correct node group idname
from the context, `node_group_idname`, but often it's clearer to
use lower-level arguments, or the context isn't accessible.
Storing the group idname in the tree type makes it accessible
without rewriting it elsewhere.
|
|
Found while investigating why crazy-space editing didn't work in T100026.
|
|
This name doesn't require understanding of fields, and
is phrased as an action which is consistent with other nodes.
Discussed in the latest geometry nodes sub-module meeting.
|
|
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
|
|
It was never added for the field on domain and field at index nodes.
They need special handling because they have many what should be
a multi-type socket declaration.
|
|
Changing the value doesn't accomplish anything, since the retrieved
value would be the same for every index then. So it's best to hide it
to make the node clearer.
|
|
`parallel_invoke` allows executing functions on separate threads.
However, creating tasks in tbb has a measurable amount of overhead.
Therefore, it can be benefitial to disable parallelization when
the amount of work done per function is small.
See D15539 for some benchmark results.
Differential Revision: https://developer.blender.org/D15539
|
|
Use an imperfect solution, since this code will be replaced soon anyway.
|
|
In a test producing 10 million vertices I observed a 3.6x improvement,
from 470ms to 130ms. The largest improvement comes from calculating
each mesh array on a separate thread. Besides that, the larger changes
come from splitting the filling of corner and face arrays, and
precalculating sines and cosines for each ring.
Using `parallel_invoke` does gives some overhead. On a small 32x16
input, the time went up from 51us to 74us. It could be disabled
for small outputs in the future. The reasoning for this parallelization
method instead of more standard data-size-based parallelism is that the
latter wouldn't be helpful except for very high resolution.
|
|
|
|
Also rearrange some lines to simplify logic.
|
|
Since fd5e5dac8946b13599, the node would remove the attribute before
adding it again, which lost the vertex group status of an attribute,
meaning they were written as arbitrary attributes.
Now, the node first tries to write to attributes with the same domain
and data-type, which covers the vertex group case. Then it falls back
to removing the attribute and adding it again. Even that can fail
though, so I added an error message to make that a bit clearer.
Differential Revision: https://developer.blender.org/D15514
|
|
Use the newer more generic sampling and interpolation functions
developed recently (ab444a80a280) instead of the `CurveEval` type.
Functions are split up a bit more internally, to allow a separate mode
for supplying the curve index directly in the future (T92474).
In one basic test, the performance seems mostly unchanged from 3.1.
Differential Revision: https://developer.blender.org/D14621
|
|
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
|
|
All callers passed `false` for this parameter, making it more confusing
than useful. If this functionality is needed again in the future, a separate
function should be added.
Differential Revision: https://developer.blender.org/D15401
|
|
Differential Revision: https://developer.blender.org/D15445
|
|
Remove the boilerplate of using a local geometry component just to use
the attribute API that was necessary before b876ce2a4a4638142439.
|
|
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
|
