The issue was raised by @ScribbleJ and @faberdasher about this model:
STL, G-code and config.ini at http://scribblej.com/heartgearplate/
(there's another issue on that model reported in #139)
I bump into this bug regularly. E.g. this bug is apparent when printing the head of the android device rest http://www.thingiverse.com/thing:5915 and the dome in the center of the lid of the companion cube box http://www.thingiverse.com/thing:13673
see what happens if you change the algorithm a little so the outermost perimeter is always printed on top of solid fill. With 1 perimeter and 45 degree slopes this may result in "zigzag" fill along the edges, but that's a small price to pay for not having scrappy-looking domes
hmm.. that's one option, although thin zigzag fill is risky... what about increasing perimeters? Slic3r could just automatically increase perimeters in that case. I like perimeters, they work well :) @triffid, opinions?
yeah could work although for very shallow gradients you may find you have a dozen perimeters in some parts of the model- I think solid infill would work best there!
So apparently there's some threshold below which perimeters make sense, and above which infill makes sense.
I wonder, could you use your medial axis algorithm to detect infill regions that are narrow and just run perimeters along them?
@triffid, Slic3r already does solid infill where infill area is exposed, so there's really no risk of have a dozen perimeters. This particular issue happens where no infill is exposed, but a layer can't lay its outermost perimeter on the innermost perimeter of the lower layer. For example:
New automatic detection of additional required perimeters for better …
…quality with domes and sloping walls. #198
Done: I added an algorithm for automatic detection of additional required perimeters in situations like these. Can you please test? Thank you!
Looks promising! I will test out on the next release. Cheers :)
Here's an example of the said feature: http://captain-slow.dk/2012/06/16/slic3r-0-8-3/