No solid infill when gap width is close to perimeter total width

[xoan]

Version

1.2.9-637-g62675a2b

Operating system type + version

Arch Linux 4.4.52-1-lts

Behavior

In a model with an horizontal gap in the border which width is close to the perimeter total width (perimeter width * num internal perimeters + external perimeter width), there is no solid infill in the previous layers.

The test case has a 1 mm horizontal gap. Print has 2 perimeters and default extrusion width is set to 0.55 mm, so perimeters are 1.10 mm.

Part of sparse infil can be seen in the screenshot.

Here is also the model in which I detect this issue. Gap is ~1 mm (0.999879 mm measured in FreeCAD, but OpenSCAD file is also provided by the author)

• Lego City train track compatible Curved by mtudury: http://www.thingiverse.com/thing:2104338

Also attached a picture of the print, even it is very subjective.

STL/Config (.ZIP) where problem occurs

• test.stl.zip
• Config: https://gist.github.com/xoan/ea2768b728b91e4624cdbf575030b3bd

[lordofhyphens]

My suspicion here is floating point rounding.

[alranel]

This is more a rendering issue than an actual issue. Did you try to print it? There's no actual horizontal gap. You can see the layer below because of the sharp way we render the extrusions, which leaves an unrealistic diagonal gap:

When infill_overlap is greater than zero (the default is 50%) infill extrusions go slightly beyond the upper layer, so they might become visible in an actual print:

Being this an actual or a visualization issue, I agree we should fix it by making solid infill.

[alranel]

To clarify, the actual extrusions look like rectangles ending with semicircumferences, so they are flat on top. We render them with a diamond section for performance reasons, so they have no flat top and these diagonal gaps are visible.

[xoan]

Yes, I printed the railtrack you can see in the last attached picture. It has the same dimensions that the test case, and you can see the «dashed» horizontal surface due the rectilinear infill, because the perimeter path is deposited in a non solid (and non continuous) surface.

I know that in an ideal scenario, infill should never been seen from outside, but the real thing is that it is complicated to achieve.

To be safe, a solution could be to have a minimun perimeter overlapping (maybe half of the perimeter extrusion width), and if this overlapping is lower, fire the solid infill routine.

[alranel]

Ah yes, I had even seen the picture yesterday, sorry. I commented without re-reading the post. The diagnosis still applies, as what's visible is caused by the infill overlap.

[xoan]

PS. I think I'm using the term «overlap» in a way that is not the correct: I mean the overlap between the two adyacent layers.

But even infill_overlap is set to 0%, the effect is still visible due the fact that the external perimeter in the next layer is deposited in a sparse infill, are you agree? :)

[alranel]

Generating solid infill isn't enough, actually, as it's still visible:

So I improved the logic for extra perimeters detection, which was actually supposed to cover these cases. Now a third loop will be added which looks much nicer:

(Note that extra perimeter detection is turned off in the config file you supplied; I recommend to turn it on.)

[xoan]

Solid infill is still visible, but the effect is not like if there is not this solid infill.

I think that both solutions can be living together: the default by fixing the issue like in your first capture, but leaving the chance to enable extra_perimeters if someone need more quality.

BTW, thanks :)

[alranel]

Both solutions need extra computation. So I prefer to only add the extra perimeters one instead of two...

[xoan]

Agreed!

[xoan]

Sorry, another test case in which the extra perimeters is not triggered.

02-battery-bracket-ng.stl.zip