Overhang handling suggestions

[VanessaE]

3D printer slicer programs just do not handle overhangs very well, and as printable objects get more detailed, they demand more from the slicer and the printer to get things right. Printers are getting better, but slicers just aren't keeping up, and this really needs addressed. They've been a thorn in the side of 3D printer users for quite some time - seems like none of the popular slicers have good overhang handling (I've tried both Slic3r forks, KISSlicer, and Cura). Of course, only Slic3r can be considered for this particular Github issue, but I'm sure other slicer authors will want to use some of these ideas also.

Related issues: #328, #2158, and #2313

After doing a lot of testing, I've made a list of overhang settings and behaviors that I think should be added. I know you don't like adding new settings, but in this case I think it's unavoidable. These should all be applied to (and only to) partial overhangs, not bridges:

[Print Settings]

• Overhang corner speed - the idea here is to be able to slow down to infinitesimal speeds while rounding an overhanging corner, then speed up for the rest of the overhanging line (then repeat as necessary). Go slow enough and you can draw nearly-horizontal 90° corners in mid-air if you also have enough cooling. Obviously one could just slow down the whole print, but that wastes time and can have a negative impact on overall print quality. For the purposes of start/endpoints for this speed, I would define "corner" as the two line segments on either side of the turn, equal in length to say 3x the line width (so a "corner" would be the range of 1.5 mm before to 1.5 mm after the actual turn, if the line is 0.5 mm wide). This includes the overhang's anchor points (e.g. where the line deviates from the wall under it, and where it rejoins at the end of the overhanging perimeter). Suggested default: 5 mm/s.
• Overhang straight line speed - just as it sounds, the speed between corners. Slower is better, but not necessarily as slow as the corner itself. This speed should also be used between the overhang's anchor points and its first and last unsupported corners. Suggested default: 20 mm/s.
• Overhang acceleration - aside from the obvious effect of creating a sharper corner, the slower the acceleration, the less ringing you'll get at the corner. For a normal perimeter, a little ringing is fine, but on an overhang, even a little ringing can completely destroy the corners. This should be in effect for the entirety of the overhang, from just before one anchor point to just after the other, and all corners in between. Recommended default: 100 mm/s²
• Overhang line width - For overhanging perimeter lines that still have at least some overlap with the previous layer, wider lines tend to produce better surface quality on the underside of the overhang, but one surely does not want to use extra-wide perimeters around the rest of the part. Suggested default: "auto", 1.5 times the corresponding perimeter line width, but let the user plug in a specific value if they want.
• Overhang exterior first threshold - For any island that has overhanging perimeters, if the total length of the longest overhanging perimeter is less than this value, that island will have its exterior perimeter printed first. Any islands whose perimeter lengths exceed this threshold would have their exterior perimeters printed first or last according to the existing global setting. Small overhangs tend to work better with exterior perimeters printed first, but long overhangs (such as a beveled edge on the bottom of a project box) tend to warp less if the exteriors are printed last. My theory here is that, in the case of small overhangs, printing the exterior perimeter first allows it to cool into place, allowing it to "contain" the inner perimeters better, even if they would otherwise stay hot for too long, but doing interiors first allows them to keep the exterior perimeter hot longer, and allows them to cool and pull everything inward (and curl upward) more easily. On longer overhangs, the ends of the overhanging perimeter are merely far enough apart that they have no effect on whether the main overhanging line holds up well enough while it cools. Suggested default: 50 mm.
• A checkbox to force concentric infill for the unsupported parts of the overhang's bottom solid layers (with the user's normal solid infill pattern just inside of that), as this pattern of infill tends to produce better undersides. My theory here is two-fold: 1) long, narrow rectilinear infill concentrates too much heat at one end of the area, with the hot zone moving along as the infill is drawn, causing the overhang to want to curl sideways, while concentric spreads the heat fairly evenly, and 2) overhanging perimeters will droop some no matter what you do, so for a particularly steep overhang, the perimeters that rectilinear infill should anchor to just won't be where Slic3r expects, while concentric infill is already anchored at each "end" where the loops go in/out of the overhang. Global, super-thick walls have a similar effect, but that wastes filament. Suggested default: enabled. Maybe this function should just be hard-coded to always use concentric infill for these areas.

[Filament Settings]

• Overhang flow ratio - for overhanging lines that have no overlap with the previous layer (i.e. because they're too close to horizontal), less flow may be better, at least for some filaments (think ABS versus PLA). There will likely need to be a setting for these that is different from bridging flow ratio. As an aside, bridging flow ratio should be moved to filament settings, for the same reasons. Less flow of course would cool faster, but this would depend on the filament type, temperature, and cooling settings. Suggested default: 1.0 (what is is now). Note: this should be completely independent of the above "Overhang line width", so that it's possible to force a slight over- or under-extrusion without affecting the line spacing, if the filament needs it.
• Overhang fan speed - some filaments can't have the fan turned on all the time. Suggested default: 100%
• Minimum fan spin-up time (or distance) - fans need time to spin-up, and some filaments or print jobs can't have them on at 100% all the time, so they need to be turned on/up/down some distance before and after the endpoints of the overhang. Suggested default: 2 seconds or 50 mm.
• A threshold setting to decide how much of an overhang is needed (in degrees or percent of line overlap), before invoking the various above settings. Suggested default, 60° (basically what it is now).
• Height-over-bridge fan threshold: if the bridging or overhang drawing was invoked somewhere, and the current draw path crosses/draws on top of it (as when building more layers on top of the initial bridge/overhang), and the current layer is less than this height above its first lines, turn the fan on at bridging speed. This would be good for filaments that don't need a fan normally, except for bridging/overhangs and the first millimeter or two above them (some brands of PETG for example).

These two test models (especially the first one) are very good for evaluating these sorts of settings:
http://www.thingiverse.com/thing:1564848
http://www.thingiverse.com/thing:58218

By using enough global settings to simulate some of the above overhang-specific settings, good overhang quality can be achieved, at least with 0.2 mm layers. Here's an example of what I was able to produce (the settings, below, are somewhat conservative compared to what I might use in practice, should these suggestions be implemented):

Example config (this is what was used to produce the parts in the photo above - do not use for a real print, it'll waste filament and/or time): segfault-config.ini.zip

Another point of note, which doesn't need a setting but which is a ...ahem... corner case 😄

Aside from never putting a seam on an overhang, don't put one close to the overhang either (the above "criss-cross" override notwithstanding). For example, on the "XYZ" test cube pictured above (XYZ_20mm_calibration_cube.stl.zip), if you use the "Aligned" seam position, Slic3r moves the seam around, depending the features on the sides of the cube. For those layers that include the lower half of the "X" on the cube front, Slic3r consistently puts the seam on the lower right leg, inside right corner:

Red marks indicate the moves as they exist now, with the travel ending at the red "X" and printing proceeding forward and then to the right, as per the bent arrow, leading to a sharp, distorted edge at the overhanging corner that follows. Blue marks indicate the path I would have expected Slic3r to use. Of course, moving the seam as suggested there would move the distortion to the inset, but then it only affects a flat vertical surface, not an overhang. One's filament choice has an effect here, likely due to viscosity and related to print temperature (the white that I use is much trickier to get "just right", compared to the other colors).

Of note, after doing a whole lot of tests (thankfully without a whole lot of wasted filament 😛 ), one thing I've just about settled on is that as layers get thinner, the maximum overhang you can draw gets less and less. At 0.2 mm layers, I can do a full 30-85° overhang arch with only moderate curling, but at 0.1 mm layers, it loses corner quality beyond 45° (as expected), and starts to curl up too much by about 55° (i.e. the hotend knocks the part off the plate).

[VanessaE]

Regarding the quality of the undersides of the overhangs, I guess a detail pic is warranted. This is Atomic "Deep Black" PLA, printed with 0.2 mm layers, all extrusion widths locked at 0.4 mm, exterior perimeters first, and with lots of cooling. Photo was taken with a bright light pointed at the part, but I desaturated the image and cranked the contrast and brightness way up to make the details more visible:

Not visible in this image is that the middle one also exhibits the least amount of upward curl/warping. The ~63 second minimum layer time in the right two pieces was created by adding a sacrificial object to the plate that is set to print extremely slow to make it "waste time", so that the actual test part could print at normal speeds.

[VanessaE]

Is someone going to address this? It's been nearly a year.

[supermerill]

Some questions:

Using "Detect bridging perimeter" should already decrease the speed & increase the flow.

• Overhang straight line speed : should be already done in "Detect bridging perimeter", or not?
• Overhang acceleration & Overhang corner speed : same. A specific "perimeter bridge acceleration" is really needed or the bridge acceleration is enough?
• Overhang line width : may be difficult to do. My idea was to do the opposite. On my list.
• Overhang exterior first threshold : it's like activating "external perimeter first" when i detect small overhang. This may create extrusion inconsistency for the external perimeter and be visible on the print (as "bad quality"). If done only for overhangs, these one need to be separated from the perimeter, a seam (or two) may be visible... i don't know if it's worth it.
• A checkbox to force concentric infill: I think that's basically what i done with my enhanced "Extra perimeters if needed" in Overhangs & perimeters in briged area #4476, but printed before the external perimeter instead of after. (if i understand well).
• Overhang flow ratio : should be possible, i'll try.
• Overhang fan speed : difference with bridge fan speed?
• Minimum fan spin-up time : use a better firmware / modify it. Not the job of the slicer, imho. Also, it's impossible to know when a g-code command is done, as the printer can slow itself, or pause, or whatever.
• Height-over-bridge fan threshold : I'll see if it's possible. I've already added the opposite for infill ratio.
• never putting a seam on an overhang, don't put one close to the overhang either: I'll see if it's easy to change.

tl/dr:
easy things : Overhang flow ratio & Height-over-bridge fan threshold
hard things: Overhang line width & no seam near overhangs.
For the other ones, can you convince me?

note: @Tinchus2009 np, i've created the thread to have feedback. "separate bridge perimeter from perimeter generator" : i didn't.

[foreachthing]

Minimum fan spin-up time : use a better firmware / modify it. Not the job of the slicer, imho. Also, it's impossible to know when a g-code command is done, as the printer can slow itself, or pause, or whatever.

I wish this was a Slic3r "issue". My UM2 is always late with higher fan speeds. When a small bridge (< 15 mm) is coming up, the fan has reached its speed about when the bridge has been passed. So, if I print bridges, I need the fan to be at 100% - from layer 0 to the end....

[lordofhyphens]

@foreachthing #3308 Generally I agree though re: not being Slic3r's job to handle the minutae of fan speeds.

There's a post-process script there though that should be helpful.

[supermerill]

also kickstart != spin-up time
kickstart is to make it start at low rpm
spin-up time is to make it spin-up in advance.

[VanessaE]

Using "Detect bridging perimeter" should already decrease the speed & increase the flow.
Overhang straight line speed : should be already done in "Detect bridging perimeter", or not?
Overhang acceleration & Overhang corner speed : same. A specific "perimeter bridge acceleration" is really needed or the bridge acceleration is enough?

Overhangs are not bridges 😄 and really, nothing related to bridging should be used to handle overhangs, because they require an entirely different logic.

For example, a bridge segment (as defined in slicing terms) never turns a corner or goes around a curve; the perimeters are always long, straight line segments. Since it's unsupported, it's always drawn at "full" flow (or close to it, per the configured bridging flow ratio). Bridges necessarily always use rectilinear infill, though not always oriented ideally. Since they're always straight, a bridge can be drawn quite fast compared to an overhang, and one can exploit the filament's die swell and shrinkage characteristics in a bridge, as well, where one definitely wants to minimize their effects when drawing an overhang.

Overhangs that are especially steep (about 65° from vertical) do currently use what I assume is bridging flow, but shallower overhangs are just drawn as a simple wall. I now don't recall if bridging speed is ever used on an overhang. Overhangs don't seem to get any extra fan at all, regardless of angle.

Overhang line width : may be difficult to do. My idea was to do the opposite. On my list.

For larger parts, wider perimeter lines definitely produce better-quality overhangs, as seen in my photos. For small, detailed overhangs on super-thin layers (such as the edges of the front window in https://www.thingiverse.com/thing:2719434), narrower lines seem to be better.

Overhang exterior first threshold : it's like activating "external perimeter first" when i detect small overhang. This may create extrusion inconsistency for the external perimeter and be visible on the print (as "bad quality"). If done only for overhangs, these one need to be separated from the perimeter, a seam (or two) may be visible... i don't know if it's worth it.

Although I had it in mind to do this per-island, per-layer (so not switching order mid-perimeter), it occurs to me that it may be better to do this on a whole-mesh basis, so that the whole mesh has its perimeters first or not, for consistency.

That way, if you have a dozen assorted meshes on the plate (whether as individual files, or as copies, or if a single .STL brings in several meshes), but only one mesh needs this special treatment, then it would get handled automatically. Basically, always assume that the user can't change the existing global setting (in the per-part "Settings" dialog) without taking other steps that would ruin the project.

A checkbox to force concentric infill: I think that's basically what i done with my enhanced "Extra perimeters if needed" in #4476, but printed before the external perimeter instead of after. (if i understand well).

That looks like it covers it, yeah.

Overhang fan speed : difference with bridge fan speed?

As above. A bridge generally requires 100% fan speed (if the filament allows fan at all), while an overhang might do best with say 50%, with the rest of the part printed with say 10% fan.

Minimum fan spin-up time : use a better firmware / modify it. Not the job of the slicer, imho.

As mentioned above kick-start is not spin-up time. It's just a brief 100% burst to get over the "hump" to get a fan to start spinning at a low final speed.

Has to be done in the slicer - while it's possible to program a firmware to know how long a fan takes to spin up, and the firmware can look ahead in its receive buffer to predict and adapt to some things (such as changes in flow rate, as in Linear Advance), it's impossible for the printer to know when to start spinning up the fan in a real print.

On a complex or detailed model, your fans may need enough spin-up time to put a couple dozen line segments between the bridge/overhang where the extra airflow is needed, and the point ahead of it where the fan would need to start spinning-up. Problem is, the firmware only buffers maybe 8 line segments, so even if it did look ahead, by the time it finds the fan command and its successive bridge or overhang segment, it's already too late to start spinning it up.

For the other ones, can you convince me?

I hope I did 😄

[supermerill]

nothing related to bridging should be used to handle overhangs, because they require an entirely different logic.

They both draw "unsupported" feature. I will test with reduced speed & acceleration when printing your first test object to convince myself.

For larger parts, wider perimeter lines definitely produce better-quality overhangs

Do you know why (it should help me to know the reason behind that)? just a note, as it's unsupported, this extrusion should be round, so wider & deeper. Do you used "Detect bridging perimeter" when making these tests (for making my own)?

That way, if you have a dozen assorted meshes on the plate (whether as individual files, or as copies, if a single .STL brings in several meshes), but only one mesh needs this special treatment, then it would get handled automatically. Basically, always assume that the user can't change the existing global setting (in the per-part "Settings" dialog) without ruining the project.

You can use a mesh setting for that. I don't see the need to do it automatically (it can surprise the user in a bad way).

A bridge generally requires 100% fan speed (if the filament allows fan at all), while an overhang might do best with say 50%

Really? Do you have some stl/filament combination for me to test it?

It's impossible for the printer to know when to start spinning up the fan in a real print.

It is, that's the purpose of the cgode. I say to the printer to have the fan at X% at this moment of the print. I will try to make something on klipper.

I hope I did

Not yet ;-p

edit:

• overhang: any region of a layer with nothing from the layer below to print on and nothing neither an both side to print a bridge between them.
• perimeter : continuous loop line that follow the shape of the object
• width : size in the 2D plan of a layer (axis X & Y)
• deep : size in the Z axis
• bridge: special infill used to fill a riegion that is supported on both side but not on the middle. note: the current bridging algorithm can draw an overhang when there are a hole in the middle of the region, and it also use a bridge between the overhang part of a perimeter and the inner part.

[lordofhyphens]

@VanessaE @supermerill

Just stepping in to ask people to confirm terms (to make sure people aren't talking past each other). Thanks.

[VanessaE]

[...] confirm terms [...]

For the sake of this thread:

"Overhang" means any section of the print that temporarily leads out at an angle from a vertical wall, partly over air, turns one or more corners while out there, and has start and end points in the same general region of the print.

A bridge is a completely unsupported section that just stretches straight across the void between two opposing anchor points.

It is of course possible for an overhang to lead to a bridge, or to stretch a bridge between two overhangs, as in the case of the uppermost few layers that complete a horizontal hole.

For larger parts, wider perimeter lines definitely produce better-quality overhangs

Do you know why? (also , as it's unsupported, this extrusion should be round, so wider & deeper) Do you used "Detect bridging perimeter" when making these tests?

I am not sure why it works, but it does -- I'm not a fluid dynamics expert. 😄

Since most overhangs are less than the aforementioned 60° threshold (or 65°, or whatever it actually is), such overhanging extrusions are not round - they're partly flat, because at least part of the width of each line is supported by and squished down onto the layer underneath.

And yes, I always have "detect bridging perimeters" enabled.

That way, if you have a dozen assorted meshes on the plate [...]

You can use a mesh setting for that. I don't see the need to do it automatically (it can surprise the user in a bad way).

I suppose so, but asking the user to create/use a modifier mesh is a LOT more complicated than just having them turn on/off a checkbox. No, there's too much focus on modifier meshes, when the program could just do some stuff automatically.

To be honest, although they are useful, they're turning into a crutch, just as post-processing scripts are.

A bridge generally requires 100% fan speed (if the filament allows fan at all), while an overhang might do best with say 50%

Really? Do you have some stl/filament combination to back that?

It was a hypothetical example, however:

As I write this, I'm printing a new revision of the MK8 gear cartridge for my extruder, using Atomic Bright White PETG. This combination does well with a continuous 25% fan. As you may know, PETG doesn't bridge worth a damn without 100% fan, and it likes a goodly amount of airflow on overhangs as well, but not necessarily 100%. It's possible to "over-cool" PETG, leading to curling and warping, enough to pop it right off the plate.

It's impossible for the printer to know when to start spinning up the fan in a real print.

It is, that's the purpose of the [g-code]. I say to the printer to have the fan at X% at this moment of the print. I will try to make something on klipper.

The point is, if you insert M106 S255 just before a bridge line segment, of course you're demanding "100% fan now"... but your if fan is slow to spool up, then it won't reach anywhere near full blast until somewhere partly through the bridge, if it gets there at all. My fans, for example, take a bit over 1 second to get from 25% to 100%, and over 2 seconds to go from 0% to 100%, so smaller bridges basically get no extra fan, even though they need it. Consider this image from my ongoing print, for example:

See these spikes in the fan speed? In no real-world use will the fan ever make it to to 100% actual speed in response. All bots using commonly-available components have this problem.

The only way to combat that is to turn the fan up early. If that means a segment of the part ends up with the fan turned up continuously (i.e. if turning the fan on early means doing so while it's in the middle of a preceding spike), then so be it. At worst, you'll get a few extra seconds of fan.

That is, unless you're using a valve-controlled hose leading to a big, remotely-mounted, always-on fan, or a tank and air compressor. 😛

I hope I did

Not yet ;-p

I guess I need to try harder 😛

[supermerill]

I've made a test (it's the top part of the 55° to 85° test):

first (left) is my default settings + Detect bridging perimeter
second (center) is the same than 1 + my "Extra perimeters if needed"
third (right) is the same than 1 + i reduced the speed/acceleration from 20/1000 to 5/100

if you have a config file with good parameters for ovehangs, i'll be happy to try it.

for the fan speed start-up time, I've addressed that here : Klipper3d/klipper#474

[VanessaE]

Well that's at least consistent with my initial experiments.

[curiouspl2]

Hello.
Got new idea about handling overhang volume compensation (because it is one of main issues causing overhangs to be printed with not enough material , causing them to curl up)

Main problem of handling overhangs currently is that it is difficult to tell if overhang is 'unsupported' - geometries of vector paths on both layers need to be taken under account. Analysis of gcode is difficult and does not allow to f.e. change arc or circle to a segmented object easily,
so all the flow/volume correction should be done before gcode export phase.

Also extrusion widths vary. It might happen that extrusions below path we analyze have weird shapes (like being perpendicular to our path) and all this makes computation and segmenting complex, and devels pulling out their hair out, while attempting to code algorithms for inter-layer analysis...

but there is simpler path :)

after slicing there is volumetric path (not yet gcode) being created for each layer - used also for preview.
It contains data about tool path and volume of extrusions.
From this data 2d array of volume can be computed, for each layer. Note we do not need to keep
all such layers, we just need to keep two of them, for adjacent layers, in memory.

Having such crude volume maps for two layers , 'correction' layer can be computed using various methods. Just difference and threshold tells much. Areas with no support will mean bridging and are
solved by bridging algo. Rest will compute 'correction' layer map .

Now this map can be used to segment and correct overhang extrusions at next layer, as it represents
missing volume in Z plane. This means this volume can be added to toolpath , and this added volume
does not change width of the extruded lines (because volume will fill voids layer below).
Note it does not involve comparing geometries, and even allows situations like partial corrections, like
in case when single map pixel will span over f.e. two perimeters, correction of first perimeter will subtract just part of correction from the pixel and correction for another perimeter will subtract another.

Also as we are not dealing with gcode, we know width and extrusion volume of each feature, so
we can simply apply corrections and repeat process with next two layers.
Also geometries of artifacts causing volume correction do not matter, just fact of missing volume in
specified area.

And as another benefit - array map can be of any defined resolution, so it is predictable computationally (does not depend on model size) and allows corrections to be computed in reasonable time. If resolution will be changed, this time will change aswell, allowing to choosing memory/time vs correction accuracy compromise by user.

I would like to hear more comments on that as this is one of very pressing issues causing
even simple prints to fail and having only very tedious workaround thru modifier meshes route which
also breaks perimeters, so produces very ugly results.

[supermerill]

@curiouspl2

change arc or circle to a segmented object easily,

stl & most 3D models store only triangles, so no "arc" or "circle" can exist.

Do you propose something similar to my "over-bridge compensation" in my fork, but also for overhangs (perimeters)?

[toskium]

Anything new on this issue yet? I see this being requested and marked duplicate to the original issue but nothing regarding putting this on the development roadmap.

[supermerill]

@toskium see #4717 for my part.
Not on the roadmap of a dev (as far as i know) for the other things.

[zbrozek]

I'm struggling to print some parts in ABS that have overhangs right now. In particular I would love to have overhang-dependent fan speed. My parts are super brittle if I print with fan all the time, but there's no way to get a decent overhang without it.

Much like we have filament cooling options based on layer time, I'd love to have them based on "supportedness" too.

[VanessaE]

@supermerill has implemented a number of these changes in his SuperSlicer fork.

[ciordia9]

@VanessaE Not to bug-jack, I've been looking for specifically a fan power during overhangs for ABS. I've got a current build of SS but I didn't see it in there. Have to read through SS a bit more carefully to see what else of your requests have been baked in. Good stuff!

[pass75]

Vanessa, I landed to this this post because I was looking for the same specific overhangs settings in PrusaSlicer. I totally agree with you that overhangs are probably the worst scourge of 3d printing and are underestimated by slicing programs. I recently discover some of them were implemented in SuperSlicer. Thank you for your efforts in supporting this. One note: reading your posts I was impressed by your skills and competences: you should definitely take part in SuperSlicer developer team! Greetings from Italy.