This commit generally moves variable declarations to the smallest scope
the variables are used in. This makes the code more readable by
making it clearer when variables are used and by removing the block
of variable declarations at the top of each function.
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
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.
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.
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.
This is related to T76659.
This just renames data type names to `CD_PROP_STRING`, `CD_PROP_FLOAT`
and `CD_PROP_INT32`. It makes them a bit more specific and removes
unnecessary abbreviations.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7980
Don't use the cube corner special case when the offsets are different
for the three edges involved. The generic VMesh for this situation isn't
perfect, but it's much better than a failed cube corner VMesh.
Tests pass.
Don't use the cube corner special case when the offsets are different
for the three edges involved. The generic VMesh for this situation isn't
perfect, but it's much better than a failed cube corner VMesh.
Tests pass.
