Infill sometimes does not meet perimeter

[OhmEye]

Sometimes infill does not fully reach the perimeter and leaves a gap between the fill and the wall. This can change with object orientation. Here is an example plate with the same object oriented 2 ways.

The config used was http://ohmeye.com/download/debug/slic3r_infill/perimeter_gap_config.ini The STL used was http://ohmeye.com/download/debug/slic3r_infill/x25_isolator.stl The version used was current stable.

Here is a solid fill layer, notice the fill for the object on the right leaves no gaps at the perimeter, it looks fine. However, the infill on the left object has a gap at the left side of the large hole.

Here is a 33% hex fill layer, notice the infill does not meet the wall on the upper right curve of the left object. The copy on the right looks fine.

Here is a bridge layer, the layer between the hex fill and solid layer, notice the same gap between the fill and the wall at the upper right on the left object. The copy on the right looks fine.

[wgbartley]

I am seeing the same thing, and orientation does seem to affect it to a considerable degree.

Version 1.0.0RC3

[ledvinap]

Seems that I have similar problem - first solid layer after infill does not touch perimeter: This occurs in 1.0.0.RC3 and master.

here are files to reproduce this: https://drive.google.com/folderview?id=0B9HM4UOKDQBLakx1Q1R0MWZPZUU&usp=drive_web

[qharley]

I am working on upgrades on my machine and thought I had some play somewhere...

I also see this phenomenon currently

On Tue, Mar 25, 2014 at 1:09 PM, ledvinap notifications@github.com wrote:

Seems that I have similar problem - first solid layer after infill does not touch perimeter: [image: cover]https://f.cloud.github.com/assets/2318015/2510868/cb230718-b40d-11e3-9cb0-824cc31c0acc.png This occurs in 1.0.0.RC3 and master.

here are files to reproduce this: https://drive.google.com/folderview?id=0B9HM4UOKDQBLakx1Q1R0MWZPZUU&usp=drive_web

Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1803#issuecomment-38552218 .

[OhmEye]

Orientation and shape have a lot to do with whether this happens or not. It's become much more annoying than I expected, I have to visually inspect very carefully with a viewer before printing, and usually cannot prevent it so have to choose between the effort or just using another slicing app. I haven't noticed any obvious correlation between specific orientations yet, only that changing it can change if or where the problem happens.

[ledvinap]

Here is rendering of slic3r surfaces for layer7: Perimeters are green, infill grey, pink areas are small gaps, red are gap fills. This pattern starts on layer 2...

Full layer is here: https://drive.google.com/file/d/0B9HM4UOKDQBLUC1RdkhNWXBBSXM/edit?usp=sharing

[alranel]

Thank you @ledvinap. It should be easy to fix. I'll look into it.

[alranel]

@ledvinap, your test case looks different. The gap is actually a narrow strip of internal infill generated by the propagation of the above walls. And yes, something can be improved there since such a narrow sparse infill is useless and slow...

Still trying to isolate @OhmEye's issue.

[ledvinap]

I'am sorry, i forgot to comment here; #1921 is just feature request and is probably not related to this one. Then I was looking at @OhmEye's problem and only pasted image for reference ...

[alranel]

Ah right, I hadn't seen #1921 yet. :)

[AJRepo]

While playing with settings on Slic3r noticed in xs/src/PrintConfig.hpp the default value for

this->first_layer_extrusion_width.value = 200;

which creates this effect. Setting the value to 100% fills the gap better. The image below shows 200% (the default) on the left and 100% (override) on the right.

[AJRepo]

As I look closer at the bug report I see that this happens on all layers, not just the first one. Looking more closely, I can get better gcode results on non-first layers if I put in 100% for perimeter_extrusion_width settings instead of the default (0).

I'm new to using slic3r? Is this a new issue that started after either of the two following commits?

commit b9793b3f ( 2014-01-03 00:34:30 +0100 1223) this->first_layer_extrusion_width.value = 200;

commit ce984ef7 ( 2014-03-24 17:52:14 +0100 690) width => ($self->config->first_layer_extrusion_width || $self->regions->[0]->config->perimeter_extrusion_width) ;

?

[ledvinap]

This is nasty bug ;-) It's aparent here: This is state before https://github.com/alexrj/Slic3r/blob/master/lib/Slic3r/Layer/Region.pm#L137 purple - @last_gaps blue - @gaps green - @last gray - @contours, @holes

@last_gaps polygon is highlited.

my $diff = diff_ex(
       offset(\@last, -0.5*$pspacing),
       offset(\@offsets, +0.5*$pspacing),
);
push @gaps, @last_gaps = grep abs($_->area) >= $gap_area_threshold, @$diff;

this diff creates very thin part (that is not rendered in svg) attached to larger gap. This way area test is passed and after @last = @{diff(\@last, [ map @$_, @last_gaps ])}; part of fill area is cut away.

Fix should be trivial (offset2 or safety offset will do)

[ledvinap]

Maybe the logic here is not optimal - it could be better to first find self->thin_fills (which correctly handles this polygons) and subtract only thin_fills from fill surface. Filling algorithm could then handle all unfilled space, maybe it could do better job. Or at least discarding of thin areas will be done closer to actual infill code.

Another problem is that last_gaps (for infill narrow areas) is found using perimeter parameters. Maybe it should use infill spacing for this round?

[OhmEye]

The bug I reported wasn't a gap fill issue, it's about the infill pattern not extending all the way to the perimeter. The resulting gap isn't part of the object geometry, it's an artifact of the bug behaving as if the perimeter is inset from it's actual position.

[AJRepo]

OhmEye: The Slic3r default setting of 200% affects both the zoomed area I provided as well as the area you are referring to in your last comment . Setting Perimeter=100% and FirstLayer=100% creates an infill pattern which extends all the way to the perimeter AND fills the gaps (see images below)

[OhmEye]

That's interesting, because I do not duplicate your results, and also because I normally have all the widths in the advanced tab set to fixed mm values and only have them all set to 0 in my example preset to reduce the number of differences from default.

If I understand you correctly, the gap should disappear when I set print settings>advanced>first layer to 100% ? In my test the only effect is on the first layer and layers 13 and 6 look identical to my examples. Or do I need to apply the patch to the code? I'm skeptical, since your pics have different fill settings from mine so I'm not sure what else has changed. (fill angle and direction are different, and I have already determined that angle and orientation change if/where this issue occurs.)

What should I do to try to reproduce your results?

Edit, I just realized I left out something that turns out to be significant. I always split plated STLs, so all the objects are individual, I did not note this as a step. I see the gap does not occur on this particular plate if I leave the STL intact, but does if I split it. I will look for an example to reproduce with a single object instead of a plate, I know I had one last week, just need to recall which and find it.

[OhmEye]

Here is an example with a single small object http://ohmeye.com/download/debug/slic3r_infill/lens.stl

Notice the fill on the upper right does not meet the perimeter

Next layer, same story

Top layer, the problem happens on both the left and right sides, not just the right side

[AJRepo]

There are two changes that you have to make

1. First_layer = 100%
2. Perimeters = 100%

If I make those two changes, set layer height to .25 (to match yours) and leave everything else as defaults I get infil to the perimeters.

(Aside: For some reason my layer 61 is your layer 62, and on down. I don't know why. )

[qharley]

Does this mean that setting it to zero will not create the right output currently?

Sent from my iPad

On 11 Apr 2014, at 6:18, AJRepo notifications@github.com wrote:

There are two changes that you have to make

1. First_layer = 100%
2. Perimeters = 100%

[image: slicer_adv]https://cloud.githubusercontent.com/assets/7245631/2676151/ce1b8d62-c12f-11e3-9948-3477e0c6eb7b.png

If I make those two changes, set layer height to .25 (to match yours) and leave everything else as defaults I get infil to the perimeters.

[image: lens61]https://cloud.githubusercontent.com/assets/7245631/2676155/f19cda84-c12f-11e3-98b0-fd7f8ca00f53.png

[image: lens60]https://cloud.githubusercontent.com/assets/7245631/2676156/f19ef94a-c12f-11e3-8af5-5275ea5a0854.png

Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1803#issuecomment-40169509 .

[OhmEye]

ok, The gaps are gone with just changing perimeter width to 100%. Changing first layer width makes no difference here to the gaps. Also, the infill pattern is very different between 0 and 100% for perimeter width.

I will test some more, since I never use percentages for widths since it's unclear what they are percentages of, I always use explicit mm values like 0.5mm. This is interesting result though!

[AJRepo]

Changing first layer width makes no difference here to the gaps.

Correct - here we're looking at layers ~60. But also look at layer 2. When I looked at your original .STL I got the missed perimeter effect on the first layer (layer 2) unless I made both changes. That's what led me to find the commits I referenced above that specified the defaults=200%.

[ledvinap]

The bug I reported wasn't a gap fill issue, it's about the infill pattern not extending all the way to the perimeter. The resulting gap isn't part of the object geometry, it's an artifact of the bug behaving as if the perimeter is inset from it's actual position.

Yes, but gap fill is cause of infill problem. Try slicing with gap fill speed set to zero - infill will be ok.

Gap filling creates polygon with very thin artifacts (probably rounding problem) that causes problems in rest of the code ...

[OhmEye]

I don't think that disabling gap fill is an acceptable workaround since it results in worse results and often much larger gaps are unfilled. I'm unable to use stable branch for a lot of work due to #1750 and unable to use master branch in many cases due to this bug and #1090 so am just trying to report as best I can.

[ledvinap]

This bug is easy to fix. I was just illustrating that is is caused by gap fill. As temporary fix, change https://github.com/alexrj/Slic3r/blob/master/lib/Slic3r/Layer/Region.pm#L112 :

                        my $diff = diff_ex(
                            offset(\@last, -0.5*$pspacing),
                            offset(\@offsets, +0.5*$pspacing),
                            1
                        );

(enable safety offset)

[alranel]

I fixed this in the stable branch by enabling safety offset. I also wrote an ugly regression test - better ugly than none.

Regarding master branch: @ledvinap, I need to study your proposal more. Do you have a test case showing the need for that change, or can you help me understand why it would be better?

[ledvinap]

For example slicing @OhmEye's x25_isolator, medial-axis does not always find gap fill around holes. Current implementation ignores gap fill candidate areas in further processing. If only filled gaps are removed, the infill created looks better (but there are few cases of rectilinear infill crossing itself. It is probably unrelated issue).

(images are for same layer, but may be from different part)

Without proposed change, there will be gap between hole and perimeter on right

[alranel]

@ledvinap, I implemented it my way. I hope you don't mind! Idea was good indeed. I'm just sad because these things are not easy to test in an automated way. Any comments?

[AJRepo]

What do you mean by "I fixed this in the stable branch by enabling safety offset?" Do you mean the new constant: INSET_OVERLAP_TOLERANCE?

[ledvinap]

@AJRepo : https://github.com/alexrj/Slic3r/issues/1803#issuecomment-40177917 There is third parameter to diff to apply safety offset - subtracted region is slightly enlarged to avoid rounding artifacts.

[alranel]

I finally managed to write a regression test, so this issue can be closed. This is how the test object looks like now in master branch:

[kefir-]

@alexrj, in your picture it looks like there is a double line in the top left corner, is that a problem?

[alranel]

@kefir-, I'm almost sure it's a rendering "feature" of gcode.ws thickening the last segment (it changes when moving the slider).