The length modifier was not handling 2 point curves correctly.
This change does two things:
1) Fix the crash by copying the original indices for 2 point curves into `dst_to_src_point`.
2) Fallback to `extend_curves_straight` for extending 2 point curves.
Pull Request: https://projects.blender.org/blender/blender/pulls/130122
Previously, some places used `curves.points_num() == 0` some other
places `curves.curves_num() == 0` to check if the geometry is empty.
Rather than having these two ways, add an `is_empty()` function
that replaces all these different checks.
Also update the curves geometry tests to use this function.
Pull Request: https://projects.blender.org/blender/blender/pulls/130168
In `execute_realize_grease_pencil_tasks` we create a new `GreasePencil`
but don't copy the parameters of (one of) the source grease pencils.
The fix adds `BKE_grease_pencil_copy_parameters` to copy the parameters
of the last src grease pencil.
Note: `BKE_grease_pencil_copy_parameters` copies the materials array. We
might want to remove this and always do the copy of this using a separate
function because some callers need their own way of copying them.
Pull Request: https://projects.blender.org/blender/blender/pulls/129977
Interpolating these attributes as integer values isn't meaningful or
helpful and is potentially problematic. So far I'd guess this is unlikely
to happen in practice which is why it probably hasn't been noticed yet.
Fixes part of #129691.
Pull Request: https://projects.blender.org/blender/blender/pulls/129809
Only retrieve a mutable copy of the attribute if we're actually able to change it.
If topology changes and there are no IDs, we can't mix the attribute and we
should avoid retrieving it in case it's shared. This is more of a hypothetical
change, I didn't actually observe a real world performance change.
Pull Request: https://projects.blender.org/blender/blender/pulls/129811
The 4x4 matrix type has a larger alignment requirement of 16 bytes
than the default, but it was stored in a generic vector of bytes. There
are a few solutions that reduce the memory reuse in this code path--
the chosen solution uses a custom allocator which always allocates
with an alignment that should be large enough for anything.
Generally I think this resampling loop could be rewritten to be a bit
simpler, avoiding these problems in the first place. Some performance
testing would show whether this "fancy" memory use between types
and loop structure is actually worth it. For now though, just correcting
the existing logic seems like the best choice.
Pull Request: https://projects.blender.org/blender/blender/pulls/129628
Unwrapping warned that a non 0/1 boolean value was being set.
Initialize all members of PVert since they would be accessed
when duplicating a PVert causing the uninitialized memory to be read.
This makes it so the stroke selection is taken into account by the
interpolation tool.
This does NOT use the selection _order_, just limits interpolation by
index to the selection. The result will be the subset of selected
strokes, excluding non-selected strokes, which is closer to the GPv2
behavior.
The `sample_curve_attribute` function was using the target curve index
for both the src and dst curves. This worked when all the curves are
interpolated, but with selections the dst curve is generally not the
same index as the src curve. The `from_curve_indices` array must be
passed along as well to retrieve the correct source index.
Pull Request: https://projects.blender.org/blender/blender/pulls/129096
The issue was that the `merge_layers` function assumed that the
`src_grease_pencil` always returns a drawing when calling
`get_eval_drawing` which can return `nullptr`.
The fix makes sure to check that the `src_drawing` exists.
Pull Request: https://projects.blender.org/blender/blender/pulls/129074
This fixes#127629. It's still a bit slower than it used to be when there are
lots of instances, but that fixes the main bottleneck that was introduced in
#116582. The issue was that we iterated over all attributes of all instances,
but it should only be necessary to iterate over the instances of each unique
geometry only once.
There is still quite some optimization potential in the Realize Instances code
for the case when realizing lots of instances. Especially the code to gather all
geometries that should be realized can still be made more efficient by reducing
redundant work and using multi-threading.
Pull Request: https://projects.blender.org/blender/blender/pulls/128699
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
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 when there was a single mesh/curve/point cloud/grease pencil
input, the code would still do a deep copy of the entire geometry. Not
only does this waste time and memory usage, it also inhibits the
benefits of the shared cache system, causing normals and other derived
data to be recalculated more than necessary.
This commit makes the realize instance node "free" in those cases.
When the instance has a non-identity transform it only copies and
transforms the positions; the rest of the geometry is untouched.
For the implementation it was simpler to still copy the ID data-block
and rely on implicit sharing to avoid the expense of copying attributes.
That's because we don't have access to the original geometry set
components after all the preprocessing has happened.
Pull Request: https://projects.blender.org/blender/blender/pulls/127867
Transforming the layers instead of points is way more efficient and usually has
the same effect visually. Therefore, it is the better standard behavior.
The main problem with this right now is that layer transforms are stored
as separate location/rotation/scale, so shearing is not supported. This will have
to be solved separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/127757
I've done this a few times and would have benefited from a utility
function for it, apparently it's done in a few more places too. The
utilities aren't multithreaded for now, it doesn't seem important
and often multithreading happens at a different level of the call
stack anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/127517
Joining many geometries was O(n^2) because of deduplication of the same
components was not done using a map. My test file that generates 1000
stars in a repeat zone got 10x faster, but it's possible to create a file for any
speedup.
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 adds a variant of `accumulate_counts_to_offsets` which checks for
overflows. The hot loop stays essentially the same, it just uses a `int64_t`
instead of `int` for the counter now. For now the error state is returned by
using an `std::optional`. Alternatives could be to throw `std::overflow_error`
or to use some Result/Expected type in the future.
Obviously, there are more places that should handle this kind of error. It's
also not obvious how to propagate that error further up yet so that we can
display e.g. a warning in the node. That decision should be applicable to other
nodes too. For now, there is no warning on the node.
Pull Request: https://projects.blender.org/blender/blender/pulls/127184
Interpolate tool was only mixing point attributes, leaving the
output curves without most curve attributes. Now the interpolate_curves
functions actually copy or mix curve attributes as well.
Only float-based attributes are interpolated for now to avoid
meaningless values for material indices, boolean flags, etc. Other
attribute types are simply copied from the first curve in each pair.
Pull Request: https://projects.blender.org/blender/blender/pulls/127350
When I first developed the attribute filters they were just a `FunctionRef`
and thus could be stored by value in this struct. Now that they are a
virtual type, that is not possible anymore.
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
