I thought I had reasoned that the add_patch would only happen
when the patch was not already in a cell, but I missed reasoning
about merged cells. So switched to a set 'add' instead of 'add_new'.
By checking if a cell has already been processed in the finding patch
component code, an enormous speedup happens. This only will be
noticeable if there are lots of patches, and some cells with a
large number of patches.
In case where there are coplanar instersections where
each part has a lot of triangles, the finding-cells algorithm was
very inefficient. This uses a Set instead of a Vector to keep track
of a cell's patches, avoids going through all patch x patch combinations,
avoids going through all patches to renumber after a merge, and
merges smaller patch-sixe cells into larger ones.
All this reduces the time to find cells in the cited case by a factor of 10.
Two problems were fixed. One, the code for dissolving vertices
left a face around if dissolving a vertex would leave less than
three vertices. Instead, the face should be deleted.
Two, with transformations like "rotate 180 degrees", this should
be no problem with exact, but the current transformation matrix
has very small non-zero entries where it shouldn't. Cleaning the
transformation matrix makes it more likely that user expectations
about coplanar faces will be fulfilled.
The code was trying to ignore hidden geometry when doing boolean,
which is correct when used as a tool, but not when a modifier.
Added a "keep_hidden" argument to bmesh_boolean to distinguish the
two cases.
Also fixed a bug when the tool is used with hidden geometry that
is attached to unhidden geometry that is deleted by the operation.
The code was trying to ignore hidden geometry when doing boolean,
which is correct when used as a tool, but not when a modifier.
Added a "keep_hidden" argument to bmesh_boolean to distinguish the
two cases.
Also fixed a bug when the tool is used with hidden geometry that
is attached to unhidden geometry that is deleted by the operation.
The routine to find dissolvable vertices had a check to ensure
that the vertex was exactly in line with the two neighbors.
I have convinced myself that this check is unneccesary (it was
failing with only a 1e-9 difference from 0 on a cross check),
so have removed it.
Also added code so that exact solver does the whole collection at once.
This patch allows users to use a collection (as an alternative to Object)
for the boolean modifier operand, and therefore get rid of a long modifier stack.
Well, this only fixes the example if one uses the new Exact mode,
but since that is available, seems fair to call this fixed.
Since these were not closed-volume operands, the Exact mode needed
some adjustment to the threshold used for "inside-outside" tests
for the case of deciding if the cutter is inside the other shape
for a Difference.
This is for design task T67744, Boolean Redesign.
It adds a choice of solver to the Boolean modifier and the
Intersect (Boolean) and Intersect (Knife) tools.
The 'Fast' choice is the current Bmesh boolean.
The new 'Exact' choice is a more advanced algorithm that supports
overlapping geometry and uses more robust calculations, but is
slower than the Fast choice.
The default with this commit is set to 'Exact'. We can decide before
the 2.91 release whether or not this is the right choice, but this
choice now will get us more testing and feedback on the new code.
