This changes the name from `For Each Geometry Element` to just `For Each
Element`. While we might have more foreach zones in the future, it's not clear
yet whether the longer name will be necessary to differentiate the zones. So
better just use the better looking name for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/128384
This patch improves working with grease pencil layers in geometry nodes.
* Allow layers to have duplicate names in geometry nodes. In original data, unique names are enforced.
* This allows e.g. duplicating layers and then merging them by name in the end.
* It also resolves a big serial bottleneck when working with many grease pencil layers in geometry nodes. Enforcing unique names is inefficient.
* New `Merge Layers` node that can merge multiple layers by name or by a custom group id.
* Applying a grease pencil modifier now first merges all layers with the same name to ensure all names are unique.
Co-authored-by: Jacques Lucke <jacques@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/127873
This adds a new type of zone to Geometry Nodes that allows executing some nodes
for each element in a geometry.
## Features
* The `Selection` input allows iterating over a subset of elements on the set
domain.
* Fields passed into the input node are available as single values inside of the
zone.
* The input geometry can be split up into separate (completely independent)
geometries for each element (on all domains except face corner).
* New attributes can be created on the input geometry by outputting a single
value from each iteration.
* New geometries can be generated in each iteration.
* All of these geometries are joined to form the final output.
* Attributes from the input geometry are propagated to the output
geometries.
## Evaluation
The evaluation strategy is similar to the one used for repeat zones. Namely, it
dynamically builds a `lazy_function::Graph` once it knows how many iterations
are necessary. It contains a separate node for each iteration. The inputs for
each iteration are hardcoded into the graph. The outputs of each iteration a
passed to a separate lazy-function that reduces all the values down to the final
outputs. This final output can have a huge number of inputs and that is not
ideal for multi-threading yet, but that can still be improved in the future.
## Performance
There is a non-neglilible amount of overhead for each iteration. The overhead is
way larger than the per-element overhead when just doing field evaluation.
Therefore, normal field evaluation should be preferred when possible. That can
partially still be optimized if there is only some number crunching going on in
the zone but that optimization is not implemented yet.
However, processing many small geometries (e.g. each hair of a character
separately) will likely **always be slower** than working on fewer larger
geoemtries. The additional flexibility you get by processing each element
separately comes at the cost that Blender can't optimize the operation as well.
For node groups that need to handle lots of geometry elements, we recommend
trying to design the node setup so that iteration over tiny sub-geometries is
not required.
An opposite point is true as well though. It can be faster to process more
medium sized geometries in parallel than fewer very large geometries because of
more multi-threading opportunities. The exact threshold between tiny, medium and
large geometries depends on a lot of factors though.
Overall, this initial version of the new zone does not implement all
optimization opportunities yet, but the points mentioned above will still hold
true later.
Pull Request: https://projects.blender.org/blender/blender/pulls/127331
Provide building block support for integer operations.
Manipulation of integer based data should not be limited to using float math nodes.
Using float math comes with accuracy issues for larger integers and requires unnecessary
type conversions.
The node also adds some integer specific operations like GCM and LCD.
Pull Request: https://projects.blender.org/blender/blender/pulls/110735
This node hashes various types into an integer. Note that hashes
cannot generally used as unique identifiers because they are not
guaranteed to be unique. It can be used to generate somewhat
stable randomness though in cases where White Noise does not
offer enough flexibility.
It uses hash functions from BLI_noise.hh. These are also used in
the White Noise node.
Pull Request: https://projects.blender.org/blender/blender/pulls/110769
This implements the `Warning` node that allows node groups to communicate
expectations about input values to the user.
By default, the `Warning` node is only evaluated if the node group that contains
it is evaluated in any way. This is better than always evaluating it, because
that could trigger lots of unnecessary evaluation in parts of the potentially
large node tree which should be ignored. In this basic mode, the output of the
node should not be connected to anything and it must not be in a zone.
For more fine-grained control for when the `Warning` node should be evaluated,
one can use the boolean output which is just a pass-through of the `Show` input.
If this output is used, the `Warning` node will only be evaluated if its output
is used. A simple way to use it is to control a Switch node with it that e.g.
"disables" a specific output when the inputs are invalid. In this case, the
`Warning` node may also be in a zone.
The node allows the user to choose between 3 severity levels: Error, Warning and
Info. Those are the same levels that we use internally. Currently, the error and
warning mode are pretty much the same, but that may change in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/125544
This adds two new nodes:
* `Grease Pencil to Curves`: Converts each grease pencil layer into an instance
that contains curves.
* `Curves to Grease Pencil`: Converts top-level curve instances into grease
pencil layers.
This opens up many new opportunities:
* Use grease pencil as input to other procedural systems that don't necessarily
output grease pencil.
* Generate grease pencil from scratch using geometry nodes.
* Temporarily convert grease pencil data to curves to use more powerful features
for curves processing.
Some data on layers are not attributes yet unfortunately, so there is some
special case handling for the `opacity` attribute. This was previously discussed
at the geometry nodes workshop:
https://devtalk.blender.org/t/2024-05-13-geometry-nodes-workshop-notes/34760#grease-pencil-14
Pull Request: https://projects.blender.org/blender/blender/pulls/124279
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
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
- Sort add menu alphabetically
- Use forward declaration for GeometrySet again
- Use `this->` to access class methods
- Use `MEM_cnew`
- Fix typo
- Pass Span by value
- Pass MutableSpan instead of Vector &
- Remove unnecessary whitespace
- Use `BLI_SCOPED_DEFER` for freeing non-RAII objects
- Use `is_empty()` instead of `size() == 0`
- Use `GeometrySet::from_mesh` ability to handle null argument
Add a node similar to the STL import node (d1455c4138) that
imports OBJ files, including both meshes and curves. The output consists
of a geometry instance for each mesh/curve in the file.
There are a few improvements to address in the future: Currently the node
has no inputs besides the file path. Options may be exposed in the future.
Materials are also not imported yet, because creating material data-blocks
during evaluation may not be trivial.
This is part of a GSoC project:
https://devtalk.blender.org/t/gsoc-2024-geometry-nodes-file-import-nodes/34482
Pull Request: https://projects.blender.org/blender/blender/pulls/123967
A few of the recently added submenus are not included in the list of builtin
menus, so node assets under those catalog names will generate redundant submenus.
Fixes same issue as b49c84276c for newly added nested menus.
Pull Request: https://projects.blender.org/blender/blender/pulls/122855
Add > Utilities submenus for Color and Field do not include assets from the
correctly named catalogs due to typos: "Utilties/Color" and "Utilties/Field"
respectively.
Pull Request: https://projects.blender.org/blender/blender/pulls/122416
This node allows replacing the transformation of every instance by providing a matrix.
Before, this was only possible by using the Store Named Attribute node. It's more common
in Blender to have specialized built-in nodes for built-in attributes (e.g. Set Position, and Set ID).
Pull Request: https://projects.blender.org/blender/blender/pulls/121473
This pull request adds an "Active Element" node that exposes the active
vertex, edge, or face index to the geometry node tool context. The
presence of an active element is available as a boolean.
This node enables the creation of "active-to-selected" style operators.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/121333
This adds a new `Axes to Rotation` node which creates a new rotation.
In many cases, the primary and secondary axis inputs are a normal and
tangent of a mesh or curve. This provides a simpler and more direct way
to create this rotation compared to using two `Align Rotation to Vector` nodes.
This more direct way of computing the rotation also allows us to optimize
the case better.
The node rotates one axis (X, Y or Z) to the given primary axis direction. Then
it rotates around that primary direction to align the second axis to the given
secondary direction. Ideally, both input axes are orthogonal. However, the node
still creates the "best" rotation when they are not orthogonal. If one or the axes
is zero or both are (close to) parallel, the resulting rotation is unstable. There is
not too much the node can do to make it more stable.
Pull Request: https://projects.blender.org/blender/blender/pulls/104416
This (experimental, for now) node retrieve's voxel values
at specific voxel indices for a grid input. It's similar to the
Sample Grid node (77cba3d551), but there is
no interpolation, and it uses indices instead of positions.
Pull Request: https://projects.blender.org/blender/blender/pulls/118690
These nodes allow working with the raw values that make up a matrix.
This can be used to construct a 4x4 matrix directly, without using the
`Combine Transform` node. This allows building transforms with arbitrary
skew, or projection matrices.
Pull Request: https://projects.blender.org/blender/blender/pulls/121283
A version of "Align Euler to Vector" with the rotation socket
instead of the vector Euler socket. Other than that, and a few
cleanups to use newer math functions, the node is the same.
The old node is just "Deprecated" for now. We could remove
it with versioning, but we can also wait to do that.
In a simple test this node is about 1.7 times faster than the old one.
Pull Request: https://projects.blender.org/blender/blender/pulls/118565
Add a "Mouse Position" node that outputs the location of the mouse
cursor in region space and the overall size of the region, both in pixel
units. Both outputs are integers to help reflect their pixel units.
If there the mouse position is ever accessible in sub-pixels, they can
easily be changed to floats.
Also add a "Wait for Cursor" option similar to the one for some built-in
operators that delay's the operator's execution until there is a mouse
click in the viewport. That way the operator can be called from menus
even though it is interactive. This option is placed in the node editor
header. When there are more options, it will be part of an "Options"
popover panel similar to the existing "Modes" and "types" popovers.
Combined with the viewport transform node, and other nodes like Raycast,
these features can allow making tools that create geometry where you
click in the scene.
Pull Request: https://projects.blender.org/blender/blender/pulls/121043
Add a node that outputs the transform of the viewport relative to the
self object's transform. This node can be used to build effects like
billboarding or aligning geometry to the current view. In combination
with the mouse position node in the future it will allow tools like
generating geometry at the mouse click position.
There are two output matrices. The first is the projection matrix
that takes positions in camera space and applies the final perspective
projection. The other is the "view" matrix which contains the location
and rotation of the camera. These are separate because though their
combination is useful, it isn't used like a typical rotation/transform matrix.
Pull Request: https://projects.blender.org/blender/blender/pulls/118680
With the matrix socket being introduced into geometry nodes, we
are starting to deal with more complex transforms like perspective
projection. For those matrices projecting a point is not as simple
as just matrix multiplication, there has to be an additional normalization
step after. To solve that in an intuitive way consistent with how it's
typically solved in code, add a new "Project Point" node.
The canonical use case for now is in combination with the mouse
position, viewport transform, and raycast nodes, to find where the
mouse clicked on the edited geometry.
Pull Request: https://projects.blender.org/blender/blender/pulls/120597
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 goal is to support better search experience in the cases where we want to
explicitly influence the ordering instead of relying only on general heuristics.
We used to support this already at some point I think, but not anymore since we
started using menu-search.
The implementation is fairly straight forward. It mainly just forwards the
search weight from the menu definition to the search code through various
required steps. The main annoying thing is that changing the signature of e.g.
`uiItemFullO_ptr` is fairly involved. Even using default parameters for these
functions is a bit annoying and becomes fairly unreadable and error-prone on the
call-site. For now, I worked around this by storing the search weight on the
`uiLayout` and to copy it to the `uiBut` from there. That seems preferable until
we have a better solution for adding parameters to all the `uiItem*` functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/120572
Adds two nodes as "grid" equivalents to the existing volume nodes:
- **Grid to Mesh**
- **Distribute Points in Grid**
The code for the latter is just duplicated for now. In a later step
old node can be replaced by versioning with two new nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/118830
This simple node finds the values of a volume grid at
positions in the local space used in geometry nodes
evaluation. There are three interpolation modes to
choose how to mix values between neighboring voxels.
For the implementation, first the values are sampled
with the grid's type directly, then implicit type conversions
are used to get the final type. This makes gives us flexibility
in case there aren't exact matches in support between grid
types and Blender types.
Pull Request: https://projects.blender.org/blender/blender/pulls/118397
Implements the design from #116067.
The socket type is called "Matrix" but it is often referred to as "Transform"
when that's what it is semantically. The attribute type is "4x4 Matrix" since
that's a lower level choice. Currently matrix sockets are always passed
around internally as `float4x4`, but that can be optimized in the future
when smaller types would give the same behavior.
A new "Matrix" utilities category has the following set of initial nodes"
- **Combine Transform**
- **Separate Transform**
- **Multiply Matrices**
- **Transform Direction**
- **Transform Vector**
- **Invert Matrix**
- **Transpose Matrix**
The nodes and socket type are behind an experimental flag for now,
which will give us time to make sure it's the right set of initial nodes.
The viewer node overlay doesn't support matrices-- they aren't supported
for rendering in general. They also aren't supported in the modifier interface
currently. But they are supported in the spreadsheet, where the value is
displayed in a tooltip.
Pull Request: https://projects.blender.org/blender/blender/pulls/116166
In 4.1 we deprecate the `Rotate Euler` node in favor of the `Rotate Rotation`
node which uses the new rotation socket type. The node is not removed
(for now) because that would come with compatibility issues. More generally,
we'll likely run into the situation where nodes are deprecated more often in the
future, without actually removing them to keep compatibility. This patch improves
how such nodes are handled in the UI.
The patch does three things:
* Adds a new `Utilities > Deprecated` entry in the add node menu in geometry nodes.
* Moves search items which are deprecated to the bottom in the search results
(currently, this only works in English, can be fixed in bcon3).
* Adds a new `bNodeType->deprecation_notice` that will result in a deprecation
warning when the node is used.
Pull Request: https://projects.blender.org/blender/blender/pulls/117905
This is meant as a replacement for the Rotate Euler node. Overall it
should be more performant, and the clarity given by the separate socket
type should help distinguish its purpose.
The Rotate Euler node is removed from search and the add menu by this
commit. In the future it can be versioned away. That isn't done now to
avoid a breaking API change and to make this commit less risky.
Pull Request: https://projects.blender.org/blender/blender/pulls/116106
This patch adds support for _Menu Switch_ nodes and enum definitions in
node trees more generally. The design is based on the outcome of the
[2022 Nodes Workshop](https://code.blender.org/2022/11/geometry-nodes-workshop-2022/#menu-switch).
The _Menu Switch_ node is an advanced version of the _Switch_ node which
has a customizable **menu input socket** instead of a simple boolean.
The _items_ of this menu are owned by the node itself. Each item has a
name and description and unique identifier that is used internally. A
menu _socket_ represents a concrete value out of the list of items.
To enable selection of an enum value for unconnected sockets the menu is
presented as a dropdown list like built-in enums. When the socket is
connected a shared pointer to the enum definition is propagated along
links and stored in socket default values. This allows node groups to
expose a menu from an internal menu switch as a parameter. The enum
definition is a runtime copy of the enum items in DNA that allows
sharing.
A menu socket can have multiple connections, which can lead to
ambiguity. If two or more different menu source nodes are connected to a
socket it gets marked as _undefined_. Any connection to an undefined
menu socket is invalid as a hint to users that there is a problem. A
warning/error is also shown on nodes with undefined menu sockets.
At runtime the value of a menu socket is the simple integer identifier.
This can also be a field in geometry nodes. The identifier is unique
within each enum definition, and it is persistent even when items are
added, removed, or changed. Changing the name of an item does not affect
the internal identifier, so users can rename enum items without breaking
existing input values. This also persists if, for example, a linked node
group is temporarily unavailable.
Pull Request: https://projects.blender.org/blender/blender/pulls/113445
This is the initial implementation for the volume grid sockets that has been
discussed during the November 2023 geometry nodes workshop.
It adds initial support for passing volume grids around in sockets. Furthermore,
it adds two new nodes. Both are initially hidden under the "New Volume Nodes"
experimental option until we have a few mode nodes.
* **Get Named Grid**: Gets or extracts a volume grid from a volume geometry
based on the grid's name.
* **Store Named Grid**: Puts a volume grid back into a volume with a name.
`SocketValueVariant` is extended to support grids besides single values and fields.
Next steps:
* Implement grid socket shape and inferencing (currently, they just look like
single values).
* Add implicit conversions between grid types.
* Implement nodes that operate on the grids (#116021).
* Improved spreadsheet and viewer support.
Links:
* https://devtalk.blender.org/t/volumes-in-geometry-nodes-proposal/31917
* https://devtalk.blender.org/t/2023-11-06-geometry-nodes-workshop-notes/32007#volumes-3
Co-authored-by: Jacques Lucke <jacques@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/115270
This adds a new `Bake` node which allows saving and loading intermediate geometries.
Typical use cases we want address with this currently are:
* Bake some data for use with a render engine.
* Bake parts of the node tree explicitly for better performance.
For now, the format that is written to disk is not considered to be an import/export format.
It's not guaranteed that data written with one Blender version can be read by another
Blender version. For that it's better to use proper interchange formats. Better support for
those will be added eventually as well. We also plan an `Import Bake` node that allows
reading the blender-specific baked data independent of the Bake node and at different frames.
The baking works very similar to the baking in the simulation zone (UI and implementation
wise). Major differences are:
* The Bake node has a `Bake Still` and `Bake Animation` mode.
* The Bake node doesn't do automatic caching.
Implementation details:
* Refactored how we create the Python operators for moving socket items so that it also
makes sense for non-zones.
* The `ModifierCache` stores an independent map of `SimulationNodeCache` and
`BakeNodeCache`, but both share a common data structure for the actually baked data.
* For baking, the `Bake` node is added as a side-effect-node in the modifier. This will make
sure that the node is baked even if it's currently not connected to the output.
* Had to add a new `DEG_id_tag_update_for_side_effect_request` function that is used
during baking. It's necessary because I want to evaluate the object again even though none
of its inputs changed. The reevaluation is necessary to create the baked data. Using
`DEG_id_tag_update` technically works as well, but has the problem that it also uses the
`DEG_UPDATE_SOURCE_USER_EDIT` flag which (rightly) invalidates simulation caches
which shouldn't happen here.
* Slightly refactored the timeline drawing so that it can also show the baked ranges of
Bake nodes. It does not show anything for baked nodes with a in Still mode though.
* The bake operator is refactored to bake a list of `NodeBakeRequest` which makes the
code easier to follow compared to the previous nested
`ObjectBakeData > ModifierBakeData > NodeBakeData` data structure.
* The bake operators are disabled when the .blend file is not yet saved. This is technically
only necessary when the bake path depends on the .blend file path but seems ok to force
the user anyway (otherwise the bake path may be lost as well if it's set explicitly).
* The same operators are used to bake and delete single bakes in `Bake` nodes and
`Simulation Zones`. On top of that, there are separate operators of baking and deleting all
simulation bakes (those ignore bake nodes).
* The `Bake` node remembers which inputs have been fields and thus may be baked as attributes.
For that it uses an `Is Attribute` flag on the socket item. This is needed because the baked data
may still contain attribute data, even if the inputs to the bake node are disconnected.
* Similar to simulation zones, the behavior of `Bake` nodes is passed into the geometry nodes
evaluation from the outside (from the modifier only currently). This is done by providing the
new `GeoNodesBakeParams` in `GeoNodesCallData` when executing geometry nodes.
Next Steps (mostly because they also involve simulations):
* Visualize nodes that have not been evaluated in the last evaluation.
* Fix issue with seemingly loosing baked data after undo.
* Improve error handling when baked data is not found.
* Show bake node in link drag search.
* Higher level tools for managing bakes.
Pull Request: https://projects.blender.org/blender/blender/pulls/115466
