alexrj/Slic3r — pull request #705 by mesheldrake (2012-09-20 14:01:46+00:00)
Title: Offset artifacts fixed with higher scale factor to Math::Clipper::offset()

I finally got a stepper-driven extruder set up, and during my first couple prints with Slic3r-generated code I was seeing all these motion hiccups in sections that should have been smooth. I realized I was watching Math::Clipper artifacts.

Math::Clipper::offset() needs a larger scale factor than what is being used to have enough precision to eliminate artifacts in concave offsets.
Slic3r is currently using values of 1 and 100 most of the time. These values are too low. We're getting lots of jagged artifacts in the resulting tool paths.

Tests on STLs in issues #700, #702 and #703 suggest that using a default scale factor of 100000 in Math::Clipper::offset() and Math::Clipper::safety_offset() will eliminate these artifacts.
Here are clear before and after examples from a gear. (looking down on multiple layers at once)

![spur tooth fixed](http://sheldrake.net/spur_gear_tooth_paths_fixed.png)
![spur center perimeters](http://sheldrake.net/spur_gear_hole_perims_fixed.png)
STL: http://sheldrake.net/spur.stl

There is a risk of extreme point proliferation with a scale factor this high in combination with the JT_ROUND option and large offsets from convex curves.

We're not doing large offsets, so the risk is minimized.

I checked the cases where JT_ROUND is used, and they should all be safe with this commit.

The four offset()s that use JT_ROUND are all safe because they set/override the scale factor to a low value and they all outset convex hulls, so there's no risk of the artifacts we can get on the concave side of things.

This fix actually reduced the the memory used to slice the hook model in #702 - probably because any small point proliferation was more than offset by the reduction of points involved with jagged artifacts.

This issue affects the 0.9.2 release of Slic3r I started using a few days ago, but OhmEye in #700 pegs the start of the problem to
SHA: 44c636aea1c491445ec7961b3142283ab3896690
which seems reasonable since safety_offset is involved.

This fix should solve #700, #702, #703, #622, #340, and maybe a couple others.

The second commit here fixes the issue described in #704. Using 0.1 degrees difference as the threshold for determining whether two adjacent segments are parallel is arbitrary, but gives better results for gradual curves than 3 degrees. With three degrees, gradual curves made of short segments are going to collapse into one segment that can deviate from the real perimeter by more than an extrusion width.