Defects appearing when changing infill setting back and forth

[davesp8]

Version

v 1.3.0-dev

Use About->About Slic3r for release versions

For -dev versions, use git describe --tag or get the hash value for the version you downloaded or git rev-parse HEAD

Operating system type + version

Windows 10 home

Behavior

STL file is loaded into Slicer. In the 'Preview' tab you view the layers and all looks fine.
You decide to change the infill around a few times. For example, move it from 20% to 70%, then from 70% back to 0%.
In the 'Preview' you notice that little pock marks have appeared in some of the layers. The original form has not been maintained.
The only way to ensure you get a perfect print is to set the infill to what you want before adding your part, otherwise it may get errors.
I have had it where nothing changed but 4 out of 5 the pock marks appear.

Images:
Pock-marked wall in Slicer

Resultant print

Newly loaded part - no issues

Resultant no issue print

Closeup (just loaded into Slicer 100% fill)

Closeup (Change fill to 25% - three pock marks appear)

STL/Config (.ZIP) where problem occurs

pockmarks.zip

[lordofhyphens]

Interesting. By the way, your last picture does not show any defects, looks like a copy of the one above it.

[davesp8]

Hmm...should show a few, have highlighted them on the attached image.

…

On 15 March 2017 at 13:26, Joseph Lenox ***@***.***> wrote: Interesting. By the way, your last picture does not show any defects, looks like a copy of the one above it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3764 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APGbkVazsKcrVUVRX4FssJxwM-5iGse_ks5rl-cSgaJpZM4Md6ZT> .

[lordofhyphens]

Thanks. BTW attachments don't work from the email interface ;)

Thanks for editing your post

[alranel]

Here's the close-up of one of those defects:

[alranel]

This is caused by Layer::detect_surfaces_type() not being idempotent because of some numerical issue causing this loss. We should either try to fix the numerical issue or drop the idempotence of such method, recalculating more stuff.

[alranel]

After Layer::detect_surfaces_type():

This is caused by this collapse offset which was introduced in c7db2cb (#1431):

// collapse very narrow parts (using the safety offset in the diff is not enough)
float offs = layerm.flow(frExternalPerimeter).scaled_width() / 10.f;

Without the collapse we get a single continuous loop:

The collapse makes sense but it alters the external shape so makes the method idempotent. It should be moved to where we generate fill_surfaces instead.

[alranel]

I fixed this by forcing slicing again, so the slices are fresh. However after 1.3.0 I want to fix in a different way (move the collapse logic to where we generate fill_surfaces).