This removes the "Geometry" part from their name because we want to use them in
other node tree types too (see #141936).
Usually, we don't change idnames because they are the primary identifier of
nodes and is expected to stay the same. Since they are generally not shown to
users (just Python developers), it's also not urgent to change them. However, in
this specific case we have the opportunity to update the idname before the node
becomes an official feature, so it's not as bad to change it.
This patch has full backward compatibility, but no forward compatibility (for
files that used the experimental feature).
Pull Request: https://projects.blender.org/blender/blender/pulls/143823
This includes a new list structure type and socket shape, a node
to create lists, a node to retrieve values from lists, and a node to
retrieve the length of lists. It also implements multi-function support
so that function nodes work on lists.
There are three nodes included in this PR.
- **List** Creates a list of elements with a given size. The values
are computed with a field that can use the index as an input.
- **Get List Item** A field node that retrieves an element from a
a list at a given index. The index input is dynamic, so if the input
is a list, the output will be a list too.
- **List Length** Just gives the length of a list.
When a function node is used with multiple list inputs, the shorter
lists are repeated to extend it to the length of the longest.
The list nodes and structure type are hidden behind an experimental
feature until we can be sure they're useful for an actual use case.
Pull Request: https://projects.blender.org/blender/blender/pulls/140679
Geometry Nodes' Add > Input > Import menu includes file format items
such as "Standford PLY (.ply)", "STL (.stl)", "Text (.txt)". The
latter needs to be translated because "Text" is a generic format.
These items are declared using a custom function
`node_add_menu.add_node_type`, with a `label` argument. This commit
adds the `label` argument to the function arguments that can be
extracted from specific node declaration functions, and specifies the
argument position for each:
"add_node_type", "add_node_type_with_outputs", "add_simulation_zone",
"add_repeat_zone", "add_foreach_geometry_element_zone",
"add_closure_zone".
There is currently no facility to specify a translation context but it
could be easily added if the need arises.
Most of these functions do not actually declare new, unique messages,
but it could happen in the future. In addition, two messages were
extracted using manual `iface_()` calls, which are no longer needed
after this change.
Reported by Ye Gui in #43295.
It is generally expected that items within the same section in the Node
Add menu appear in alphabetical order.
However, certain handful of places in the different node editor menus
don't seem to follow this convention. This patch simply re-arranges the
items in some places to follow alphabetical order.
Pull Request: https://projects.blender.org/blender/blender/pulls/140070
This adds a new Format String node which simplifies constructing strings from
multiple values. The node takes a format string and a dynamic number of
additional parameters as input. The format string determines how the other
inputs are inserted into the string. Only integer, float and string inputs are
supported for now.
It supports two different format syntaxes:
* Python compatible format syntax which also mostly matches the behavior of the
`fmt` C++ library. Most of this is supported, but there are some small
limitations.
* Syntax of the form `###.##` where each `#` stands for a digit. This is the
syntax that was introduced in #134860.
This node greatly simplifies common string operations which would have required
potentially many nodes before to convert numbers to strings and to concatenate
them. It also makes new conversions possible that were not supported before.
This node can also be used to insert e.g. frame numbers into a file path which
was surprisingly complex before.
This node has special behavior for the name of new inputs. For the purpose of
the node, the name of the inputs must be valid identifiers and it's usually
helpful when they are short. New names are therefore initialized to be single
characters. If possible, the first character of the linked input is used. This
works well when connecting e.g. a Separate Vector/Color node. Otherwise, inputs
are named `a` to `z` by default. If that's not possible, the source socket name
is used instead (converted to be a valid identifier). If that still doesn't
work, the name is made unique using the normal `.001` mechanism except that `_`
instead of `.` is used as separator to make the name a valid identifier.
Python Syntax references:
* Python: https://docs.python.org/3/library/string.html#formatspec
* `fmt`: https://fmt.dev/latest/syntax/
More detailed notes about compatibility with the above syntax specifications:
* Conversion using e.g. `!r` like in Python is not supported (maybe the future).
* Sub-attribute access like `{vector.x}` is not supported (maybe the future).
* Using `%` like in Python is not supported (maybe in future).
* Using `#` for an alternate form is not supported. This might help in the
future to make the syntax compatible with #134860.
* Using `L` like in the `fmt` library is not supported because it depends on the
locale which is not good for determinism.
* Grouping with e.g. thousands separators using e.g. `,` or `_` like in Python
is not supported (maybe in future). Need to think about the locale here too.
* Mixing of unnamed (`{}`) and named (`{x} or {0}`) specifiers is allowed.
However, all unnamed specifiers must come before any named specifier.
The implementation uses the `fmt` library for the actual formatting. However,
the inputs are preprocessed to give us more control over the exact supported
syntax and error messages. The code is already somewhat written so that many
strings could be formatted with the same format but that's not actually used yet
because we don't have string fields yet.
Error messages are propagated using a new mechanism that allows a limited form
of error propagation from multi-functions to the node that evaluates them.
Currently, this only works in fairly limited circumstances, e.g. it does not
work during field evaluation. Since this node is never part of field evaluation
yet, that limitation seems ok, but it's something to work on at some point.
Properly supporting that requires some more changes to propagate enough context
information everywhere. Also showing errors of field evaluation on the field
node itself (instead of on the evaluation node) requires even more work because
our current logging system is not setup to support that yet.
This node comes with a few new requirements for the socket items system: names
must be valid identifiers and they are initialized in a non-trivial way.
Overall, this was fairly straight forward to implement but currently it requires
to adding a bunch of new members to all the accessors that don't really need it.
This is something that we should simplify at some point even if I'm not entirely
sure how yet. The same new requirements used in this node would probably also
exist in a potential future expression node.
Pull Request: https://projects.blender.org/blender/blender/pulls/138860
Previously, one had to search for the name of an input node (Geometry, Light
Path, etc.) instead of for the actual desired values.
This patch makes it possible to search for the output names of various input
nodes directly. All other outputs of the input node are hidden automatically.
This was partially support for the Scene Time before.
Supported nodes:
* Compositor: Scene Time
* Geometry Nodes: Camera Info, Mouse Position, Scene Time, Viewport Transform
* Shader Nodes: Camera Data, Curves Info, Geometry, Volume Info, Light Path,
Object Info, Particle Info
Right now, the output names are hardcoded in the menu. We don't have a great way
to access those without an actual node instance currently. For that we'll need
to make the node declarations available in Python, which is a good project but
out of scope for this this feature. It also does not seem too bad to have more
explicit control over what's shown in the search.
Pull Request: https://projects.blender.org/blender/blender/pulls/139477
How solid/faded the edges of a Grease Pencil stroke is
controlled by the `softness` attribute. This change adds a
node that exposes that attribute, allowing the user to
control it via Geometry Nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/138939
This adds a new Bit Math node which supports the following operations: `and`,
`or`, `xor`, `not`, `shift` and `rotate`.
For the `shift` and `rotate` operations, a posititive shift is a left shift and
a negative shift is a right shift.
Currently, the node always works on 32-bit integers which is what Geometry Nodes
uses internally for integers. If required, this can be extended to work on other
bit widths in the future.
The need for this came up every now and then. It can be useful when encoding
specific bits in integer attributes (for efficiency or because the geometry is
exported to other software that expects a certain format). Also, this node is
useful for some people doing crazy but fun things with Geometry Nodes like
emulating hardware. Even if the use-cases are not common, if they arise, it's
hard to work around and the cost of having this node is quite low for us.
Co-authored-by: Charlie Jolly <charliejolly@noreply.localhost>
Pull Request: https://projects.blender.org/blender/blender/pulls/138290
Previously, one had to search for "Time" to get the Scene Time node which
provides access to the current frame and second. Intuitively I often start
searching for "frame" or "seconds" instead and only later remember what I
actually have to search for.
This patch improves the UX by allowing to create a Scene Time node by searching
for "frame" or "seconds" directly. This works in Geometry Nodes and the
compositor.
Pull Request: https://projects.blender.org/blender/blender/pulls/138927
The current behavior for the Node Editor's Add menu is to list the
user's asset catalogs at the root level of the menu. However, an
exception is made if the catalog has the same name as a builtin menu.
In such case, the asset catalog is appended to that builtin menu,
instead of being drawn at the root level.
How this is currently implemented right now is to have a hard-coded set
of builtin menus in `add_menu_assets.cc`. Certain menus are missing from
this set, particularly newer ones, which may be an oversight during the
creation of these menus.
This patch adds those menus to that list, which are as follows:
- Input/Gizmo
- Input/Import
- Grease Pencil (and all its submenus)
- Texture (in Compositor Nodes)
Pull Request: https://projects.blender.org/blender/blender/pulls/138870
These are generic properties of grids (not stored in voxels) which are
useful to know in geometry nodes. The transform in particular defines
the voxel size. Background value is used outside of active voxels.
Pull Request: https://projects.blender.org/blender/blender/pulls/138592
Previously, it was possible to search for specific math operations in
link-drag-search but not in the normal add menu. This patch adds support for
searching for specific operations in various math nodes.
A good trick for adding e.g. a vector add node is to search for `vadd`
(similarly with `iadd`).
The menu itself looks unchanged. This patch only adds additional elements to the
search.
Pull Request: https://projects.blender.org/blender/blender/pulls/138534
This adds an Import VDB node. It loads all the grids from a .vdb file and hence
outputs a Volume geometry instead of an individual grid.
The grids are cached through the existing volume grid file cache, so they are
automatically deduplicated when volume grids are loaded from files in other
ways.
Pull Request: https://projects.blender.org/blender/blender/pulls/138380
This adds a new Instance Bounds nodes which provides an easy and
efficient way to get the bounding box of each instance.
Nested instances or not taken into account to compute the bounding
box. That would result in a major performance degredation because
one would have to basically realize all instances to do that.
Also see #135933 for some examples.
Pull Request: https://projects.blender.org/blender/blender/pulls/135933
Adds field versions of the operations from Attribute Statistic, can
support grouping via Group IDs. These operations are added as separate
nodes: `Field Average`, `Field Min & Max`, & `Field Variance` which
group the different statistic operations according to their use.
Supported Data Types:
- Field Average - (Float, Vector)
- Field Min & Max - (Float, Integer, Vector)
- Field Variance - (Float, Vector)
Pull Request: https://projects.blender.org/blender/blender/pulls/134640
The capitals were only used for API compatibility when the add menu
was first added, they're not needed for new menus. Better to avoid
since they're non-standard for menu names.
Adds a new node to set the Grease Pencil depth ordering.
Here are the options:
* 2D Layers: Uses the Layer order + Stroke order to calculate the depth ordering.
* 3D Location: Uses the 3D position of the points as the depth.
This reflects the same setting that is available in the Grease Pencil
object-data properties.
The node is added to the `Grease Pencil` > `Write` menu.
Resolves#129458.
Pull Request: https://projects.blender.org/blender/blender/pulls/135914
Adds a new `Set Grease Pencil Color` node.
It was already possible to write to the color and opacity attributes using the
`Store Named Attribute` node, but this required the user to know the names
of the "built in" attributes.
Similar to how we can set other built-in attributes (e.g. the curve radius) this
adds a node to write to the following Grease Pencil attributes:
* `vertex_color` (point domain): The color of a point (the alpha value is used
as a mix factor with the base material color).
* `opacity` (point domain): The opacity of a point.
* `fill_color` (curve domain): The fill color of a stroke (the alpha value is used
as a mix factor with the base material color).
* `fill_opacity` (curve domain): The fill opacity of a stroke.
For consistency with other nodes, there is a mode to switch between writing
to the points (`Stroke` mode) and the fills (`Fill` mode).
Pull Request: https://projects.blender.org/blender/blender/pulls/136260
Add a "dumb vector" storage option for custom normals, with the
"custom_normal" attribute. Adjust the mesh normals caching to
provide this attribute if it's available, and add a geometry node to
store custom normals.
## Free Normals
They're called "free" in the sense that they're just direction vectors
in the object's local space, rather than the existing "smooth corner
fan space" storage. They're also "free" in that they make further
normals calculation very inexpensive, since we just use the custom
normals instead. That's a big improvement from the existing custom
normals storage, which usually significantly decreases
viewport performance. For example, in a simple test file just storing
the vertex normals on a UV sphere, using free normals gives 25 times
better playback performance and 10% lower memory usage.
Free normals are adjusted when applying a transformation to the entire
mesh or when realizing instances, but in general they're not updated for
vertex deformations.
## Set Mesh Normal Node
The new geometry node allows storing free custom normals as well as
the existing corner fan space normals. When free normals are chosen,
free normals can be stored on vertices, faces, or face corners. Using
the face corner domain is necessary to bake existing mixed sharp and
smooth edges into the custom normal vectors.
The node also has a mode for storing edge and mesh sharpness, meant
as a "soft" replacement to the "Set Shade Smooth" node that's a bit
more convenient.
## Normal Input Node
The normal node outputs free custom normals mixed to whatever domain is
requested. A "true normal" output that ignores custom normals and
sharpness is added as well.
Across Blender, custom normals are generally accessed via face and
vertex normals, when "true normals" are not requested explicitly.
In many cases that means they are mixed from the face corner domain.
## Future Work
1. There are many places where propagation of free normals could be
improved. They should probably be normalized after mixing, and it
may be useful to not just use 0 vectors for new elements. To keep
the scope of this change smaller, that sort of thing generally isn't
handled here. Searching `CD_NORMAL` gives a hint of where better
propagation could be useful.
2. Free normals are displayed properly in edit mode, but the existing
custom normal editing operators don't work with free normals yet.
This will hopefully be fairly straightforward since custom normals
are usually converted to `float3` for editing anyway. Edit mode
changes aren't included here because they're unnecessary for the
procedural custom normals use cases.
3. Most importers can probably switch to using free normals instead,
or at least provide an option for it. That will give a significant
import performance improvement, and an improvement of Blender's
FPS for imported scenes too.
Pull Request: https://projects.blender.org/blender/blender/pulls/132583
This implements bundles and closures which are described in more detail in this
blog post: https://code.blender.org/2024/11/geometry-nodes-workshop-october-2024/
tl;dr:
* Bundles are containers that allow storing multiple socket values in a single
value. Each value in the bundle is identified by a name. Bundles can be
nested.
* Closures are functions that are created with the Closure Zone and can be
evaluated with the Evaluate Closure node.
To use the patch, the `Bundle and Closure Nodes` experimental feature has to be
enabled. This is necessary, because these features are not fully done yet and
still need iterations to improve the workflow before they can be officially
released. These iterations are easier to do in `main` than in a separate branch
though. That's because this patch is quite large and somewhat prone to merge
conflicts. Also other work we want to do, depends on this.
This adds the following new nodes:
* Combine Bundle: can pack multiple values into one.
* Separate Bundle: extracts values from a bundle.
* Closure Zone: outputs a closure zone for use in the `Evaluate Closure` node.
* Evaluate Closure: evaluates the passed in closure.
Things that will be added soon after this lands:
* Fields in bundles and closures. The way this is done changes with #134811, so
I rather implement this once both are in `main`.
* UI features for keeping sockets in sync (right now there are warnings only).
One bigger issue is the limited support for lazyness. For example, all inputs of
a Combine Bundle node will be evaluated, even if they are not all needed. The
same is true for all captured values of a closure. This is a deeper limitation
that needs to be resolved at some point. This will likely be done after an
initial version of this patch is done.
Pull Request: https://projects.blender.org/blender/blender/pulls/128340
This adds a new Camera Info node to Geometry Nodes. It provides information
about the passed in camera like its projection matrix and focus distance.
This can be used for camera culling which was must more complex before.
It also allows building other view-dependent effects.
Pull Request: https://projects.blender.org/blender/blender/pulls/135311
The import nodes are considered complete enough to expose without
the experimental option. This commit removes the option so they will
be exposed in 4.5. There are still some possible future improvements,
including automatic caching, possibly exposing more input sockets,
and possibly including imported paths in the "Internal Dependencies"
panel. Those are considered non blocking though.
Pull Request: https://projects.blender.org/blender/blender/pulls/135957
As a small addition to the import node features for 4.5,
this simple node imports a text file as a string. Potential
use cases include retrieving text for motion graphics.
Currently this just allows .txt files. More extensions could
be allowed in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/135459
Add a node that finds the number of times a substring occurs in a string,
and the position of the start of the first match.
See the PR description for more rational and details.
Pull Request: https://projects.blender.org/blender/blender/pulls/129270
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
