Concentric pattern not always concentric

[OhmEye]

On a circular layer, concentric fill used to produce concentric circles for the entire layer. I recently discovered that recent versions no longer do. I did a git bisect and found that the commit that introduced the change was 44c636a

Screenshots for test object https://github.com/OhmEye/Temp/blob/master/record_45.stl

Good concentric produced with commit 20229fc

Bad concentric produced with commit 44c636a

[cwarner711]

I have also encountered some strange behavior with the concentric fill pattern. Using the same *.stl file, when I change parameters like layer width layer height, or even more confusingly, brim width, I get a distorted pattern. Here is the pattern I would like to achieve:

http://farm9.staticflickr.com/8306/7993829241_4df31537a7_m.jpg

And this is the distorted pattern:

http://farm9.staticflickr.com/8303/7993829383_369e160257_m.jpg

(How does one import images into a thread?)

I am also having problems with getting complete fill with this pattern- I come close when over-stuffing the first layer, but still have some small gaps. The gaps always appear at the same position in the pattern, independent of where on the print bed I print the object, and appear to be related to how the geometry is sliced. Especially puzzling is why changing the brim width would distort the fill pattern...

[mesheldrake]

The problem seems to be with passing too small of a scale to Geometry::Clipper::offset()
Most of the time it looks like the scale being passed in is 1. That's too low for Clipper to have enough precision to clean up the artifacts of it's offset approach.
I hardcoded the scale for offset() to a few different values and got clean concentric paths on OhmEye's test case at scale=100.

[alranel]

@OhmEye, can you confirm this is gone too?

[cwarner711]

I can not figure out how to change the Geometry::Clipper::Ofset. Any
guidlines, or has this been picked up in the latest release?

Charlie

On Sun, Dec 23, 2012 at 4:10 AM, Alessandro Ranellucci <
notifications@github.com> wrote:

@OhmEye https://github.com/OhmEye, can you confirm this is gone too?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/700#issuecomment-11644304.

[mesheldrake]

@cwarner711 - this was a setting in the code, not a user setting, and it's been set to good high values in recent releases.

[cwarner711]

OK. I just recently downloaded 0.9.7, but haven't started using it yet (I
don't like to change things in the middle of a project). I am still using
0.9.3, and will not be ready to change for a week or so. I would suggest
you mark my original issue as "solved", and if I have further issues when I
switch to 0.9.7, I will create a new issue.

Charlie

On Tue, Jan 1, 2013 at 7:52 PM, Mike Sheldrake notifications@github.comwrote:

@cwarner711 https://github.com/cwarner711 - this was a setting in the
code, not a user setting, and it's been set to good high values in recent
releases.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/700#issuecomment-11798219.

[OhmEye]

I'm not ignoring this, just haven't had time yet to retest and confirm. I'll do when I can and report back. :)

[OhmEye]

I tried to do a quick test using the test object but got an error trying to add it. It will likely be a few days before I have time to look at this again.

Use of uninitialized value in subtraction (-) at /in/Slic3r/lib/Slic3r/Geometry.pm line 736.

Never mind, it was a corrupted copy of the STL. I redownloaded and with current git master am unable to reproduce this issue now so it looks fixed to me.

[mesheldrake]

Thanks for squeezing in that confirmation test.