BMesh intersect could leave invalid items in the selection list,
causing a crash. The list is now cleared since boolean is such a
destructive operation, it's unlikely the selection order would be useful.
Thanks to @lukastoenne for finding the root cause.
The main goal here is to remove the need for a C API to the code in
`mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c`
to C++ and making the necessary changes for it to compile. On top of
that there are some other slight simplifications possible to the
direct mesh boolean code: it doesn't need to copy the material
remaps, and the modifier code can use some other C++ types directly.
Changes to increase subdivision by one along both axis (X and Y)
For example with x_segment = 3 and y_segment = 3.
There should be 16 vertices ((3 + 1) * (3 + 1)) for correct
number of subdivisions. Currently they are 3 * 3 = 9 vertices.
Ref D10699
The commit rB6f63417b500d that made exact boolean work on meshes
with holes (like Suzanne) unfortunately dramatically slowed things
down on other non-manifold meshes that don't have holes and didn't
need the per-triangle insideness test.
This adds a hole_tolerant parameter, false by default, that the user
can enable to get good results on non-manifold meshes with holes.
Using false for this parameter speeds up the time from 90 seconds
to 10 seconds on an example with 1.2M triangles.
When polygons around a bevel are rebuilt, sometimes UVs are merged
around a new vertex in the case of the face opposite a single edge
being beveled on a 3-edge vertex. This should not have been done
if any of the edges at that vertex were a seam.
This was introduced in the new geodesic distances algorithm for proportional
editing. When all faces of an edge are hidden, that edge should be considered
as loose geometry.
Initial patch by Pablo with modifications by Brecht.
Differential Revision: https://developer.blender.org/D10488
While Boolean is not guaranteed to work if the operands are not
volume-enclosing (technically: PWN - piecewise constant winding number),
it needs to do something in those cases. This change makes
more cases meet user expectations in T84493, T64544, T83403,
T82642 (though very slow on that one).
The original new boolean code used "generalized winding number"
for this fallback; replaced this with code that uses raycasting.
Raycasting would have been faster, but for unfortunately also
switchd to per-triangle tests rather than per-patch tests since
it is possible (e.g., with Suzanne) to have patches that are
both inside and outside the other shape. That can make it much
slower in some cases, sadly.
The previous fix to the width modes Percent and Absolute did
not take into account that with limit mode Weight, the amount
needs to be scaled by the bevel weight of the beveled edge in
question. (Sometimes there are two beveled edges in question,
in which case an average is used.)
This makes the exact boolean have zero weights for any vertex groups
on any newly created vertices, which is what the fast solver does.
The exact boolean solver was interpolating vertex data when interpolating
loop data in newly created faces. Not sure why I chose that. The Fast
boolean solver doesn't do that, so I stopped doing it too.
