Issue was caused by clearing dirty flags from element table in bmesh before
the data was fully ready.
This confused checks happening from threads and some threads did consider
element table is usable while other thread was still filling it in.
The "pipe" case -- where two beveled edges are in line
and there is at least one more beveled edge -- needed better
handling when profile parameter = 1.0 (square outward).
The method for calculating points on the profile for non-circles
and non-lines meant that the segments making up an edge had
uneven widths.
Use a numeric search technique to find superellipse evaluation
points that lead to equal-sized chords across the profile.
Also calculate the actual profile points sooner, so that they
don't have to be recalculated again and again.
This also sets up for a possible later feature of arbitrary
profile shapes, set by user.
Ref: http://en.wikipedia.org/wiki/XOR_swap_algorithm, modern compilers/CPUs are much more efficient with "naive" algo than XOR one.
Doubled check, for me in an optimized build, XOR is several times slower than naive algo.
With new subdivision method for making the vertex mesh, we always
subdivide the edges between the new vertices around a vertex
(we used to not subdivide edges between two non-beveled edges).
This fixes a bug related to this change.
Vertex bevel was completely messed up after last change,
and this fixes.
'Weld' bevels, where there are exactly two beveled edges
meeting at a vertex, now look better in cases where one
of the beveled edges is on a flat plane.
It is better to keep the profile as it is perpedicular
to the edge, and then project it onto a given plane
at the corners. Also fixed the interpolation to a
different number of segments when the profile is not
round.
Parameter controls concavity / convexity.
<.25 means: concave inward
.25 means: straight slanted
>.25 means: concave outward
.5 means: circular (the default)
1 means: straight along original sides
For now, there is a hard lower limit of .15
because more work is needed to get decent
results in the range below that.
The profile is actually a superellipse, and the
parameter is 1/4 of the exponent in the implicit equation
for a superellipse, except at the extreme values of 0 and 1.
In separating out the adj mesh change from a profile change,
I'd forgotten that some profiles need to be flat (in particular,
for vertex-only bevels). This fixes that.
This gets rid of a hacky way of setting the mesh
coordinates at corners, which created overlaps
in some cases.
Also, special case a cube-like corner with all
edges beveled, to snap to a sphere, giving more
expected curvature in that case.
