Previously a for loop with two iterations was used to calculate the
3D segment locations for the input number and the higher power of 2.
Splitting off the inside of the for loop to a separate function makes
the code more readable.
This commit also includes a simple timer for bevel, enabled with a
define. Interestingly, the cleanup in this commit happended to give
a 3% speedup on a Ryzen 3700x for a bevel calculation with 64
segments.
The bevel code initialized the CurveProfile with the "higher power of 2"
segments after the normal number of segments, leaving the widget in an
incorrect state after the calculation. A simple fix is to re-order the
initializations, doing the input number second.
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
This matches the change that was done to the bevel modifier so that the
interface for the modifier, the active tool, and the operator are consistent.
This commit extends the refactor to the bmesh implementation too, so
that the parameters in the implementation don't stray too far from what
is exposed.
Tests are adjusted and still pass.
Internally UV selection considered close UV's to be connected.
While this could be convenient in some cases,
it complicates logic for more advanced selection operations that
need to check when UV's should be considered part of the same vertex
since simple threshold checks would give different results depending
on the order of UV's tested.
Users must now run "Merge by Distance" instead of relying
on this selection threshold.
This adds support for path selection for vertex edge & face selection
modes, matching mesh editing behavior, useful with the UV rip tool.
Region select & edge tagging are currently not supported,
although they could be added eventually.
Support custom-data correction based on surrounding geometry for all
transformation modes of the mesh transform operators.
The is the same logic used in Vert and Edge Slide.
In order not to change the current default behavior,
this property does not affect Vert and Edge Slide modes.
When there is an odd number of segments, bevel has an ambiguous
choice as to which side face to use to copy face attributes from
and to use for UV (and other loops that have math function) interpolation.
We used to make choice arbitrarily, which led to visually inconsistent
results. Now there is tie-breaking code, face with lexicographic lowest
value in vector with these elements:
(1) connected component (in math-layer space) id
(2) selected (0) vs unselected (1)
(3) material index
(4,5,6): z,x,y components of face center, in that order.
This will allow the easier addition of a constant radius mode in the
future and some changes in the UI to mirror the recent similar change
from "Only Vertices" to the "Affect" enum.
This mode is like Percent, but measures absolute distance along
adjacent edges instead of a percentage.
So, for example, if you use this mode with 2 segments and profile=1,
you will see the length that the bevel moves along unbeveled edges
between beveled ones will match the value specified.
Many users seem to expect this behavior, even though it means the
bevel width is uneven, so this option is for them.
Custom Loop Normals are normally encoded relative to the default
normals, similar to normal maps, allowing them to naturally follow
mesh deformations. Changes to mesh topology however often result
in nonsensical effects that are not desired.
The Remove Doubles operation especially (now known as Merge By
Distance) is intended as a purely topological operation, and
definitely should not change the vector of the custom normals.
This patch implements that behavior by converting the relative
encoding into an absolute vector layer for the duration of the
operation. It also modifies other Merge types in this way for
consistency, the Rip operator as their inverse counterpart;
and also Delete, Dissolve, Connect Path and Knife operators
as other examples more related to topology than shape.
On the technical side, this ports mesh_normals_loop_custom_set
to BMesh, and then uses a temporary Custom Data layer to store
the normals as vectors for the duration of the above mentioned
operations. When the normals are converted back to custom data,
the caller can choose whether to mark edges as sharp to preserve
distinct normals, or just average them instead. All but Remove
Doubles choose to average for now.
Differential Revision: https://developer.blender.org/D4994
