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.
When the desired widths (offsets) of beveled edges cannot be
satisfied, often because we want them to meet on an intermediate
non-beveled edge, we need to compromise on the widths somehow.
This code changes the compromise to minimize the sum of squares
of errors in the offsets. It also adds a global width consistency
pass: starting from a vertex that needed width adjustment, it
uses a breadth-first search to try to propagate the adjustments
and keep the bevel widths from having to taper along the edges.
Also fixed a case where a reflex angle would cause bad results.
Also fixed the way the 'percentage' width method was calculated.
- could crash if triangulate attempted to create an existing face.
- tagging edges to rotate was unreliable, don't do this anymore.
now check if edge is in the array passed to the beauty function.
When beveling two adjacent edges, code used face normal instead
of the face-corner normal (these can be different for nonplanar
faces); the bevel may look uneven in such cases.
Switched to using corner normal, and needed to fix the case
where the edges meet at a reflex angle. Fixed a similar case
when beveling two edges with one non-beveled in between.
Also removed unnecessary argument from offset_meet.
In the case that there are two beveled edges with one unbeveled
one in between, and the widths don't allow them to magically
line up, it is better to slide along unbeveled edge.
Sometimes bevel widths are uneven (this was the case before)
and it is a followup TODO to do a width cleanup pass afterwards
to even the edges up as much as possible.
Now there is an 'Offset Type' dropdown on tool
shelf with types:
Offset - current method, offset of new edge
from old along sliding face
Width - width of new bevel face (if segments=1)
Depth - amount a chamfering plane moves down
from original edge
Percent - percent of way sliding edges move
along their adjacent edges
The different options mainly are useful when
beveling more than one edge at once.
Leaving as a TODO to put these in the modifier,
as doing that has more permanent effects so
want to let users shake out problems with this
first.
Quads: Beauty, Fixed, Fixed Alternate, Shortest Diagonal
Ngons: Beauty, Scanfill
* Shortest Diagonal is the default method in the modifier (popular
elsewhere), but beauty is the default in Ctrl+T).
* Remove the need for output slot and beauty operator to be called
after Clt+T
Patch with collaborations and reviewed by Campbell Barton
The ear loop method is potentially too slow (OˆN).
We are not using the 'beauty' option at the moment.
I'll incorporate that next.
(and later specific methods for quad splitting)
Patch done in collaboration (and reviewed by) with Campbell Barton.
add BM_ITER_MESH_MUTABLE which steps before entering the for() loop body and prevents the assert from complaining about removing mesh data while iterating as well as the crash.
this was done in quite a few areas, more may turn up.
Suggestion by Jonathan Williamson, and thanks to
Walid Shouman for noticing that the existing code
worked if a test to prohibit it were removed.
Limitation: treats segments > 1 the same as
segments == 1 in this case; a TODO to do
something more intelligent.
