This catches the exception and shows the error message to the user.
We don't have much control over the error message here currently. Better just
report it for now. In the future we could try to detect what error it is exactly
and produce a more user friendly error.
This was broken by 8027720e51 because
we forget to update the label in the declaration.
This is now reverted for the Mesh Line node, because there is no way to
change the label in the declaration yet. A new patch can be created that properly
updates the Mesh Line node to use the declaration.
Implements the design from #120318. The existing selection nodes now have
the ability to deal with float/soft selection. For meshes the soft selection
corresponds to the inverse of the sculpt mask attribute. In the future this
will likely be unified with edit mode selection a bit more which is why
this design was chosen compared to separating masking and selection.
Curves and point clouds already use a single selection attribute with
either data type.
Pull Request: https://projects.blender.org/blender/blender/pulls/126316
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
The material handling on curves was not super strong yet because there was not a
lot of need for it. However, now with Grease Pencil it's much more likely that
material selections are used on curves.
The patch is larger than one might expect at first, because we have to pass more
information into the field context in many places, because the materials are
stored on `Curves` and not `CurvesGeometry`.
Related to #128109.
Pull Request: https://projects.blender.org/blender/blender/pulls/128182
This improve the API in multiple aspects:
* No need for an additional `lookup` call to get the current attribute. This
would internally iterate over all attributes again. This leads to O(n^2)
behavior. Note that there are still other reasons for O(n^2) behavior when
processing attributes (where n is the number of attributes).
* Remove the need to return a value from the iteration code to indicate that the
iteration should continue. This is now the default behavior. The iteration can
still be stopped by calling `iter.stop()`.
* Easier access to `is_builtin` property.
* Iterator callback only has a single parameter instead of two (of which one is
sometimes unused).
Pull Request: https://projects.blender.org/blender/blender/pulls/128128
Adds support for the "Menu" socket type in for-each-element zones. This
only includes field inputs and their matching per-element values, but
not outputting attributes of type Menu (Menu attributes are not
generally supported at this point).
A dedicated enum propagation function is added for the zone input node.
This isn't technically necessary: the first 2 inputs and outputs should
be ignored but are not menus anyway. However, this is clearer and
provides a place for future changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/128106
The View matrix isn't really the direction and location of the viewport,
it's the opposite, since it transforms object space into camera space.
Change both tooltips to state the change of transform space instead
of using nouns to try to describe what they "are".
Pull Request: https://projects.blender.org/blender/blender/pulls/124741
For most cases where the iteration index is needed, a For Each zone is the
better than using a Repeat zone. It's easier to use and more optimizable.
However, in some cases a Repeat zone is actually the right solution and the
index often useful in such cases too.
Pull Request: https://projects.blender.org/blender/blender/pulls/127521
This makes the input field much wider. I enabled this for most string sockets
except for a few where it is important to see the label even if the user has
inserted a string already (usually because there is more than one string input).
Pull Request: https://projects.blender.org/blender/blender/pulls/127992
This refactor changes many nodes to set socket availability in the node
declaration instead of using the more generic `bNodeType::updatefunc`.
This fixes issues where sockets that should be unavailable in evaluated data are
actually available. Also it moves us closer to a state where the generic update
function is not necessary anymore. The update function being so generic makes it
hard to integrate it well into the high level tree update code, because
"anything could happen" in that callback.
Pull Request: https://projects.blender.org/blender/blender/pulls/127845
It is too easy to accidentally enable skipping the simulation while moving the
node around without noticing. Now it is necessary to pass in a boolean value
from another node to modify the skip value. Existing files that had this
checkbox checked are updated by versioning code.
This implements #127506.
Pull Request: https://projects.blender.org/blender/blender/pulls/127988
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
Integrate an existing implementation of the SLIM unwrapping algorithm
into Blender. More info about SLIM here:
https://igl.ethz.ch/projects/slim/
This commit is based on the integration code written by Aurel Gruber
for Blender 2.7x (unfinished and never merged with the main branch).
This commit is based on Aurel's code, rebased and further improved.
Details:
- Unwrap has been moved into a sub-menu,
slim unwrapping is exposed as: "Minimum Stretch".
- Live unwrap with SLIM refines the solutions using a timer.
- When using SLIM there are options to:
- Set the number of iterations.
- Weight the influence using vertex weights.
- SLIM can be disabled using the `WITH_UV_SLIM` build option.
Co-authored-by: Aurel Gruber <aurel.gruber@infix.ch>
Ref !114545
Previously, it was only possible to bake to disk with geometry nodes. This patch
adds support for storing the baked data directly in the .blend file.
By default, new bakes are stored in the .blend file now. Whether a new bake
should be packed or stored on disk can be configured in two places: in the
properties of the bake node and in the bake panel of the modifier. These
settings don't affect existing bakes, only the next bake.
To unpack or pack an individual bake, there is a new operator button next to the
bake button. The icon and the label below indicate where the bake is currently
stored. The label now also contains the size of the bake.
To unpack or pack all bakes, the `File > External Data > Pack Resources / Unpack
Resources` operators can be used. The unpack operator also has a new title that
mentions the number if individual files separate from the number of bakes. This
works better than just listing a number of files because a bake can consist of
many files.
Pull Request: https://projects.blender.org/blender/blender/pulls/124230
This adds support for line separators in nodes. Currently this is only available for
built-in nodes and it's only used in the Simulation Zone. However, we also want
to use it in the For Each Geometry Element zone (#127331). Support for node groups
can be added separately too.
Pull Request: https://projects.blender.org/blender/blender/pulls/127501
The issue is that the boolean node did not propagate edit data and thus lost
information about gizmos. Now the boolean node propagates edit data from
all geometry inputs.
Pull Request: https://projects.blender.org/blender/blender/pulls/127457
This exposes warnings that are propagated to the modifier in the Python API.
This allows people to show these warnings in custom UIs for their node groups.
Warnings are accessed like this:
```python
for warning in modifier.node_warnings:
print(warning.message)
print(warning.type)
```
Note that this only works on the geometry nodes modifier. These warnings may
be extended with more information in the future. E.g. it could be useful to know
which node created the warning.
Pull Request: https://projects.blender.org/blender/blender/pulls/127193
This introduces the concept of an #AttributeFilter. It's used to tell a geometry
algorithm which attributes it should process/propagate and which can be ignored.
We already had something similar before named
`AnonymousAttributePropagationInfo`. However, as the name implies, this was
specific to anonymous attributes. This had some downsides:
* A lot of code had to be aware of the concept of anonymous attributes even if
it did nothing special with anonymous attributes.
* For non-anonymous attributes we often had a separate `Set<std::string> skip`
parameter. It's not nice to have to pass two kinds of filters around and to
have to construct a `Set<std::string>` in many cases.
`AttributeFilter` solves both of these downsides.
Technically, `AttributeFilter` could also just be a `FunctionRef<bool(StringRef
attribute_name)>`, but that also has some issues:
* The `bool` return value is often ambiguous, i.e. it's not clear if it means
that the attribute should be processed or not. Using an enum works better.
* Passing function refs around and combining them works, but can very easily
lead to dangling references.
* The default value of a `FunctionRef` is "empty", i.e. it can't be called. It's
generally more nice to not have a special case for the default value. Now the
default `AttributeFilter` propagates all attributes without any extra handling
on the call-site.
Pull Request: https://projects.blender.org/blender/blender/pulls/127155
Previously, the `AttributeIDRef` wrapper was needed because it also had to
contain a pointer to an `AnonymousAttributeID`. However, since
b279a6d703 this is not necessary anymore.
Therefore we can use "raw" `StringRef` now which reduces the mental overhead
when working with attributes and also simplifies code.
Pull Request: https://projects.blender.org/blender/blender/pulls/127140
In some cases when there are no faces there are no corner domain
topology attributes. Though this could be changed theoretically,
it's simpler to just make sure they exist in the few places we resize
a mesh rather than creating a new one from scratch.
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
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
Use snake style naming for all the kernel nodes functions.
Omit kernel prefix in the names since of the using namespace.
Use full forms of the terms
('iter' -> 'iterator', 'ntree' -> 'node_tree', 'rem' -> 'remove', ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/126416
Just turn on the option for geometry nodes where attributes are
generally expected to be used. We could expose this and other
options at some point too but that requires a bit more thought.
This adds the ability to customize the default width of a group node that's
created for a node group. This feature works towards the goal of unifying the
features available to built-in nodes and node groups. We often customize the
width of built-in nodes from them to looks slightly better (e.g. to avoid
cut-off labels).
Pull Request: https://projects.blender.org/blender/blender/pulls/126054
When a curve instance did not have a "opacity" attribute, the default would be 0.
This meant that when creating Grease Pencil layers from scratch, the user
would need to manually write a "opacity" attribute.
Now the default value is 1, so that this step is no longer necessary.
The specialized code for converting grease pencil layer attributes to
instance attributes was accessing the instance component without check.
This _should_ work because the component is explicitly created, but
still fails for empty grease pencil data, because the
`get_component_ptr` function checks if the component is "empty" as well
(zero instances).
Pull Request: https://projects.blender.org/blender/blender/pulls/125887
Bake nodes are not supported in a repeat zone. They used to just output
default values when used in a repeat zone, but now they just pass-through
the inputs like an unbaked bake node would.
This makes the behavior more like one would expect when using the same
node group in and outside of a repeat zone that happens to have a bake
node inside (which is not even used).
