Previously, node types had a callback that creates internal links. Pretty
much all nodes used the same callback though. The exceptions are the
reroute node (which probably shouldn't be mutable anyway) and some
input/output nodes that are not mutable.
Removing the callback helps with D13246, because it makes it easier
to reason about which internal links are created and when they change.
In the future, the internal links should be part of the node declaration.
This cleans up part of the code that still set the flag manually. Also, this
change helps with D13246 because it makes it easier to tag the node
tree as changed when the availability of a socket changed.
This commit contains a few mostly-related changes to this node:
- Add a warning when retrieving the geometry from the modifier object.
- Only create the output geometry when it is necessary.
- Decompose transform matrices in a more friendly way.
- Use default return callbacks like other newer nodes.
Differential Revision: https://developer.blender.org/D13232
Goals of this refactor:
* Simplify creating virtual arrays.
* Simplify passing virtual arrays around.
* Simplify converting between typed and generic virtual arrays.
* Reduce memory allocations.
As a quick reminder, a virtual arrays is a data structure that behaves like an
array (i.e. it can be accessed using an index). However, it may not actually
be stored as array internally. The two most important implementations
of virtual arrays are those that correspond to an actual plain array and those
that have the same value for every index. However, many more
implementations exist for various reasons (interfacing with legacy attributes,
unified iterator over all points in multiple splines, ...).
With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and
`GVMutableArray`) can be used like "normal values". They typically live
on the stack. Before, they were usually inside a `std::unique_ptr`. This makes
passing them around much easier. Creation of new virtual arrays is also
much simpler now due to some constructors. Memory allocations are
reduced by making use of small object optimization inside the core types.
Previously, `VArray` was a class with virtual methods that had to be overridden
to change the behavior of a the virtual array. Now,`VArray` has a fixed size
and has no virtual methods. Instead it contains a `VArrayImpl` that is
similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly,
unless a new virtual array implementation is added.
To support the small object optimization for many `VArrayImpl` classes,
a new `blender::Any` type is added. It is similar to `std::any` with two
additional features. It has an adjustable inline buffer size and alignment.
The inline buffer size of `std::any` can't be relied on and is usually too
small for our use case here. Furthermore, `blender::Any` can store
additional user-defined type information without increasing the
stack size.
Differential Revision: https://developer.blender.org/D12986
The node does support curves, but only in index mode (see T88630)
So add a specific error message for the nearest mode, and let the
node support curves in the declaration.
Differential Revision: https://developer.blender.org/D13205
Adds a boolean field output containing a selection of the
points of the star that are controlled by the outer radius
of the star.
Differential Revision: https://developer.blender.org/D13097
Adds a vector offset field to the "Curve Handle Position Node".
This vector is added to the incoming position (which is the
implicit handle position if not connected) which will set the
position of the handle. Default is (0,0,0)
Differential Revision: https://developer.blender.org/D13035
Currently the Distribute Points on Faces node does not propagate
non-point attributes correctly. That is because it first interpolates the
attributes to the point domain on the input mesh, and then propagates them.
Differential Revision: https://developer.blender.org/D13148
Reference struct members by name instead relying on their order.
This also simplifies moving back to named members when all compilers
we use support them.
The point domain attributes (stored on splines) are sorted so they
have a consistent order on all splines after the join. However, spline
domain attributes were included in the new order, which didn't work
because the length of the attribute lists didn't match. The simple fix
is to only include point domain attributes in the new order vector.
Adds a length output to the curve parameter node which returns the
length of a spline at each point, or the length of the curve at
each spline depending on the domain.
Differential Revision: https://developer.blender.org/D12882
Building on the work in rBef45399f3be0, this commits adds
tooltips to the inputs for the default primitives nodes.
Differential Revision: https://developer.blender.org/D12640
Add a boolean input to the resample curve node that indicates which
splines should be resampled and which should be unchanged.
Differential Revision: https://developer.blender.org/D13064
This properly checks the order of point domain attributes on each
spline, and avoids the map, which makes the code easier to understand.
The assert is also added to realizing instances and the join node.
Differential Revision: https://developer.blender.org/D13071
Currently the curve to mesh node relies on the order of attributes being
the same on every spline. This is a worthwhile assumption, because it
will allow removing the attribute name storage duplication on every
spline in the future.
However, the join geometry node broke this order, since it just created
new attributes without any regard to the order. To fix this, I added a
"reorder" step after all the merged attributes have been created, the
types have been joined, etc. It should be possible to change this code
so that the attributes are added with the right order in the first
place, but I would like to do that after refactoring spline attribute
storage, and not for 3.0.
Differential Revision: https://developer.blender.org/D13074
Even though volumes can only have one material, it is still necessary to
allow assigning a material to a prodecurally created volume. This commit
adds volume support and a warning for when a non-constant selection is
used with a volume.
Fixes T92485
Differential Revision: https://developer.blender.org/D13037
Instead of creating a separate grid first and then merging the points
to volume grid, use the recently added `BKE_volume_grid_add_vdb`
helper function for this purpose.
This node doesn't only support point clouds, it supports any geometry
component type with points, so meshes, curves, and point clouds.
We could explicitly list them to add a warning for volumes, but
that wouldn't really have any practical benefit, and isn't done
elsewhere.
As part of the refactor to the node declaration builders, we had hoped
to add a regular expression specifically for these socket names, but
recent discussions have revealed that using the translation marker
macros is the preferred solution.
If the names and descriptions were exposed to RNA, these would not
be necessary. However, that may be quite complicated, since sockets
are all instances of the same RNA types.
Differential Revision: https://developer.blender.org/D13033
Calling `remove_unused_references` inside the `modify_geometry_sets` loop
was known to be not entirely reliable before. Now I just moved it out of
the loop which fixes the bug.
This fixes one (of possibly multiple) root issues. The collection passed into
the Collection Info node must not contain the current object, because that
would result in a dependency cycle and recursive instancing.
The text is just too long, it doesn't fit in the node width,
and the tooltips display the property names well enough,
since they aren't used as often as other settings.
Also display the text in lite builds too, there is no reason not to.
That makes the node more useful by default.
One use case is to delete some points after the Set ID node, then instance
with some randomness. Now when deleting different points, the
randomness will remain stable.
Subdivision surface: Both geometry sockets renamed to "Mesh"
Points to Volume: Use "Points" and "Volume" names
Distribute Points on Faces: Use "Mesh" input name
These are meant to provide a hint to users which type each
node is meant to use.
