Extend the work from #3496 to allow the safe optimization of more
complex step transitions.
- Use the actual safePDC path for short step transitions and breaks,
currently up to 2 cutter diameters. This value is chosen to cover
basically all typical end step-overs, including those with heavy skew.
Extending this much further (up to the break even point for a retract &
rapid) will need some careful thinking for multi pass paths.
- Coordinate offset tolerances with per-operation tessellation
tolerances, to avoid tessellation artifacts messing up paths by
causing false retracts. Such retracts can cause entire steps near
vertical areas to be falsely skipped, which would cause a major
deviation from the target model. By considering per-job tolerances, we
allow users to safely save computational resources by computing roughing
operations with lower precision, or selectively increase precision for
finish passes.
- Refine the default tessellation tolerance to GeometryTolerance / 4.
This makes sure that the job GeometryTolerance is respected by
operation defaults.
Improvements now identify cases where selected faces create a closed loop that creates an internal closed wire to not be processed.
Remove unnecessary comments.
Add debug statements.
Meshing tolerance settings for 3d surface operations were ignored since
switching to directly using facets from the view tesselation. On complex
3d shapes, this could cause serious meshing artifacts in the generated
paths, serious enough to show up even in path previews.
Additionally, there were occasionally segfaults when a model was not
viewed and thus implicitly tessellated before starting an OCL operation.
This patch switches from using view tessellations to explicitly calling
`tessellate()`. While this is usually more expensive than using the
existing view tessellation, recent changes to parallelize tessellation
have reduced this additional cost significantly.
Note that this diff only restores the use of LinearDeflection, since
that is the main thing we care about in OCL use cases. Angular
deflection is still ignored, but I think this is a good thing for this
case since a highly refined mesh in tiny but heavily curved areas below
the linear deflection threshold just adds unnecessary cost. If there is
agreement on this point, then we can remove the preference for
AngularDeflection from the UI in a follow-up.
Improve `HandleMultipleFeatures` processing when set to `Collectively` by implementing new class to refine the processing area, attempting to remove common edges between connected face regions.
