Currently the infill code makes rectangles, which has the path code making lots of backtracking moves. Also, the path leaps over gaps to print fill rectangles that were split up. This makes for a lot of strings is all sorts of problems for oozing plastic.
We should probably change from intersecting rectangles with the fill Area, and instead intersect lines with it, then find the shortest path that connects the lines, where the line joins don't intersect the perimeter, unless there are no other alternatives. (Or maybe line joins that do intersect the perimeter should follow the perimeter around.)
Thanks for picking up on this. It shouldn't be too difficult for me to restructure things so that sub-areas are shelled and filled sequentially instead of globally.
Currently the infill code makes rectangles, which has the path code making lots of backtracking moves. Also, the path leaps over gaps to print fill rectangles that were split up. This makes for a lot of strings is all sorts of problems for oozing plastic.
We should probably change from intersecting rectangles with the fill Area, and instead intersect lines with it, then find the shortest path that connects the lines, where the line joins don't intersect the perimeter, unless there are no other alternatives. (Or maybe line joins that do intersect the perimeter should follow the perimeter around.)