modified things to work with curve strategy, put protection for maximum, minimum travel using path as following a path can plunge beyond the depth if one is not careful
Simplified datapoints in a chunk to avoid Shapely error by MadDogJroc
thanks for this patch.
I don't have a time to check this properly , but will commit it, we can remove it in future. Shapely has a simplify operator that works quite nicely. Only drawback of your solution might be some performance loss in some cases I think?
I think shapely didn't measure distance to boundary, but to any point in
the chunk, which could lead to wrong sorting in outliefill. Now it
measures the distance to boundary.
Also when paths are trimmed due to depth or limit curve. Similar
approach could be used for other non-sorted 3d strategies.
Especially good with ZigZag - Meander movements.
This speeds up greatly finding of parent/child in pockets, outlinefill,
and probably more.
Pockets with many independent shapes were ultra-slow, not really
measurable, now should be usable....
-revert new parallel pattern algo, isn't finished yet(parallel stepback
problem)
-curves, text, can now be used also if parented
-scan tools remove small parts tool.
Resorting a collection of chunks would yield different results than the
first sort. This was caused by adaptdist changing the order of the
points on a chunk that had already been sorted earlier.
Generates overcuts on a curve.
- inner, or also outer polygons.
-has threshold for angles to consider
the overcuts are optimal - done so that the radius of the cutter only
touches the corner, but doesn't go behind it.
this optimizes chunk sorting a bit, by not iterating over too many
children - some chunks could be checked many times.
For parallel operations with layers, this fixes something that was
rather a bug - because too many relations were created and this could
lead to exponential computation times relative to count of layers.
the memory limit is a new feature, preventing crashes when ppl. e.g.
compute path on the default size obects, and also any other cases with
non-exact mode.
otherwise, big, happy removal of polygon library residues. This library
is NO logner a dependency of blender CAM. Shapely library works far
better in most cases. Sometimes it's slower but this can be compensated
with optimizations almost always quite easily.
bridges code had some really stupid redoing - it was getting the bridges
polygon for EACH chunk which was supposed to be computed... this proves
again my old rule - if I write something very badly , I can then enjoy
optimizations by several hundred percent :)