Increase solid infill area to next sparse infill line

[Sebastianv650]

Version

Applicable to all Versions

Behavior

This is a problem I have since I own a 3D printer: If you have models which have more than one horzontal top surface only a few layer heights separated from each other, the print will have rough imperfections on the topmost layer due to the way Slic3r starts a solid infill over a sparse infill when the solid infill isn't connected to a perimeter on all sides. See the attached stl, a baseplate for my latest print as an example (scale to 5%):

Grundplatte.txt (rename to .stl)
That's the result:

If you choose a even more sparse infill type like cubic instead of rectilinear, it gets even worse. The reason for this is that the ends of the first solid infill layer, which is printed with bridging parameters, have nothing to stick to, so they curl upward when the print head switches direction. The next layers printed obove this jams into the ends, resulting in surface defects.
This problem also happens in a simmilar way when we have a shape like a cube, where you have a cylindrical hole in the top (not going all the way down). The 1st solid layer of this hole is printed over the sparse infill, if this is realy low it might even print completely over air.

My idea is to add a second condition to the infill area generation: Always extend the first defined area to the next sparse infill line printed in the last layer. This way, the ends have something where they can stick to when the print head turns into the other directions, so they shouldn't curl up.
See sketch for clarification:

In worst case (no infill or small part), it would extend the solid infill up to the next perimeter. The next solid infill layer can then be printed in the usual area, so no extension is now needed as it has already a surface it's printed on.

Feel free to ask questions, I'm not sure if I was able to describe exactly what's the point ;)

[bubnikv]

That has been on my list for a long time.

…

On Sat, Nov 4, 2017 at 10:37 AM, Sebastianv650 ***@***.***> wrote: Version Applicable to all Versions Behavior This is a problem I have since I own a 3D printer: If you have models which have more than one horzontal top surface only a few layer heights separated from each other, the print will have rough imperfections on the topmost layer due to the way Slic3r starts a solid infill over a sparse infill when the solid infill isn't connected to a perimeter on all sides. See the attached stl, a baseplate for my latest print as an example (scale to 5%): Grundplatte.txt <https://github.com/prusa3d/Slic3r/files/1443092/Grundplatte.txt> (rename to .stl) That's the result: [image: baseplate] <https://user-images.githubusercontent.com/10776877/32404126-5271f808-c14a-11e7-87e7-c3c447a7b778.JPG> If you choose a even more sparse infill type like cubic instead of rectilinear, it gets even worse. The reason for this is that the ends of the first solid infill layer, which is printed with bridging parameters, have nothing to stick to, so they curl upward when the print head switches direction. The next layers printed obove this jams into the ends, resulting in surface defects. This problem also happens in a simmilar way when we have a shape like a cube, where you have a cylindrical hole in the top (not going all the way down). The 1st solid layer of this hole is printed over the sparse infill, if this is realy low it might even print completely over air. My idea is to add a second condition to the infill area generation: Always extend the first defined area to the next sparse infill line printed in the last layer. This way, the ends have something where they can stick to when the print head turns into the other directions, so they shouldn't curl up. See sketch for clarification: [image: scan_0001_cut] <https://user-images.githubusercontent.com/10776877/32404178-27b5ffa0-c14b-11e7-98a9-3be600881306.jpg> In worst case (no infill or small part), it would extend the solid infill up to the next perimeter. The next solid infill layer can then be printed in the usual area, so no extension is now needed as it has already a surface it's printed on. Feel free to ask questions, I'm not sure if I was able to describe exactly what's the point ;) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#569>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFj5I0htP_gsB_8dlMzhKu88GHyuQG9Sks5szDA9gaJpZM4QR8ut> .

[jkuusama]

I was about to file the same issue when I found this. Just in case it helps, here is the same, described differently, including an artificial example where Slic3r is fooled to print on nothing.

Version

1.41.3+win64

Operating system type + version

WIn64 (irrelevant, slicer issue)

3D printer brand / version + firmware version (if known)

Prusa MK2S (irrelevant, slicer issue)

Behavior

• Describe the problem
  Internal solid layers are printed "in the air", resulting to curled filament. Curled filament results to layer shifts, when the nozzle hits it.

When there is need to print a solid layer inside a part, the solid layer does not extend to nearest infill. For example, consider a part that has a pit, say, a solid part with a hole that does not go all the way trough. The bottom of the pit is printed solid. The pit bottom layers are generated only to the size needed, resulting parts of it to be printed on empty space. The correct behaviour is to print to the nearest infill for support.

• Steps needed to reproduce the problem
  Create a part that has a pit. For example, a solid part that has a hole which does not go all the way trough. Slice it. Examine the first layer of the pit bottom.

• Expected Results
  Pit bottom supported or extended to nearest infill.

• Actual Results
  pit bottom printed to air.

  • Screenshots from Slic3r preview are preferred
    The part:
    

Infill settings, exaggerated to illustrate the issue:

Last layer before the problem layer:

First layer of the pit bottom, printed on air:

Is this a new feature request?
No.

Project File (.3MF) where problem occurs

Body2_0.2mm_PLA_MK2S.zip

[ulitiy]

For me it's #1 issue that could save up to 30% filament. Make 0% infill and use infill only where it's really needed for cosplay/decorative parts. There's no reason for people to use 20% infill for their Picachus.

Similary called checkbox "only infill where needed" only breaks the infill, IDK why it's even there.

[kingakristo]

Same problem which I hoped to be answered by someone from Prusa, maybe a video could help us to solve this issue for thousands of users... @josefprusa

[nburro]

I've had the same issue. PrusaSlicer 2.x correctly identifies the feature type as Bridge infill, so it seems like the logic would need to be applied specifically in those instances.

At the end of each bridging segment (or where a direction change is needed), the slicer would need to look at both the current layer and the layer below. Check if the end of the bridge is going to touch an existing extrusion on either layer. If not, look for to the next available extrusion (on either layer) beyond the end of the bridge and extend to it.

[dxstp]

@rtyr Any updates on this? I hoped this will be included in 2.3.1 :(
This issue causes bridges to start in mid-air, causing melted plastic blobs or it rips the model off the plate. Yet the solution seems to be simple: Either print a full solid layer before the bridge/infill island or extend the edges to the nearest last layer track underneath. Would be great to get this fixed after 3.5 years.

Workaround: Use the "print solid layer every n layers" or use the height range modifier and change the infill to 100% for the critical slices.

[lukasmatena]

@dxstp It has relatively high priority, but I will rather not promise it for 2.4.

[dxstp]

@lukasmatena Wouldn't it be the easiest to completely fill the layer under the first solid bottom layer after an infill layer, no matter what? It could be activated as an expert config setting if needed.
My hope is that this could be actually implemented more easily, without having to modify larger parts of the sources.

[foreachthing]

Wouldn't it be the easiest to completely fill the layer under the first solid bottom layer after an infill layer, no matter what?

No, just think about what it would do to print times, if it was a very large part. Also, what a waste of material.

[tracetechnical]

Wouldn't it be the easiest to completely fill the layer under the first solid bottom layer after an infill layer, no matter what?

No, just think about what it would do to print times, if it was a very large part. Also, what a waste of material.

I would rather have a print that completed without failure than a fast or efficient print. If it wrecks the part... then the whole thing is a waste of material.

[foreachthing]

I would rather have a print that completed without failure than a fast or efficient print. If it wrecks the part... then the whole thing is a waste of material.

Sure... but why not use a modifier in critical areas?

[tracetechnical]

Mostly because I would expect the slicer to be competent out of the box. For a commercial usecase like mine, time is money. I have neither the time nor the inclination to arse about having to second guess what the slicer will or will not do. Printing into dead space, causing lumps or other issues is directly opposed to being competent.

[dxstp]

@foreachthing

Wouldn't it be the easiest to completely fill the layer under the first solid bottom layer after an infill layer, no matter what?

No, just think about what it would do to print times, if it was a very large part. Also, what a waste of material.

The reason for sparse infills actually is having a fast and material efficient print. Otherwise we have to print the parts with no less than 20% infill to mitigate the impact of this bug - or lose a print completely. Both is much more wasteful than printing one solid layer which is properly attached everywhere.

Of course a smarter solution is possible, but alas, this bug is almost 4 years old. A pragmatic and simple solution which actually gets implemented seems to be at least something.

[dxstp]

PETG material curled up, then melting on the nozzle again and ended up with a plastic blob welding print and nozzle together.

Detail view, just the first bottom solid layer and the previous infill layer (15%):

[sslupsky]

This issue appears to be affecting support layers as well. Here is a screenshot showing several top support layers are entirely floating in mid air. I have not found a work around for this.

PrusaSlicer
Version:   2.4.0-alpha3+x64
Build:     PrusaSlicer-2.4.0-alpha3+x64-202109301500

Operating System:    Macintosh
System Architecture: 64 bit
System Version:      macOS Big Sur Version 11.6 (Build 20G165)
Total RAM size [MB]: 34,360MB
OpenGL installation
GL version:   2.1 ATI-4.6.20
Vendor:       ATI Technologies Inc.
Renderer:     AMD Radeon HD - FirePro D500 OpenGL Engine
GLSL version: 1.20

[dxstp]

@lukasmatena @bubnikv The original issue is still open in 2.4.0-beta1, the generated result looks exactly the same. The root cause is in the slic3r library, I already mentioned this issue in their Github too. However, this is regarded as a "feature request" and unlikely to be addressed by the lead developers ("pull request or bust").
Please consider giving this issue a high priority on your TODO list, as this issue dates back to 2014 and causes many subtle printing issues, ranging from bumpy surfaces to shifted layers and complete losses.

[lukasmatena]

@dxstp It has relatively high priority, but I will rather not promise it for 2.4.

Only thing that has changed is the fact that it will indeed not be in 2.4.

[Automatica-Mat]

What's happening with this issue? I've upgraded to the latest version today and still no change. It seems all that needs doing is to put a perimeter around the infill area before infilling?

[lukasmatena]

@Automatica-Mat Like I already said, it is quite high on the list. Doing an extra perimeter will not magically make it supported, it may help in some cases but not universally (it might bridge in your case, but hardly in what @dxstp posted).

[masterkyle]

Cura first draws a line around the area of the first layer. This allows the border of the layer above to connect instead of curling up. Please see the picture.

[pedjas]

Well, just to add one more vote for this issue to get higher on priority list as it indeed ruins prints.

[derpue]

Considering the speed in which the arachne engine was ported from cura, i personally can't understand why this issue (which isn't just only an annoyance, but a serious bug, resulting in failed prints, or the need to add more infill, thus wasting material and time) is so long open, especially when looking at super slicer (a fork of PrusaSlicer), which has the needed feature, called 'Supporting dense layer', at least since 2020.
https://github.com/supermerill/SuperSlicer/wiki/Dense-infill-under-solid-layer

With that feature enabled, we also need fewer bottom layers to get a quality surface over low infill, thus compensating the additional material and time needed for that layer, if not saving material and time.
Even more the "extra" area added around the needed area is smaller compared to the existing algorithm in PrusaSlicer, saving even more material and time:

Prusa Slicer:

(5% infill, print would probably failed)
SuperSlicer:

(4% infill)

Edit: So the code is there since 'years', you just need to grab it, as SuperSlicer is a form of PrusaSlicer i assume that shouldn't be so much work at it's the same codebase.
Edit2: just saw that that sugeestion was already done in may but mostly ignored

[FoX2V]

I will join the request to solve this problem .. after switching from cura to prusa, a lot of plastic was screwed up until I realized what the problem was, and later - many hours to find the right setting to fix this problem, feeling like a complete idiot because I can’t find the right setting in Prusaslicer (well, it can’t not be there) ..
but it turns out this problem has been known since 2017 and since 2017 in the course of the "solution" ... sad ..

Well, I would like to take this opportunity to thank you for the Prus slicer, because very nice to use this product

[NielschB]

This is a severe bug as it directly leads to failing prints and should not be too hard to solve. Having it open for more than 5 years now, that's just bad :(

[lukasmatena]

This should be fixed in 2.6.0-alpha5. Feedback is welcome.

[Ro3Deee]

în 2.6.0 a5, it doesn't work with lighting, adaptive cubic, support cubic infill (it works gyroid and all others, but with lightning, adaptive cubic, support cubiv does not ).

example on Gyroid (ok):

adaptive cubic (not ok):

support cubic (not ok):

lightning (not ok):

[vovodroid]

Still in the air:

[cimbalek]

In 2.6.0. Alpha 5 it doesn't work properly. It's in the air [1] and moreover there is no margin[2], so it resulted in broken print [3]. Maybe adding bridge perimeter (like the red line in [2]) at the edge would work, but I am not sure how I would implement it with more complex shapes

[1]

[2]

[3]

[Ro3Deee]

In 2.6.0. Alpha 5 it doesn't work properly. It's in the air [1] and moreover there is no margin[2], so it resulted in broken print [3]. Maybe adding bridge perimeter (like the red line in [2]) at the edge would work, but I am not sure how I would implement it with more complex shapes

what infill? is is cubic like în #569 (comment) ?

[rtyr]

From changelog:

Extend sparse infill #569

Another long-standing issue was connected to bridging solid infill printed over sparse infill. The shape of such infill islands was only determined by what was above, and the infill lines were often inadequately supported as a result, leading to mid-air extrusions and possibly failed prints. PrusaSlicer now extends the lines of the bridge infill so that their ends are supported by the sparse infill on the layer below. The bridge infill is now always using 'Thick bridges'. The new algorithm is NOT applied for Support Cubic, Adaptive Cubic and Lightning infill.

[pedjas]

From changelog:

Extend sparse infill #569

Another long-standing issue was connected to bridging solid infill printed over sparse infill. The shape of such infill islands was only determined by what was above, and the infill lines were often inadequately supported as a result, leading to mid-air extrusions and possibly failed prints. PrusaSlicer now extends the lines of the bridge infill so that their ends are supported by the sparse infill on the layer below. The bridge infill is now always using 'Thick bridges'. The new algorithm is NOT applied for Support Cubic, Adaptive Cubic and Lightning infill.

That is great news.

Will Slicer warn if infill that is used does not create proper support for upper leayers?

[rtyr]

Will Slicer warn if infill that is used does not create proper support for upper leayers?

We plan to extend supported infill patterns :). This was just changelog for alpha5 release.

[kubispe1]

I think we delivered this feature, so I am closing this thread. For specific bugs/requests were created own issues already and we are mosly working on them. Hope you like the feature it in the end of day. Thanks

[TylonHH]

As I searched for Bridge Infill maybe my bug is related to this feature
#10754