Interesting. I wonder if this issue occurs when using adaptive layer height, when the layer height drops to, say, 0.12 mm at portions of a print?

P.S. It would be helpful for the OP to include the project file so that others can test the model.

@Ergonomicmike

I decided to check this bug in Prusa Slicer and QIDI Slicer. They don't have this
Problems.

They do a perfect job! Here is my test file: https://drive.google.com/file/d/1xlRdgrJJVd9smNrEmeQhDjCTk3WDX8Ry/view?usp=drivesdk

Here's the same test file in QIDI slicer, everything is perfect:

Related?
#5861

@otede

Maybe it's a problem of the same order!

I have heard about it that there is a cooling problem on the overhangs.

My problem with slowdowns when printing in layers of 0.1, 0.12....

What are your overhang and outer wall speeds and what line width are you using for your outer walls?

OP, please share your ORCA project file.

@staal54a @otede
https://drive.google.com/file/d/1xlRdgrJJVd9smNrEmeQhDjCTk3WDX8Ry/view?usp=drivesdk

@staal54a @otede https://drive.google.com/file/d/1xlRdgrJJVd9smNrEmeQhDjCTk3WDX8Ry/view?usp=drivesdk

Even for 0.2mm layer height, I dont think the slow for overhang is working properly. I found that both the 10%-25% and 25%-50% affect your overhangs speed. This shouldnt be the case right? (also if you look at the result for when I changed 10%-25%, you could see 2 lines with different speed stand out)

So I'm not sure how the slicer views walls/lines of extrusion. But, if the lines are viewed not as perfectly flat rectangles but blobs with more material in the middle and less towards the outside, then I'm not sure the 0.1mm behavior is incorrect. When you have a lower layer height and no change in line width, you by definition have less of a steep overhang.

To try to show it wasn't an issue with layer height, I left your 0.1mm layer height and changed the line width to 0.3mm and it sliced properly and showed all chamfered surfaces as overhangs. Note that the percentages are not angles of the overhang but rather how much the overhang is supported by the wall below which is a function of not just the geometry of the model, but also the layer height and line width.

As for the striping, my guess is you found a perfect edge case with this model and your settings where the parameters are just on the border of being an overhang and, due to the circular nature of the model and maybe some rounded values, a few walls cross that threshold and are seen as overhangs.

A better test would be to see if you could recreate the striping on an overhang with straight walls, not curved. If you use one of those overhang tests, it should also reveal what angle in the geometry is viewed as an overhang based on your layer height and line width.

See above how the overhang test has overhangs applied correctly (it starts at the 50 degree mark on the overhang test, but the test only goes in 10 degree increments). Please note that the green bands on the sliced preview window are due to your small perimeters speed and threshold settings and unrelated to the overhang setting.

@staal54a So basically the entire implementation of slicing overhangs is broken in Orca?

@staal54a So basically the entire implementation of slicing overhangs is broken in Orca?

I won't say there is nothing wrong with it (there are some issues I and several other people are having related to bridging and overhang detection conflicting) but in terms of this specific issue and what has been presented on this bug report so far, I haven't seen anything that leads me to believe the implementation is broken. It just seems it does not work the way you want it to. The approach by Orca (which is taken from Bambu Studio which it is forked from, don't know about further derivatives like PrusaSlicer) is simply how much of an extrusion is not supported by a previous layer, not what the geometry of the model is (though the geometry does play into it as a factor).

The question/conversation about whether this is the best approach versus something like Cura which, I think, just allows setting an overhang angle based solely on the geometry of the model, is certainly a fair one to have. Though just from the standpoint Orca is a direct fork of Bambu Studio, and Bambu Studio implements the percent not supported method, I doubt this will change for Orca Slicer. However, all of this conversation would be more of a new Feature Request/Enhancement and not a bug (at least based on what's seen in this thread SO FAR).

Also, to my point before about lower layer height meaning layers are more supported (which in Orca means they are viewed as less steep overhangs), here is a Reddit post that contains a basic picture showing why layer height can affect overhangs. PLEASE note that the poster assumes layers are rectangles which I'm not sure is how slicers view it so don't pay attention to the numbers in the graphic since they could be inaccurate, just see the picture for a high level overview of what's happening: https://www.reddit.com/r/3Dprinting/comments/fgl7qu/made_this_graphic_on_why_layer_height_affects/

@otede
The problem is that when reducing the layer height from 0.2 to 0.12, 0.10, 0.8 Orca disables the slowdowns on overhangs.

Other slicers such as Qidi Slicer, Prusa Slicer do not have this problem. They work correctly with overhangs even at layer height 0.08.

@staal54a
Theoretically you say everything right.

But practically I can't print a part with 0.1 layer height without slowing down on overhangs.

As a result, using Orca I get a defective part, while using Prusa/Qidi I get a perfect result.

@staal54a Theoretically you say everything right.

But practically I can't print a part with 0.1 layer height without slowing down on overhangs.

As a result, using Orca I get a defective part, while using Prusa/Qidi I get a perfect result.

Simple as that! Best yet, there's no response on this from Orca devs. And the issue is still present in the recent dev builds I'm not sure what they expect to happen.

Yep I am having this issue too. With lower layer heights it doesn't recognize them as overhangs, and even with 0.2mm it is still hit or miss, especially with sharp corners that overhang. It is making it difficult to use Orcaslicer. Can we also switch to using overhang angles instead of the overlap %? I find that the overlap percentages don't really work, and don't make intuitive sense.

Here's an image of a test part sliced with 0.2mm layer height. 10mm/s for all overhangs. You can see it misses the corner even though it has the same overhang percentage.

Here's the same thing but changed to 0.12mm. Even with setting all the overhangs to 10mm/s, it won't slow the shallower ones down at all.

@staal54a Theoretically you say everything right.

But practically I can't print a part with 0.1 layer height without slowing down on overhangs.

As a result, using Orca I get a defective part, while using Prusa/Qidi I get a perfect result.

@Start4up Can you upload your PrusaSlicer project file where it slices your test model as you want? That would be useful to have as a comparison against the Orca project and potential differences in their implementation. For example, Orca's most "shallow" overhang step is from 10% to 25% overhang, but I'm wondering if Prusa starts interpolating the dynamic overhang speed value at any amount of overhang, even less than 10%.

Also, for your test model (the circular one with the four overhangs), when you say 55 degrees, is that assuming that 0 degrees would be a vertical line and 90 would be a horizontal line or vice versa?

As a side note, it is sort of annoying that Orca (really I think Bambu Studio started it) and PrusaSlicer use two different ways to denote overhangs: I think Orca/Bambu's percentage means the percent of the line that IS NOT supported but PrusaSlicer's percentages mean the percent of the line that IS supported. So a 25% in Orca is 75% in PrusaSlicer and vice versa.

Okay, I have a new theory about what's going on: If we assume all extrusions are perfectly rectangular in nature (layer height by line width), then my guess is that the overhang speed fields are incorrectly applied. I can't seem to figure out what the exact behavior is, but that overhang test I used when sliced with 0.2mm layer height and 0.4mm layer width should have the 10-25% speed applied to the 20 degree angle. I did a quick mockup in a Fusion360 sketch to verify what the overlap for certain angles should be and in that case I would have an overhang of about 0.07mm, which is more than 25% of 0.4mm line width. However, that is not the case.

The interesting part is Bambu Studio does seem to handle it correctly (at least applying the 10-25% overhang speed to the 20 degree angle for the 0.2mm x 0.4mm test I was doing, I didn't try 0.1mm since I'm busy with other things at the moment).

If someone could try to verify what I said and test a few different cases and double check my reasoning independently, that would be very helpful. It is very possible I'm wrong.

@SoftFever I try not to tag external people on tickets, but if my reasoning is correct (hopefully people will double check), that means the base overhang functionality is broken for everyone regardless of layer height (at least as of Orca Slicer 2.2.0 which is what I'm using myself).

@staal54a

I literally use the same file as for orca.

Test project
https://drive.google.com/file/d/1xlRdgrJJVd9smNrEmeQhDjCTk3WDX8Ry/view?usp=drivesdk

The issue here seems to be your misinterpretation of the overhang percentages.
These do not represent the overhang angle like 0% is 0 degrees and 100% is 90 degrees but the distance the overhang perimeter of the current layer overhangs the the one from the previous layer in % of the overhang perimeters line width.
With lower layer heights this percentage becomes smaller for the same overhang angle, that's why different speeds are employed than when printing higher layers. And this is IMHO the correct behavior.

@shyblower
I think you are right!

But the main question is how to print parts with Orca slicer with layer height less than 0.2 if Orca refuses to slow down on overhangs ?

Reduce the whole printing speed? That's certainly a solution but how many days will printing take then....

@Start4up these settings work quite well for me with all layer heights:

@shyblower

Can I ask you to download my project and adjust it as you see fit.

The only thing is that the layer height should be 0.10

And show me the speed map.

To see what kind of speed Orca will offer on the overhangs.

Thank you!

@Start4up Ok, OrcaSlicer does not slow down the overhangs in your test project when sliced with 0.1mm layer height.
I've measured an overhang distance of about 20% which should put it in the 10%-25% range. Since there is no slowdown at all, you might be correct that it does not work as expected.
Since I'm currently a bit into the source code I might take a closer look at what's going on here and try to fix it in my own OrcaSlicer fork and in case I'm successful, raise a pull request here.

@shyblower
Thank you so much! I hope you can fix it.

And one more thing!

Just above @otede wrote that maybe this problem is related to the way Orca counts and cooling on overhangs. He noticed that my overhang slowdowns problem was very similar to his overhang cooling problem.
#5861

I don't know exactly how the two problems are related, but it looks very much like the root of the problems are the same.

Exactly, even at 0.1mm layer heights and 0.45 wide exrusions, the 10% overhang setting should definitely take effect even at only 30 degree overhangs. At a 30 degree angle, for every 0.1mm you go up, you go over 0.065mm. Meaning that you are overhanging by 0.065mm.
0.065/0.45 = 14.4% so the 10% - 25% setting should apply. But it doesn't register at all.

Prusaslicer does work, but stops at 25% overhang and then interpolates the speed for anything from 0 - 25% overhang. This isn't a good solution either though, since for 0.1mm layer height this makes it very hard to control the speed of overhangs up to 50 degrees.

So the way orcaslicer does it is ok, but just needs to be updated to actually work for the 10-25% range.

@galaxyman7 I'm on it, but I cannot give you an ETA because I've just begun diving deeper into that incredible mess of source code and some stuff there seems hard to fix without breaking other things, because so many features depend on each other.

Isn't it a good example of the issue? Can you see the bottom chamfers of that model hex nut holes? With some ~50% fan speed at layer No 2-3 I think, where intense cooling is needed on those specific hex hole peremeters. Project file attached.

Metric_Screw_Hex_Nut_Jig_4657385 gauge embossed debossed projektorca 01 pause.zip

@shyblower @galaxyman7 @Start4up

I've raised a PR addressing this here: #8080

I'd appreciate some testing please as the fix was straight forward but regression testing for other overhang angles is needed to confirm this did not break the 25%+ overhang slowdowns.

The above now looks closer to the expected, eg the below screenshot from above taken from the qidi slicer.

Basically what was happening was that the code was not slowing down from 10-25% overhang. Rather the moment it hit 25% overhang it applied the 10-25% overhang speed. So 25% was the minimum overhang that would perform a slowdown.

With this change what is on the label is implemented, i.e. 0-10% overhang = no slowdown. 10-25% -> proportional slowdown from external perimeter speed which is maintained up to 10% overhang, down to the set by the user limit which is hit at 25% overhang. etc.

I would strongly advocate not removing the 0-10% dead band as due to the way STL's are exported by modelling software and sliced, there are always micro variations between layers (i.e. less than 1-2% variations in overhangs) that may trigger a slowdown unnecessarily and trivially, causing extrusion micro segments and stuttering.

For the same reason I would not advise implementing a hard speed clamp at the 10% mark, ie when overhang is equal to 10% set a specific speed, as it is very easy to get +- 1% variation in overhang in circular models due to the way polygons are created, meaning you’d get alternating fast and slow segments right after each other, causing micro blobs and blemishes on the external wall.

Hence a proportional control is better as it inherently smooths out these speed changes when micro variations to overhang amount naturally happen.

Okay, I have a new theory about what's going on: If we assume all extrusions are perfectly rectangular in nature (layer height by line width), then my guess is that the overhang speed fields are incorrectly applied. I can't seem to figure out what the exact behavior is, but that overhang test I used when sliced with 0.2mm layer height and 0.4mm layer width should have the 10-25% speed applied to the 20 degree angle. I did a quick mockup in a Fusion360 sketch to verify what the overlap for certain angles should be and in that case I would have an overhang of about 0.07mm, which is more than 25% of 0.4mm line width. However, that is not the case.

The interesting part is Bambu Studio does seem to handle it correctly (at least applying the 10-25% overhang speed to the 20 degree angle for the 0.2mm x 0.4mm test I was doing, I didn't try 0.1mm since I'm busy with other things at the moment).

If someone could try to verify what I said and test a few different cases and double check my reasoning independently, that would be very helpful. It is very possible I'm wrong.

@SoftFever I try not to tag external people on tickets, but if my reasoning is correct (hopefully people will double check), that means the base overhang functionality is broken for everyone regardless of layer height (at least as of Orca Slicer 2.2.0 which is what I'm using myself).

Bambu slicer works differently with overhangs. It doesn’t or, at least in the past it didn’t, apply proportional slow down. Rather a fixed value whenever an overhang fell in this range.

Orca applies proportional slowdown between the speeds above and within that range depending on how much overhang is within the range.

That doesn’t invalidate the issue though, as the 10-25% band was basically a 25% threshold.

Tests done. Appears to have fixed the issue successfully. It would be good if the OP could confirm too.

Left - this PR - Right - Orca 2.2

Slowdown is now performed correctly between the 10-25% range instead of being ignored.

Build can be downloaded from the actions tab, here: https://github.com/SoftFever/OrcaSlicer/actions/runs/12838846984

Awesome, thank you for all your hard work everyone! I will try this out soon. I know most of the problems I had were when I used smaller layer heights (0.1mm), so if it works for that layer height that would be great.