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.
- let FeatureExtrude set the right direction
- use the UI as once intended: custom vector values are always taken as they are, so reversing a custom direction will not lead to a negation of the custom vector in the UI. The logic is: "take the vector as it is, and when Reversed is on, negate it additionally"
- update the preview when the direction is changed in the dialog
- don't uncheck the direction viewbox without any reason
- only recompute once
- update the direction information on reversion
- only pocket: add missing code we have in pad (proper code merging will follow the next days)
This is a combination of 4 commits. Original commit messages follow.
[PD] Initial support for point sections in loft
This commit allows the last section in a loft to be a single vertex of a solid.
Currently single vertices of sketches or datum points are NOT supported.
[PD] Allow loft "profiles" to be points
Most reliably done in dialog-based workflow.
[PD] Allow loft last section to be sketch point
[PD] Refactor `Loft::execute`
Makes it easier to support adding a single-vertex sketch in profile or sections
field when selecting the sketch in tree (i.e. without selecting subelements).
[PD] Refactoring after PR #5176 is merged
now that pockets have the same functionality as pads, the UIs can be unified:
- the position of the Offset widget in the UI is better in pocket, thus use it for pad too
- add missing tabstops for pad
- add missing tooltip for pocket
- update tabstops for pocket
- the info if a custom direction is used, was incorrectly determined by checking a checkbox that only displays the vector value, no matter if it is a custom vector or not
This PR adds the functionality of pads to pad along either a custom direction or along an edge to pockets.
So with this PR Pad and Pocket are on the same level of functionality.
