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
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
