Gapfill in bridge areas defeats bridge detection for supports

[lordofhyphens]

Version

1.3.0-dev 15fe0b6

Behavior

If a bridge includes gap fill, the bridging perimeters are treated as an overhang for the purpose of support generation. This leads to supports that are very difficult to remove (and probably aren't necessary).

With gapfill:

Without gapfill:

STL/Config (.ZIP) where problem occurs

example.zip

[lordofhyphens]

Since we have variable-width perimeters, perhaps we can see if it possible to replace the gap fill between two external perimeters with a single extra-wide perimeter instead of gap fill?

Another possibility is to split the support in half so that it can be removed in 2 pieces?

[wpwrak]

The support may indeed not be necessary. I had Cura print an earlier version of this (although with an incorrect nozzle size it insists on using, 0.3 mm instead of 0.4 mm), it omitted the support, and the result was good.

The main problem here is that, using honeycomb and "don't support bridges", the support is fused solidly to the base (and possibly also to the walls), so it's very hard to remove. I basically had to carve the hole open (damaging the delicate base).

[Tinchus2009]

@lordofhyphens I was just about to post a similar report, I didnt noticed the gap thing, but you are right there. My report was going to be almost exactly like this: support is being created in places where actually is not needed. y though was that there was a bug in the "dont support bridges option" . And no, actually supports like the ones in your example are not necesary and right now are wasting a lot of time because of support being created for the top of holes for example, and if those holes are at some high... ike 100 mm, you have tallllll unnecesary supports. I have accounted in medium models a waste of 10, 15 and 20 minutes because of this issue

[bubnikv]

If a bridge includes gap fill, the bridging perimeters are treated as an overhang for the purpose of support generation.

Slic3r uses a bridge flow for bridging infills (if it detects the bridges). If enabled, it uses bridging flow for perimeters, which are supported by less than half their width. This applies for the perimeters on your examples, if the option "detect bridging perimeters", named "overhangs" in the config is enabled. Now the bummer is, the "detect bridging perimeters" is not performed over the gap fill. I will put that on my list, but the list is already quite long.

This leads to supports that are very difficult to remove (and probably aren't necessary). The main problem here is that, using honeycomb and "don't support bridges", the support is fused solidly to the base (and possibly also to the walls), so it's very hard to remove. I basically had to carve the hole open (damaging the delicate base).

Slic3r does not calculate the bottom interfaces correctly. You may try the current master from the Prusa3D fork, the supports shall be all right in this regard, at least with PLA the supports are joy to work with, PET still ok, but ABS more difficult as usual.

The support may indeed not be necessary. I had Cura print an earlier version of this (although with an incorrect nozzle size it insists on using, 0.3 mm instead of 0.4 mm), it omitted the support, and the result was good.

I am not quite sure whether Cura applies the bridging flow. Even S3D does not apply the bridging flow, so the bottom surface is drawn with threads with usual width and height, which unsupported will turn into round threads of small diameter.

My report was going to be almost exactly like this: support is being created in places where actually is not needed. y though was that there was a bug in the "dont support bridges option". And no, actually supports like the ones in your example are not necesary and right now are wasting a lot of time because of support being created for the top of holes for example, and if those holes are at some high... I have accounted in medium models a waste of 10, 15 and 20 minutes because of this issue

This is more difficult than it seems. Slic3r tries to detect ANY overhang, no matter how small it is, and supports it. The same applies for Cura I believe. Simplify3D works differently, it samples the model with rays at a regular grid, therefore if there are just tiny overhangs, with high probability they will be missed by the regular sampling. Is it good or bad? It really depends on the model. For example, take the 3D benchy model and enable automatic support generator. While the model is perfectly printable without supports, any slicer known to me will generate supports all over the place, with the exception of Simplify3D due to its regular sampling.

ike 100 mm, you have tallllll unnecesary supports.

That is another issue. Most slicers do not do ensure the stability of supports. Simplify3D and my new supports in Slic3r ensure some stability by projecting the support zig-zag lines into a regular grid, thus ensuring at least the minimal cross section of the support towers.

…

On Tue, Jan 24, 2017 at 10:57 PM, Tinchus2009 ***@***.***> wrote: @lordofhyphens <https://github.com/lordofhyphens> I was just about to post a similar report, I didnt noticed the gap thing, but you are right there. My report was going to be almost exactly like this: support is being created in places where actually is not needed. y though was that there was a bug in the "dont support bridges option" . And no, actually supports like the ones in your example are not necesary and right now are wasting a lot of time because of support being created for the top of holes for example, and if those holes are at some high... ike 100 mm, you have tallllll unnecesary supports. I have accounted in medium models a waste of 10, 15 and 20 minutes because of this issue — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3672 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFj5I7HaZzXDUT2ghEj9dEVyF9mFH7ouks5rVnPOgaJpZM4LlCWP> .

[VanessaE]

Is something getting done about this soon? It's been over 2 years....