- when a helix is defined in the growth mode it can have a pitch of zero
This commit fixes the resulting division by zero by directly setting the known turns
Introduce an enum to verify the axis depending on the used context.
* For helix no restriction is needed
* For Pad/Pocket the axis must not be parallel with the sketch plane
* For Revolve/Groove the axis must not be perpendicular with the sketch plane
Helices that become smaller with every turn are geometrically perfectly valid. Therefore we cannot forbid this.
(For example when creating a helix from a face you often cannot move it so that you can apply a positive growth.)
Now that we have the feature that sweeps can have vertices as end or begin of a sweep, there is the need for the feature to move sections. For example vertices may only be the last section.
- it is not sensible that all helix geometries use 1 as increment in the dialog but the growth uses 5. Looking at the PR that introduced this feature it seems that this was just a copy issue from the angle edit since this uses 5 as increment.
- the other changes are from Qt's Designer
Previously, only the vertical and horizontal axis of the profile was
selectable in the task panel of the additive/subtractive helix. Now the
profile's normal axis can be selected, too. This now allows to create
helical extrusions or "twisted pockets".
The order of the GUI entries was chosen to be in line with the order of
axis selection of the multi-transform parameters.
The actual feature's implementation needed adaption for this special case
as in some places a unit vector (`gp_Dir`) was derived from the cross-
product of axis and profile normal -- a null-vector when the axis *is*
the normal. This caused the gp_Dir's ctor to throw.
Used when finding subelements of a feature. Many of the comparisons used to also
check for string lengths, but as far as I can tell they are not strictly
necessary (see https://www.cplusplus.com/reference/string/string/substr/) and
just `substr` can be used without them. However, `compare` explicitly is for
comparing, and does not make a new object that `substr` does.
Similar to PR #5170 for loft. This commit squashes the following commits.
[PD] Refactor `Pipe::execute` and support point sections
[PD] Allow point profile in selection-based pipe workflow
[PD] Only add sketch subs if it is vertex
[PD] Make both end faces of pipe regardless of point sections
Earlier we were checking if these faces correspond to point sections, but
apparently the end faces are independent of the order in which the sections are
added, so the "front" may be the face closest to the last added section, rather
than the "profile". Creating null faces and adding them for sewing together into
a solid does not appear to have side-effects so far.