- building without python works again
- rename maxi/mini to i_max/i_min (so thay are available for function names)
- some minor edits to IK stretch setting (no functional changes).
Main problem was in poly_rotate_plane() (which rotates a ngon to make its normal aligned with Z axis), it did not handled the case where the normal was aligned but opposite to the Z axis (which had the consequence that, as with the T mesh of the given blend, all tested new edges inside face were detected as outside, and vice-versa...).
Additionnaly, I made a mistake in previous Triangulate commit (r48243) in bm_face_goodline, which could allow a few invalid triangles in some specific cases, fixed!
And done a bit of cleanup, as I was at it.
The bug is related to 31581 and the main cause is the small offset that
BM_loop_interp_from_face introduces before calculating barycentric
weights. Solved by only calculating displacement layer.
Issue is that all loops of a face adjacent to the sliding verts were
getting project-corrected. Introduced a test to only project the
affected loops.
The projection code introduces a small offset to the boundaries so that
any boundary tests can work as expected, but this leads to shrinking of
the barycentric coordinates of the projection, causing a shrink of the
uvs in turn. This even affects the uvs that -should- be affected though
the unfixed behavior works strangely in a correctish way (my guess is
because the projection uses the same face as the opposite sliding loop).
I fixed the behaviour by taking the mean value of the uvs. This won't
support seams but current code doesn't either. Also, all CustomData to
exhibit this unfixed behaviour. I only fixed the uv case, other data
(Vcolors, etc) will have discontinuities when edge sliding. I expect
that the CorrectUV code I am working on may address some of these
issues.
Also, added NULL checks for utility function (was intended for this bug
but wasn't needed after all)
Notes:
*This implements a quite simple algorithm, which simply checks angles (actually, absolute cosines) of created tri and remaining face (which may be a tri, quad, or more NGon), so that both are "best" (ie avoid as much as possible too much narrow/wide corners), and also checks the new edge is OK (i.e. does not goes "out" of original face).
*Incidently, it fixes a typo in that bm_face_goodline() func!
*It's quite performant (a bit quicker than previous code, as far as I have tested it) and prevent creation of completely flat triangles as much as possible, but it's far from being a "best" solution (as it is still a "progressive" one)!
*It also introduces a new math func (in BLI_math_vector.h), cos_v3v3v3, which computes cosine (ie dot product of normalized vectors) and is roughly a quicker replacement for angle_v3v3v3, when real angles are not needed.
from Benoit Donat-Bouillud (ladeheria)
from tracker -
When using a screw axis (reference edge for screw), the operation always give the same result (as if the orientation of the reference edge was not take into account).
Add check for merging vertices into vertices that are themselves
marked for merge, was already done for array eleements but not end
caps.
Fixes bug [#31695] Array Modifier: End Cap fails if all vertices are merged
Also corrected some reversed assert arguments.
