This removes `AnonymousAttributeID` which was "attached" to every anonymous
attribute before. It adds more complexity than is justified for its
functionality.
It was originally introduced to keep the reference count of the anonymous
attribute so that it can be deleted automatically when the attribute is not
referenced anymore. For quite some time we have had deterministic attribute
life-times though which don't rely on the reference count anymore.
Anonymous attributes are sometimes shown in the UI as "friendly looking" string
like `"UV Map" from Cube`. Some information necessary for this was also stored
in `AnonymousAttributeID`. However, this can also be solved differently.
Specifically, this functionality has now been added directly to
`AttributeFieldInput`.
This refactor also allows removing `AttributeIDRef` which was mainly introduced
because we had to keep the `AnonymousAttributeID` attached with the attribute
name. Just using simple string types to identify attributes can reduce the
mental overhead quite significantly. This will be done as a separate refactor
though.
Pull Request: https://projects.blender.org/blender/blender/pulls/127081
And same for the `copy_layout` function. These functions do not free any
potentially existing data in destination, but expect it to be uninitialized.
Hopefully these new names will make it more clear and avoid bugs like #122160.
There is a reason for the bitwise operator but it's not explained:
The attribute_foreach function callback has side-effects that the
compiler does not know about (everything is const). Simply replacing
the bitwise operator will cause the second term to be skipped, which
breaks tests due to missing attributes.
Now the term is explicitly evaluated first, then combined with actual
boolean operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/126366
The grid geometry creation incorrectly tagged the mesh with no loose edges
or vertices, breaking invariants of the caches that are relied on elsewhere.
This adds a `geometry::smooth_curve_positions` function that
smoothes both bézier curves and all the other curve types.
Bézier curves are smoothed by joining the handle and control
points into a flat array, then using the 1D gaussian algorithm
and writing the resulting positions back into the left and right
handle positions as well as the control points. In general,
this works reasonably well and is similar to the results of the
other curve types.
Pull Request: https://projects.blender.org/blender/blender/pulls/125496
This was reported by the studio. When opening one of the lighting
files in 4.3, Blender would crash.
The realize instance task for grease pencil needs to copy all the
layer attributes to the target geometry. When creating the
`dst_attribute_writers` using `lookup_or_add_for_write_only_span`
the `bke::AttrDomain::Point` was used when it should have been
`bke::AttrDomain::Layer`.
Pull Request: https://projects.blender.org/blender/blender/pulls/125603
This continues the cmake modernization effort and introduces support for
allowing our optional dependencies to integrate properly. TBB is added
here as it's proven troublesome to maintain correctly.
Currently the only Blender project which uses the TBB headers directly
is `blenlib`. However, all downstream projects which require blenlib as
their dependency, and wish to properly make use of its threading
facilities, needed to define various TBB items in their CMake files. Not
only is this unnecessary and arcane, but several projects didn't do this
and ended up not using threading as well as producing ODR violations
along the way[1].
This PR makes TBB a modern dependency and exposes it PUBLIC'ly from
`blenlib`. All downstream projects which depend on blenlib will now
receive everything they require from TBB automatically. This includes
the `WITH_TBB` define, the headers, and the library itself.
[1] blender/blender@05241f47f5
Pull Request: https://projects.blender.org/blender/blender/pulls/124916
Interpolation tool for strokes ported from GPv2.
Adds a new operator that inserts a new frame with interpolated curves.
The source curves are taken from the previous/next keyframe.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/122155
This implements the _automerge_ feature which finds nearby end points
during stroke draw and merges the new curve with existing strokes.
New utility functions are added in `geometry` for slightly generalized
functionality. The `curves_merge_endpoints` takes an index map that
describes how to connect curves by index. It performs a topological sort
and reorders connected curves into contiguous ranges. This can be used
with an arbitrary number of connected curves. The tool feature itself
only uses a single curve, based on 2D end point positions.
Unit tests have been added for the curve merge utility function.
Pull Request: https://projects.blender.org/blender/blender/pulls/124459
Previously, this code would crash when there are vertex groups which are
not stored as simple arrays. This happened e.g. in #124416.
All non-array attributes are converted to array-attributes with this change
for now, which is better than crashing.
Previously, grease pencil was just ignored by the Join Geometry and Realize
Instances code. Now they work by concatenating the layers of all grease pencil
geometries together. So if e.g. there are two inputs with each 3 layers, then
the output will have 6 layers. Layer attributes are kept intact.
Some important things to keep in mind:
* Grease pencil layers are expected to have unique names. Ensuring uniqueness
requires O(n^2) currently.
* The material indices on the curves in each layer have to be remapped.
Just like with all other geometry types, the first input in the Join Geometry
node will come first in the output geometry. Since grease pencil layers are
drawn starting at index zero, that means that the first input will be drawn
first (i.e. it's at the bottom).
Pull Request: https://projects.blender.org/blender/blender/pulls/124361
This adds support for attaching gizmos for input values. The goal is to make it
easier for users to set input values intuitively in the 3D viewport.
We went through multiple different possible designs until we settled on the one
implemented here. We picked it for it's flexibility and ease of use when using
geometry node assets. The core principle in the design is that **gizmos are
attached to existing input values instead of being the input value themselves**.
This actually fits the existing concept of gizmos in Blender well, but may be a
bit unintutitive in a node setup at first. The attachment is done using links in
the node editor.
The most basic usage of the node is to link a Value node to the new Linear Gizmo
node. This attaches the gizmo to the input value and allows you to change it
from the 3D view. The attachment is indicated by the gizmo icon in the sockets
which are controlled by a gizmo as well as the back-link (notice the double
link) when the gizmo is active.
The core principle makes it straight forward to control the same node setup from
the 3D view with gizmos, or by manually changing input values, or by driving the
input values procedurally.
If the input value is controlled indirectly by other inputs, it's often possible
to **automatically propagate** the gizmo to the actual input.
Backpropagation does not work for all nodes, although more nodes can be
supported over time.
This patch adds the first three gizmo nodes which cover common use cases:
* **Linear Gizmo**: Creates a gizmo that controls a float or integer value using
a linear movement of e.g. an arrow in the 3D viewport.
* **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be
rotated to change the attached angle input.
* **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale.
In the future, more built-in gizmos and potentially the ability for custom
gizmos could be added.
All gizmo nodes have a **Transform** geometry output. Using it is optional but
it is recommended when the gizmo is used to control inputs that affect a
geometry. When it is used, Blender will automatically transform the gizmos
together with the geometry that they control. To achieve this, the output should
be merged with the generated geometry using the *Join Geometry* node. The data
contained in *Transform* output is not visible geometry, but just internal
information that helps Blender to give a better user experience when using
gizmos.
The gizmo nodes have a multi-input socket. This allows **controlling multiple
values** with the same gizmo.
Only a small set of **gizmo shapes** is supported initially. It might be
extended in the future but one goal is to give the gizmos used by different node
group assets a familiar look and feel. A similar constraint exists for
**colors**. Currently, one can choose from a fixed set of colors which can be
modified in the theme settings.
The set of **visible gizmos** is determined by a multiple factors because it's
not really feasible to show all possible gizmos at all times. To see any of the
geometry nodes gizmos, the "Active Modifier" option has to be enabled in the
"Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of
the following is true:
* The gizmo controls an input of the active modifier of the active object.
* The gizmo controls a value in a selected node in an open node editor.
* The gizmo controls a pinned value in an open node editor. Pinning works by
clicking the gizmo icon next to the value.
Pull Request: https://projects.blender.org/blender/blender/pulls/112677
`get_count_input_from_length()` did not check whether length is zero,
this would cause division by zero exception. Now will return a segment
count of 1 when a zero length is given.
Pull Request: https://projects.blender.org/blender/blender/pulls/124440
This adds a new `name` member to the `GeometrySet` class. This name can be set
with the new `Set Geometry Name` node. Currently, the name is only used in the
spreadsheet when displaying instances.
The main purpose of this name is to help debugging in instance trees. However, in the
future it may also be used when exporting instance trees or when creating separate
objects from them.
Note, the name is not expected to be unique, it is fully in user control.
Naming geometries is necessary to make the spreadsheet more useful for instances,
because currently the user has no information for which geometry is used by each instance.
We also want to use this name to improve the integration with grease pencil where
sometimes layers become instances with the same name.
Pull Request: https://projects.blender.org/blender/blender/pulls/114910
If the mesh has a curve builtin attribute that's not stored on the point domain,
the creation of the attribute will fail and it can't be interpolated. Possibly this
could be supported somehow, by averaging all the values in the curve's points
or so, but for now just avoid the crash.
Previously, the "Simplify" option was a world space distance threshold.
This meant that zooming in and out of the view changed the way
this option behaved. There were complaints from artists about this.
This change improves two things:
* The simplify algorithm uses the screen space coordinates rather than the
3D positions.
* The UI setting is in pixels making it much easier to tweak (no need
for values in the 1e-4 range).
Pull Request: https://projects.blender.org/blender/blender/pulls/122719
There was an overloaded version of `add_layer` that took
a const reference to a source layer. The function would
duplicate that layer.
The function name `add_layer` was a bit confusing in this
case. Calling it `duplicate_layer` makes it a bit clearer.
As part of #121565.
To avoid using drawing indices outside of the internal grease pencil API,
this refactor adds the functions `GreasePencil::get_eval_drawing` to replace
the `get_eval_grease_pencil_layer_drawing*` functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/121567
Cleanup to avoid unnecessary copies of VArray. This
requires ref-qualifier overloads of dereference operator
of attribute reader and some move operators and constructor
overloads in the code.
Pull Request: https://projects.blender.org/blender/blender/pulls/118437
Previously, the Realize Instances node would always realize everything in the geometry.
Now it's possible to more selectively realize parts of the geometry:
* One can choose which top level instances should be realized.
* The realization depth can be controlled per top-level instance. For example, if there are
5 top level instances, each of which contains 10 other instances, it's now possible to
realize only one level so that one ends up with 50 instances.
Pull Request: https://projects.blender.org/blender/blender/pulls/116582
This implements all the sculpt tools in Grease Pencil 3.
UI changes in the 3D view header and keymap entries for sculpt mode are
still minimal, more entries should be added once the relevant operators
are supported.
A set of utility functions and a shared base class
`GreasePencilStrokeOperationCommon` for sculpt operations has been added
to make individual operations less verbose.
The `GreasePencilStrokeParams` struct bundles common arguments to reduce
the amount of boilerplate code. The `foreach_editable_drawing` utility
function takes care of setting up the parameters and finding the right
drawings, so the tool only has to modify the data. Common features like
tracking mouse movement and inverting brush influence are handled by the
common base class.
Most operations are then relatively simple, with the exception of the
Grab and Clone operations.
- __Grab__ stores a stroke mask and weights on initialization of the
stroke, rather than working with the usual selection mask.
- __Clone__ needs access to the clipboard, which requires exposing the
clipboard in the editor API.
Pull Request: https://projects.blender.org/blender/blender/pulls/120508
This adds a new `Handles` checkbox to the conversion operator that
affects how the conversion works in the following cases:
`Bezier -> Catmull Rom / Poly / Nurbs` and `Catmull Rom -> Nurbs`.
If enabled, three control points are added for each original control
point, otherwise only one.
-----
The images show the effect of the toggle. The top result is always the one with handles and the bottom one without.
* `Bezier -> Poly`
* `Bezier -> Catmull Rom`
* `Bezier -> Nurbs`
* `Catmull Rom -> Nurbs`
Pull Request: https://projects.blender.org/blender/blender/pulls/120423
There was no check for a convex hull with 1-2 points,
causing unwrap to crash on degenerate faces.
Regression caused by [0] (fix for #115061), which hid this bug.
[0]: 0053de6556
Add a simple node to compute the intersection, difference, or union
between SDF grids. This should be the first new use case for the
new volume grid nodes that wasn't possible before.
For naming and multi-inputs, the node uses the same design as the
mesh boolean node. We considered splitting each operation into a
separate node, but though most users considered these different
"modes" of the same operation.
One thing to keep in mind is that it's important for the grids to
have exactly the same transform. If they have different transforms,
the second grid must be resampled to match the first, because the
OpenVDB CSG tools have that requirement. Resampling is expensive
(for SDF grids it means a grid -> mesh -> grid round trip) and should
be avoided.
Pull Request: https://projects.blender.org/blender/blender/pulls/118879
The main motivation for this is that it's part of a fix for #113377,
where I want to propagate the edit mesh pointers through copied
meshes in modifiers and geometry nodes, instead of just setting the
edit mesh pointer at the end of the modifier stack. That would have
two main benefits:
1. We avoid the need to write to the evaluated mesh, after evaluation
which means it can be shared directly among evaluated objects.
2. When an object's mesh is completely replaced by the mesh from another
object during evaluation (with the object info node), the final edit
mesh pointer will not be "wrong", allowing us to skip index-mapped
GPU data extraction.
Beyond that, using a shared pointer just makes things more automatic.
Handling of edit mesh data is already complicated enough, this way some
of the worry and complexity can be handled by RAII.
One thing to keep in mind is that the edit mesh's BMesh is still freed
manually with `EDBM_mesh_free_data` when leaving edit mode. I figured
that was a more conservative approach for now. Maybe eventually that
could be handled automatically with RAII too.
Pull Request: https://projects.blender.org/blender/blender/pulls/120276
The reverse uv sampling operation generally fails when there the sample position
is within more than one uv triangle. Unfortunately, the combination of limited
floating point accuracy and very small triangle areas caused this case
sometimes, even if the triangles don't actually overlap. This happens relatively
rarely, but if it does, it causes annoying artifacts. The solution is to only
detect these kinds of overlapping triangles if they have a certain minimum size
and to be more relaxed otherwise.
Pull Request: https://projects.blender.org/blender/blender/pulls/120408
Avoid copying the positions array into the evaluated edit hints array
that's used to support editing with deformed positions when there is
a topology-changing procedural operation. In a simple test in sculpt
mode with 706k curve points, memory usage went from 78 to 70 MB.
This adds more duplication would be ideal, mainly because retrieving
the data with write access and making implicit sharing info for arbitrary
arrays aren't abstracted by implicit sharing utilities. It may be possible
to improve both of those aspects, either now or in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/120146
