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
This implements all the sculpt tools in Grease Pencil 3.
UI changes in the 3D view header and keymap entries for sculpt mode are
still minimal, more entries should be added once the relevant operators
are supported.
A set of utility functions and a shared base class
`GreasePencilStrokeOperationCommon` for sculpt operations has been added
to make individual operations less verbose.
The `GreasePencilStrokeParams` struct bundles common arguments to reduce
the amount of boilerplate code. The `foreach_editable_drawing` utility
function takes care of setting up the parameters and finding the right
drawings, so the tool only has to modify the data. Common features like
tracking mouse movement and inverting brush influence are handled by the
common base class.
Most operations are then relatively simple, with the exception of the
Grab and Clone operations.
- __Grab__ stores a stroke mask and weights on initialization of the
stroke, rather than working with the usual selection mask.
- __Clone__ needs access to the clipboard, which requires exposing the
clipboard in the editor API.
Pull Request: https://projects.blender.org/blender/blender/pulls/120508
This adds a new `Handles` checkbox to the conversion operator that
affects how the conversion works in the following cases:
`Bezier -> Catmull Rom / Poly / Nurbs` and `Catmull Rom -> Nurbs`.
If enabled, three control points are added for each original control
point, otherwise only one.
-----
The images show the effect of the toggle. The top result is always the one with handles and the bottom one without.
* `Bezier -> Poly`
* `Bezier -> Catmull Rom`
* `Bezier -> Nurbs`
* `Catmull Rom -> Nurbs`
Pull Request: https://projects.blender.org/blender/blender/pulls/120423
There was no check for a convex hull with 1-2 points,
causing unwrap to crash on degenerate faces.
Regression caused by [0] (fix for #115061), which hid this bug.
[0]: 0053de6556
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 main motivation for this is that it's part of a fix for #113377,
where I want to propagate the edit mesh pointers through copied
meshes in modifiers and geometry nodes, instead of just setting the
edit mesh pointer at the end of the modifier stack. That would have
two main benefits:
1. We avoid the need to write to the evaluated mesh, after evaluation
which means it can be shared directly among evaluated objects.
2. When an object's mesh is completely replaced by the mesh from another
object during evaluation (with the object info node), the final edit
mesh pointer will not be "wrong", allowing us to skip index-mapped
GPU data extraction.
Beyond that, using a shared pointer just makes things more automatic.
Handling of edit mesh data is already complicated enough, this way some
of the worry and complexity can be handled by RAII.
One thing to keep in mind is that the edit mesh's BMesh is still freed
manually with `EDBM_mesh_free_data` when leaving edit mode. I figured
that was a more conservative approach for now. Maybe eventually that
could be handled automatically with RAII too.
Pull Request: https://projects.blender.org/blender/blender/pulls/120276
The reverse uv sampling operation generally fails when there the sample position
is within more than one uv triangle. Unfortunately, the combination of limited
floating point accuracy and very small triangle areas caused this case
sometimes, even if the triangles don't actually overlap. This happens relatively
rarely, but if it does, it causes annoying artifacts. The solution is to only
detect these kinds of overlapping triangles if they have a certain minimum size
and to be more relaxed otherwise.
Pull Request: https://projects.blender.org/blender/blender/pulls/120408
Avoid copying the positions array into the evaluated edit hints array
that's used to support editing with deformed positions when there is
a topology-changing procedural operation. In a simple test in sculpt
mode with 706k curve points, memory usage went from 78 to 70 MB.
This adds more duplication would be ideal, mainly because retrieving
the data with write access and making implicit sharing info for arbitrary
arrays aren't abstracted by implicit sharing utilities. It may be possible
to improve both of those aspects, either now or in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/120146
Compute an index masks of points to remove to simplify the curve attribute using the Ramer-Douglas-Peucker algorithm.
The Ramer-Douglas-Peucker algorithm finds a set of points in a polyline to remove so that the overall shape of the polyline is similar. How similar can be controlled by the distance `epsilon`.
The function takes a `GSpan` so it can be used with any attribute (that has a type `float`, `float2`, or `float3`).
Pull Request: https://projects.blender.org/blender/blender/pulls/118560
This improves performance by **reducing** the amounts of threads used for tasks
which require a high memory bandwidth.
This works because the underlying hardware has a certain maximum memory
bandwidth. If that is used up by a few threads already, any additional threads
wanting to use a lot of memory will just cause more contention which actually
slows things down. By reducing the number of threads that can perform certain
tasks, the remaining threads are also not locked up doing work that they can't
do efficiently. It's best if there is enough scheduled work so that these tasks
can do more compute intensive tasks instead.
To use this new functionality, one has to put the parallel code in question into
a `threading::memory_bandwidth_bound_task(...)` block. Additionally, one also
has to provide a (very) rough approximation for how many bytes are accessed. If
the number is low, the number of threads shouldn't be reduced because it's
likely that all touched memory can be in L3 cache which generally has a much
higher bandwidth than main memory.
The exact number of threads that are allowed to do bandwidth bound tasks at the
same time is generally highly context and hardware dependent. It's also not
really possible to measure reliably because it depends on so many static and
dynamic factors. The thread count is now hardcoded to 8. It seems that this many
threads are easily capable of maxing out the bandwidth capacity.
With this technique I can measure surprisingly good performance improvements:
* Generating a 3000x3000 grid: 133ms -> 103ms.
* Generating a mesh line with 100'000'000 vertices: 212ms -> 189ms.
* Realize mesh instances resulting in ~27'000'000 vertices: 460ms -> 305ms.
In all of these cases, only 8 instead of 24 threads are used. The remaining
threads are idle in these cases, but they could do other work if available.
Pull Request: https://projects.blender.org/blender/blender/pulls/118939
Similar to the recently introduced `Solver` enum. This is just friendlier
and doesn't require including `DNA_node_types.h` in the geometry
module header. There's no strong benefit to declaring these enums in
DNA in practice.
This adds a "Solver" option to the geo boolean node, with the options
Exact and Float.
The current geo boolean node only uses the Exact solver.
This adds the ability to use the faster original floating point boolean solver.
The float solver has issues with coplanar and other coincident geometry,
but is generally much faster than the Exact solver, and users have asked
for this option (which is available in the Boolean Modifier and edit mode
boolean tool).
Like the modifier, the Float solver needs to convert the Mesh to BMesh,
do the operation, and then convert back to Mesh. It also has to do it
iteratively if more than two operands are supplied.
This is the first of a planned series of commits that will add a
new exact boolean solver, based on the Ember paper, as a solver option.
Ember will be much faster than the current exact solver, but may still not
be as fast as float, and also will not handle some non-volume-enclosing
inputs as well as Float, so it is likely that the Float solver will always remain.
We may eventually retire the old Exact Solver, however.
This commit also prepares for more sensible code in the future by
changing the internal enum names for the solvers to better reflect the
algorithms used: Fast -> Float, and Exact -> Mesh_Arr (which means
"Mesh Arrangments, the name of the paper upon which the current
exact solver is based).
Co-authored-by: Howard Trickey <trickey@google.com>
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/119294
Header file is renamed to GEO_mesh_boolean_convert.cc and
files that included it are updated to use that path.
This is in preparation for bigger changes to the internal
boolean API, which make more sense as a "geometry" API
than a kernel API.
Pull Request: https://projects.blender.org/blender/blender/pulls/119336
This implements a new internal data structure for reverse uv sampling.
Being better than the previous one was not particularly hard, because it
was never really optimized and used a very simple approach. I found the
new implementation to be about 10-20x faster in my tests. Simon was
able to reproduce an comparable speedups in production files.
The speed-up is mainly achieved by a better memory layout and better
multi-threading during construction. The lookup performance is mostly the
same as before.
Like the old data structure, the new one also splits the uv space into
uniformly sized cells. The size of the cells is based on the number of
triangles. Then it sorts all triangles into the rows that they touch. Finally,
it creates a flat array for each row that contains the triangle indices
contained in each cell.
There are still ways to optimize this further, but for now this is a good
improvement already.
Pull Request: https://projects.blender.org/blender/blender/pulls/118772
The `std::all_of` function wasn't used correcty.
Also, the last value of `dst_offsets` was always 0
(because the offsets were still counts at this point)
so the fix also makes sure the last value
is never included in the check.
This splits the core part of `resample_to_uniform` into it's own function, so that it doesn't depend on field evaluation.
From there, new versions of `resample_to_count`, `resample_to_length`, and `resample_to_evaluated` are provided.
Pull Request: https://projects.blender.org/blender/blender/pulls/118551
String attributes are not handled correctly (or at all) by geometry nodes
currently because their storage is very inefficient and will likely have to
change in the future anyway. Elsewhere processing string attributes was
explicitly disabled. That was missing in these cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/118802
- Use standard (copy & pasted) linear interpolation utility
- Use helper variable for attributes
- Make some other names a bit simpler
- Remove unnecessary variable
Similar to 2e6223d90f, but potentially 16 times more effective.
The new attribute is named "instance_transform". It isn't displayed in the
spreadsheet since that wouldn't really be useful. This simplifies a lot of
code since it doesn't have to handle transforms specially anymore. But
complexity is added in the store named attribute node and attribute input
node to keep the old "position" attribute working for compatibility.
Pull Request: https://projects.blender.org/blender/blender/pulls/118531
