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.
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.
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.
The existing hash function didn't work well with Set's method of
masking to the lower bits, because many verts have zeros in the
lower bits.
Also, replaced VectorSet with Set for Vert deduping.
Needed a better normal to for plane to offset into when there are
non in-plane edges between two beveled edges. It was using the vertex
normal, which is just wrong.
Differential Revision: https://developer.blender.org/D9508
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.
In some situations where two beveled edges were very close to in-line
but not quite straight, bevel would build a miter when it shouldn't.
The code that chose whether to use a miter at each vertex was slightly
incorrect.
For outer miters there is a check for 3 or more selected edges, but an
inner miter can still be useful with only two beveled edges at a vertex,
so we can't use that here. Instead I changed the check for in-line edges
to run before determining whether the angle is reflex or not. The logic
ends up a bit more straightforward as well. This doesn't completely
remove the rather strange looking triangle vertex meshes at each corner,
but it does make it stable when locations are slightly adjusted.
The only other place this `edges_angle_kind` function was used is for
profile=1.0 vertex meshes. I tested and made sure that still works well.
Differential Revision: https://developer.blender.org/D9420
The previous fix forgot the case where there is an intermediate
edge and everything isn't in one plane.
Differential Revision: https://developer.blender.org/D9336
Corrects incorrect usages of the fragment 'apart of' when 'a part of' was required.
Differential Revision: https://developer.blender.org/D9245
Reviewed by Campbell Barton
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
The code for Bevel's percent (and absolute) modes were pretty bogus.
It assumed, like the rest of the modes, that the offset lines are
parallel to the beveled edge. Which is not true for these modes,
though it accidentally works sometimes if the legs are equilength.
Also the clamping code for those modes was completey wrong.
It is too hard to really fix the clamping code for absolute mode,
but it is a little better now. Percent mode clamping is fixed.
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.
With this option, self-intersections in either or both operands
will be handled properly (if both sides are piecewise winding
number constant, and maybe some other cases too).
In the Boolean tool, this flag was there already but the code
forced a unary operation in that case; this commit corrects it
to make a binary operation. This flag makes the code slower, which
is why it is an option and not an always-on thing.
