Infill modifiers can create unwanted seams in top and bottom layers

[adamdport]

Version

2.3.0+

Operating system type + version

Mac OS 11.2

Behavior

An infill modifier can result in seams in the top/bottom layer pattern

• Steps needed to reproduce the problem

It doesn't seem to happen for every shape/stl, but I've attached project files and an STL where it can be recreated.

1. Add the STL to a project
2. Set the infill to 0%
3. Add a box modifier
4. Set the infill for the modifier to 15% gyroid
5. "slice now"
6. The very top and very bottom layer do not have seams, but every other top/bottom layer does (see attached photo)

• Expected Results

Infill modifiers should not affect top/bottom layers nor add seams

• Screenshots from PrusaSlicer preview are preferred

Is this a new feature request?
no

Project File (.3MF) where problem occurs

Archive.zip

[rtyr]

This issue is similar to:
#3846

The way the modifier volumes work is they split the object into pieces, which are sliced independently.

[ledvinap]

Isn't there phase when compatible expolygons get merged? More aggressive (or configurable) merging will help in other places where 100% infill is printed separately,

[mws-rmain]

Same issue.
My modifier was only applied to alter infill - it has no entry under 'Layers & Perimeters' - therefore my expectation is it would have no effect on layers & perimeters. Unnecessary seams on top & bottom are cosmetically ugly but far more importantly: the 'seam' created extends down through ALL layers, including infill. The 'seam' then becomes a potential weak point in the entire assembly. The reason I added a cylindrical modifier was to mechanically support a hole with solid infill. This bug compromises mechanical characteristics I was intending to augment. Interestingly, the boundary between the cylindrical modifier & the part body DOES NOT appear to create a seam in the perimeter in the picture below, only in the top & bottom layers.

It's not really relevant how modifiers currently work. The way they currently work is compromising at least one of their intended functions.

[bubnikv]

@adamdport
I cannot remember the details now, but I believe I have fixed that in current master (the upcoming PrusaSlicer 2.4).
The current master processes your model without splitting the infill regions.

@ledvinap

Isn't there phase when compatible expolygons get merged?

Indeed. However only regions that have the same infill parameters are merged, including extrusion width and extrusion speed.

@mws-rmain
Please attach your 3MF, so we may retest.

[mws-rmain]

Attached ZIP contains my 3MF.
Is there a timeline for release of 2.4?

spacer block.zip

[rtyr]

It is OK on current master.

[mws-rmain]

Thanks, that looks great.
Is there a release schedule for 2.4?

[bubnikv]

Fixed in PrusaSlicer 2.4.0-alpha1.

[bubnikv]

Is there a release schedule for 2.4?

As soon as the change log is whipped up and the worst offenders on current master are fixed :-)

[robustini]

The problem has been fixed if the modifier only contemplates infill, but if you modify the perimeters instead it gives the known problem.