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
This removes `AnonymousAttributeID` which was "attached" to every anonymous
attribute before. It adds more complexity than is justified for its
functionality.
It was originally introduced to keep the reference count of the anonymous
attribute so that it can be deleted automatically when the attribute is not
referenced anymore. For quite some time we have had deterministic attribute
life-times though which don't rely on the reference count anymore.
Anonymous attributes are sometimes shown in the UI as "friendly looking" string
like `"UV Map" from Cube`. Some information necessary for this was also stored
in `AnonymousAttributeID`. However, this can also be solved differently.
Specifically, this functionality has now been added directly to
`AttributeFieldInput`.
This refactor also allows removing `AttributeIDRef` which was mainly introduced
because we had to keep the `AnonymousAttributeID` attached with the attribute
name. Just using simple string types to identify attributes can reduce the
mental overhead quite significantly. This will be done as a separate refactor
though.
Pull Request: https://projects.blender.org/blender/blender/pulls/127081
And same for the `copy_layout` function. These functions do not free any
potentially existing data in destination, but expect it to be uninitialized.
Hopefully these new names will make it more clear and avoid bugs like #122160.
There is a reason for the bitwise operator but it's not explained:
The attribute_foreach function callback has side-effects that the
compiler does not know about (everything is const). Simply replacing
the bitwise operator will cause the second term to be skipped, which
breaks tests due to missing attributes.
Now the term is explicitly evaluated first, then combined with actual
boolean operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/126366
The grid geometry creation incorrectly tagged the mesh with no loose edges
or vertices, breaking invariants of the caches that are relied on elsewhere.
This adds a `geometry::smooth_curve_positions` function that
smoothes both bézier curves and all the other curve types.
Bézier curves are smoothed by joining the handle and control
points into a flat array, then using the 1D gaussian algorithm
and writing the resulting positions back into the left and right
handle positions as well as the control points. In general,
this works reasonably well and is similar to the results of the
other curve types.
Pull Request: https://projects.blender.org/blender/blender/pulls/125496
This was reported by the studio. When opening one of the lighting
files in 4.3, Blender would crash.
The realize instance task for grease pencil needs to copy all the
layer attributes to the target geometry. When creating the
`dst_attribute_writers` using `lookup_or_add_for_write_only_span`
the `bke::AttrDomain::Point` was used when it should have been
`bke::AttrDomain::Layer`.
Pull Request: https://projects.blender.org/blender/blender/pulls/125603
This continues the cmake modernization effort and introduces support for
allowing our optional dependencies to integrate properly. TBB is added
here as it's proven troublesome to maintain correctly.
Currently the only Blender project which uses the TBB headers directly
is `blenlib`. However, all downstream projects which require blenlib as
their dependency, and wish to properly make use of its threading
facilities, needed to define various TBB items in their CMake files. Not
only is this unnecessary and arcane, but several projects didn't do this
and ended up not using threading as well as producing ODR violations
along the way[1].
This PR makes TBB a modern dependency and exposes it PUBLIC'ly from
`blenlib`. All downstream projects which depend on blenlib will now
receive everything they require from TBB automatically. This includes
the `WITH_TBB` define, the headers, and the library itself.
[1] blender/blender@05241f47f5
Pull Request: https://projects.blender.org/blender/blender/pulls/124916
Interpolation tool for strokes ported from GPv2.
Adds a new operator that inserts a new frame with interpolated curves.
The source curves are taken from the previous/next keyframe.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/122155
This implements the _automerge_ feature which finds nearby end points
during stroke draw and merges the new curve with existing strokes.
New utility functions are added in `geometry` for slightly generalized
functionality. The `curves_merge_endpoints` takes an index map that
describes how to connect curves by index. It performs a topological sort
and reorders connected curves into contiguous ranges. This can be used
with an arbitrary number of connected curves. The tool feature itself
only uses a single curve, based on 2D end point positions.
Unit tests have been added for the curve merge utility function.
Pull Request: https://projects.blender.org/blender/blender/pulls/124459
Previously, this code would crash when there are vertex groups which are
not stored as simple arrays. This happened e.g. in #124416.
All non-array attributes are converted to array-attributes with this change
for now, which is better than crashing.
Previously, grease pencil was just ignored by the Join Geometry and Realize
Instances code. Now they work by concatenating the layers of all grease pencil
geometries together. So if e.g. there are two inputs with each 3 layers, then
the output will have 6 layers. Layer attributes are kept intact.
Some important things to keep in mind:
* Grease pencil layers are expected to have unique names. Ensuring uniqueness
requires O(n^2) currently.
* The material indices on the curves in each layer have to be remapped.
Just like with all other geometry types, the first input in the Join Geometry
node will come first in the output geometry. Since grease pencil layers are
drawn starting at index zero, that means that the first input will be drawn
first (i.e. it's at the bottom).
Pull Request: https://projects.blender.org/blender/blender/pulls/124361
This adds support for attaching gizmos for input values. The goal is to make it
easier for users to set input values intuitively in the 3D viewport.
We went through multiple different possible designs until we settled on the one
implemented here. We picked it for it's flexibility and ease of use when using
geometry node assets. The core principle in the design is that **gizmos are
attached to existing input values instead of being the input value themselves**.
This actually fits the existing concept of gizmos in Blender well, but may be a
bit unintutitive in a node setup at first. The attachment is done using links in
the node editor.
The most basic usage of the node is to link a Value node to the new Linear Gizmo
node. This attaches the gizmo to the input value and allows you to change it
from the 3D view. The attachment is indicated by the gizmo icon in the sockets
which are controlled by a gizmo as well as the back-link (notice the double
link) when the gizmo is active.
The core principle makes it straight forward to control the same node setup from
the 3D view with gizmos, or by manually changing input values, or by driving the
input values procedurally.
If the input value is controlled indirectly by other inputs, it's often possible
to **automatically propagate** the gizmo to the actual input.
Backpropagation does not work for all nodes, although more nodes can be
supported over time.
This patch adds the first three gizmo nodes which cover common use cases:
* **Linear Gizmo**: Creates a gizmo that controls a float or integer value using
a linear movement of e.g. an arrow in the 3D viewport.
* **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be
rotated to change the attached angle input.
* **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale.
In the future, more built-in gizmos and potentially the ability for custom
gizmos could be added.
All gizmo nodes have a **Transform** geometry output. Using it is optional but
it is recommended when the gizmo is used to control inputs that affect a
geometry. When it is used, Blender will automatically transform the gizmos
together with the geometry that they control. To achieve this, the output should
be merged with the generated geometry using the *Join Geometry* node. The data
contained in *Transform* output is not visible geometry, but just internal
information that helps Blender to give a better user experience when using
gizmos.
The gizmo nodes have a multi-input socket. This allows **controlling multiple
values** with the same gizmo.
Only a small set of **gizmo shapes** is supported initially. It might be
extended in the future but one goal is to give the gizmos used by different node
group assets a familiar look and feel. A similar constraint exists for
**colors**. Currently, one can choose from a fixed set of colors which can be
modified in the theme settings.
The set of **visible gizmos** is determined by a multiple factors because it's
not really feasible to show all possible gizmos at all times. To see any of the
geometry nodes gizmos, the "Active Modifier" option has to be enabled in the
"Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of
the following is true:
* The gizmo controls an input of the active modifier of the active object.
* The gizmo controls a value in a selected node in an open node editor.
* The gizmo controls a pinned value in an open node editor. Pinning works by
clicking the gizmo icon next to the value.
Pull Request: https://projects.blender.org/blender/blender/pulls/112677
`get_count_input_from_length()` did not check whether length is zero,
this would cause division by zero exception. Now will return a segment
count of 1 when a zero length is given.
Pull Request: https://projects.blender.org/blender/blender/pulls/124440
This adds a new `name` member to the `GeometrySet` class. This name can be set
with the new `Set Geometry Name` node. Currently, the name is only used in the
spreadsheet when displaying instances.
The main purpose of this name is to help debugging in instance trees. However, in the
future it may also be used when exporting instance trees or when creating separate
objects from them.
Note, the name is not expected to be unique, it is fully in user control.
Naming geometries is necessary to make the spreadsheet more useful for instances,
because currently the user has no information for which geometry is used by each instance.
We also want to use this name to improve the integration with grease pencil where
sometimes layers become instances with the same name.
Pull Request: https://projects.blender.org/blender/blender/pulls/114910
If the mesh has a curve builtin attribute that's not stored on the point domain,
the creation of the attribute will fail and it can't be interpolated. Possibly this
could be supported somehow, by averaging all the values in the curve's points
or so, but for now just avoid the crash.
Previously, the "Simplify" option was a world space distance threshold.
This meant that zooming in and out of the view changed the way
this option behaved. There were complaints from artists about this.
This change improves two things:
* The simplify algorithm uses the screen space coordinates rather than the
3D positions.
* The UI setting is in pixels making it much easier to tweak (no need
for values in the 1e-4 range).
Pull Request: https://projects.blender.org/blender/blender/pulls/122719
There was an overloaded version of `add_layer` that took
a const reference to a source layer. The function would
duplicate that layer.
The function name `add_layer` was a bit confusing in this
case. Calling it `duplicate_layer` makes it a bit clearer.
As part of #121565.
To avoid using drawing indices outside of the internal grease pencil API,
this refactor adds the functions `GreasePencil::get_eval_drawing` to replace
the `get_eval_grease_pencil_layer_drawing*` functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/121567
Cleanup to avoid unnecessary copies of VArray. This
requires ref-qualifier overloads of dereference operator
of attribute reader and some move operators and constructor
overloads in the code.
Pull Request: https://projects.blender.org/blender/blender/pulls/118437
Previously, the Realize Instances node would always realize everything in the geometry.
Now it's possible to more selectively realize parts of the geometry:
* One can choose which top level instances should be realized.
* The realization depth can be controlled per top-level instance. For example, if there are
5 top level instances, each of which contains 10 other instances, it's now possible to
realize only one level so that one ends up with 50 instances.
Pull Request: https://projects.blender.org/blender/blender/pulls/116582
