Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve outline accuracy and reduce z-seam wobble by not discarding so many points #757
A user on the forum was having problems with a wobbly z-seam and I have been looking into it. As far as I can tell, the problem is caused by the simplify() method discarding points that it really shouldn't do if the z-seam is to stand much chance of being straight. That method has two criteria to decide whether a point in a polygon outline can be removed while still preserving the shape of the polygon. (1) distance of the point from the points before and after and (2) distance of the point from the line that joins the before and after points (error distance).
One of the changes in this PR is to not use the error distance criteria when simplifying the outline polygons. This is enough to vastly improve the location of the z-seam, here's a couple of images that show the difference, first, the results for the original code:
and now the results for the PR code:
One downside of not throwing away points is that for models that have a lot of points, the slicing time is going to increase. If this PR is deemed unacceptably slow then one solution would be to introduce another setting that can go with Maximum Resolution (BTW, shouldn't this be called Minimum Resolution as it is specifying the min size of a line segment?) that can specify the max allowed error distance and that could be used to reduce the numbers of points.
Another change in this PR is that I modified the simplify() code so that it no longer accesses elements of a vector using invalid iterators. It may be that the original code does work OK but it can't be guaranteed to do so.
Yes, this PR does have a bad effect on slicing speed when the model has a lot of outlines but, then again, it does actually produce a more accurate result. Here's a complex part sliced with the same resolution (0.04) with and without the error distance criteria.
When using the error distance criteria (original code) the slice took around 35 seconds and the output looked like this:
Look closely at that image and you can see some really bad outlines have been created.
When not using the error distance criteria the slice took around 180 seconds (much longer) but the output quality is noticeably improved:
The fidelity of the outlines is much improved. I know which one I would rather print.
However, playing more with the Maximum Resolution setting, you can trade off slicing time with output fidelity. With a resolution of 0.25mm, the slicing time is around 66 seconds and the output still looks much better than the result obtained with this PR so I think that perhaps the slowdown is acceptable given that the user can adjust the resolution.