* If all column vectors of the 3x3 sub-matrix are equal the function incorrectly claims that it's uniform scaling.
* Detect also non-uniform scaling and if was applied from the left or right side
* Replace the int with an enum and expose it to Python
* Add several new unit tests
These features, based on the code for the Pipe class, allow the user
to simply create a helical sweep within PartDesign workbench.
Sample application is threads, springs, coils, augers, etc.
Also, remove needless requirement for positive cone angle on helixes.
Thanks to @bitacovir for helping with the icons
Thanks to @chennes for review
Thanks to @vosk for review
Thanks to @wwmayer for review
Enforce that links stay within scope for ProfileBased features
This also ensures that the Body itself is not used for creating features within
the body, causing a "Graph not a DAG" error.
OCC currently does not reliably enforce linear deflection on curved
surfaces, especially curved lofts over nurbs splines. To avoid surprises
when tight tolerances are needed, replace the static default angular
deflection of 0.5 radians (~28 degrees), with a more sensible angular
deflection derived from the provided linear deflection tolerance.
By adding the default heuristic to TopoShape, we can keep typical
tessellate() and STL export functionality users simple, and also avoid
the need to implement similar heuristics in many places. If more
explicit control over angular deflection is needed for some use cases,
then we could still choose to expose the option to override the derived
default explicitly.
The hope is that OCC's linear deflection enforcement will be more
reliable at some point, at which point this heuristic will no longer be
needed.
Update parameters for all BRepMesh_IncrementalMesh instances to allow
parallel meshing. This matches what is already done for view
tessellations.
Other positional parameters are filled with their defaults in
BRepMesh_IncrementalMesh, so there should be no behavior change outside
of allowing parallelism.
std::move is redundant when it is used to return a local object from a function (eg return std::move(local)): indeed, returning a local object from a function implicitly moves it. Moreover using std::move this way
See https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-return-move-local
However, in order to avoid -Wreturn-std-move as well, a Base object is move-constructed
from Derived when required.
for Drawing, Image, Inspection, Mesh, MeshPart, Part, Path, Points, Raytracing, ReverseEngineering, Spreadsheet, Start, Surface, Web
TODO: fix several -Woverflow in area
