detect overhang walls interferes with bridging

[BETLOG]

Is there an existing issue for this problem?

• [X] I have searched the existing issues

OrcaSlicer Version

2.0.0

Operating System (OS)

Linux

OS Version

Kubuntu 24.04

Additional system information

No response

Printer

frankenstein anycubic i3 mega, Ideaformer IR3 extruder, bambu nozzle

How to reproduce

Create model with areas that are to be bridged.

Actual results

Sometimes areas that are designed to be bridged get overhang wall treatment, and filled with a concentric layer. This increases the chance of failure. In many cases a symmetrical stl will have bridge assigned to one feature, and overhang wall assigned to it's mirrored twin, for no apparent reason. In some cases this seemed to be accompanied by 'floating cantilever' warnings.

Expected results

Probably bridging should always take precedence, and maybe query the user about what treatment to give otherwise. Orca really needs a way to zoom on a specific area to display what some of its warnings are talking about.

Project file & Debug log uploads

anycubic-i3Mega_gantrySpoolMount_frame.zip

Checklist of files to include

• [X] Log file
• [X] Project file

Anything else?

The log/project zip is not useful for demonstrating the seemingly random selection of overhang or bridge, as the first few times I noticed this all I did was take screenshots, and didnt save any 3mf.

Below: The 3mf infcuded here is merely to demonstrate what I believe is the cause of the issue. ie: if 'detect overhang walls' is on then it may interfere with things that are intended to be bridged.

Below: instances of mesh being sliced with a different treatment to otherwise identical overhangs, both intended to be bridged.

Below: 'bridge counterbore holes' with sacrificial layer failing 1/4 of the time, despite all 4 holes being essentially identical, and the left and right section of stl literally being mirrored. I was also seeing some interaction with 'detect overhang walls' here too.

[tome9111991]

same issue like me https://github.com/SoftFever/OrcaSlicer/issues/5706

I think it's a problem with the "extra perimeters on overhangs" setting

[BETLOG]

same issue like me #5706

agreed

[BlackNet]

Been dealing with this same issue for the past 2 weeks.

[tastyratz]

I was noticing the same behavior myself just now and found your report in a search.

Here is an example of very odd overhang detection displacing bridges on the temperature tower

I was originally trying to replicate and test https://github.com/SoftFever/OrcaSlicer/issues/4040 when I noticed the left edges were not even being detected as overhangs at all for me.

This also impacts line ordering. The "overhangs" are printed before the bridges (even though they are all actual bridges).

[tastyratz]

I am running 2.1.1 and it was fine when I was on 1.9.x.

I thought I'd followup with another model link and real-life example here: https://www.printables.com/model/585445-voron-02r1-wide-feet-stock-skirts-update os

(For reference I also have this on the build plate: https://www.printables.com/model/185070-voron-misumi-2020-endcap )

it's really peculiar the way bridge and overhang detection is happening os I'm seeing different behavior on the same plate with 2 parts. The misumi endcaps you can see are odd in the way they detect bridging and internal bridging because of the gaps over the voron logo and... well I can't answer WHY it would be leaving a gap an doing internal bridging after (must be some artifact with the model) The v0 wide legs are showing overhangs over the built in supports which is more fitting. This specific area issue goes away if I disable the "extra perimeters on overhangs" setting which ties back to #5706

If I disable "detect overhang walls" then it STILL does not switch to bridging over bridges and instead switches the "overhangs" to perimeter walls which should very clearly be bridges.

For reference, I decided to try and slice the same part in the latest Superslicer beta just now ss it's properly detecting the area over the built in support as bridge infill

Curiously, superslicer does their overhangs very differently specific to the one that failed the most and it's NOT this way in the model so they must be handling regular bridges different. ss ss

Note too that the misumi endcap odd behavior in Orca doesn't seem to be present in SS by comparison

All that being said, sadly, the bridge bug ruined an otherwise perfect print trying to bridge on my overhang/logic settings. I'll have to wait to print my V0 parts for this one to be fixed because I can't seem to get a clean abs bridge anymore on my trident XOL setup.

I also found this report on Prusaslicer, it could potentially be upstream https://github.com/prusa3d/PrusaSlicer/issues/12417

[lightmaster]

On the X1C 0.4mm profile with a standard 3DBenchy loaded, if you change wall loops from 2 to 3 and turn on Extra Perimeters on Overhangs, it changes the cabin roof from a series of bridges to a concentric bridge. I've seen multiple people here say to turn off Extra Perimeters on Overhangs, but I think this is a bug with overhang detection, not a case of "just turn off X setting".

[CCS86]

Fixes here would be very useful.

[5p0rkz1lla]

I'm not sure if it will help find a solution, but I did discover something I don't see in this discussion. The issue appears to only apply when printing over another portion of the model. For the wall/bridge it's as if instead of just checking the previous layer it's checking all previous layers. When there's only the bed below things work correctly...

[hotellonely]

this is still an active issue that needs to be solved. currently, the only "fix" is to change "Bridge Counterbore Hole" method to "Partially Bridged". Note that both None and Sacrificial Layer won't work. Only working one is Partially Bridged. Which doesn't make sense and can only be considered as a bug.

Example here:

In the image above, I'm showing the print speed of a single bridging layer of orca temperature tower. this is the correct behavior, when the walls are correctly bridged. You can see that the print speed is consistent between briding infills and bridging walls.

However if I change the setting to None or Sacrificial Layer, now it thinks that the bridging wall is overhang, and uses incorrect speed for printing, causing much more sagging than it should. I'm pretty sure this has ruined more prints than it should.

[lightmaster]

@hotellonely Wait, a bridge is supposed to look like that first image, where there are perimeters before and after the bridge but none on the non-anchored sides? I always thought it was supposed to look like that second image.

[hotellonely]

@hotellonely Wait, a bridge is supposed to look like that first image, where there are perimeters before and after the bridge but none on the non-anchored sides? I always thought it was supposed to look like that second image.

At least that's what Bambulab now thinks. They submitted a change as a bug fix, to change the behavior to look like the first image by default.

A bridging perimeter should be printed like a bridge rather than overhang for Inner-Outter-Inner or Outter-Inner because there's nothing that you can attach onto, by the side.

For Inner-Outter order, slow overhang helps because it has something to attach onto from previously printed lines, but, because you don't have anything to cling on with the bridging perimeter when you're printing outter-inner or inner-outter-inner mode, so it should be printed as a bridge instead of overhang.

I think it all started from Prusa slicer which didn't come with OI or IOI print order previously, so they didn't really have a problem with that.

[staal54a]

@hotellonely What's really strange is that the "fix" with setting the Bridge counterbore holes setting to "Partially bridged" seems to use the same routing that an internal bridge would but applies the external bridge speed.

As a note, I think Orca Slicer always will view a bridge as a 100% overhang per this comment: https://github.com/SoftFever/OrcaSlicer/issues/5788#issuecomment-2182741408

Can you try disabling Slow Down for Curled Perimeters and seeing if the bridging speeds are correct? When I do that, I still get the same line types with the outer perimeters detected as overhang walls and continuing around walls of the structure being bridged to, but the speed of those lines are correct.

Overall, I think there are several issues that may not necessarily be directly related but all stem from this overlap between bridges and overhangs that need to be addressed in some way. Related issues I have found so far: https://github.com/SoftFever/OrcaSlicer/issues/6448 (feature request) https://github.com/SoftFever/OrcaSlicer/issues/2231 https://github.com/SoftFever/OrcaSlicer/issues/6941 (this one apparently has the counterbore partially bridged option converting actual overhangs to bridges)

There may be more but it really does seem like bridges and overhangs have some underlying issues.

[hotellonely]

@hotellonely What's really strange is that the "fix" with setting the Bridge counterbore holes setting to "Partially bridged" seems to use the same routing that an internal bridge would but applies the external bridge speed.

As a note, I think Orca Slicer always will view a bridge as a 100% overhang per this comment: #5788 (comment)

Can you try disabling Slow Down for Curled Perimeters and seeing if the bridging speeds are correct? When I do that, I still get the same line types with the outer perimeters detected as overhang walls and continuing around walls of the structure being bridged to, but the speed of those lines are correct.

Overall, I think there are several issues that may not necessarily be directly related but all stem from this overlap between bridges and overhangs that need to be addressed in some way. Related issues I have found so far: #6448 (feature request) #2231 #6941 (this one apparently has the counterbore partially bridged option converting actual overhangs to bridges)

There may be more but it really does seem like bridges and overhangs have some underlying issues.

I'm not sure if I have stated it here or somewhere else before, but no turning off "slow down for overhang" is not a solution to this problem. I've made various tests and extra perimeter, slowdown for overhang,... none of them can provide consistent fix for this issue.

The only rather consistent fix is the counterbore hole, by changing it to partially bridged. it doesn't work perfectly, but well enough or at least better than the wonky output...

[kayboy-bebop]

@hotellonely What's really strange is that the "fix" with setting the Bridge counterbore holes setting to "Partially bridged" seems to use the same routing that an internal bridge would but applies the external bridge speed. As a note, I think Orca Slicer always will view a bridge as a 100% overhang per this comment: #5788 (comment) Can you try disabling Slow Down for Curled Perimeters and seeing if the bridging speeds are correct? When I do that, I still get the same line types with the outer perimeters detected as overhang walls and continuing around walls of the structure being bridged to, but the speed of those lines are correct. Overall, I think there are several issues that may not necessarily be directly related but all stem from this overlap between bridges and overhangs that need to be addressed in some way. Related issues I have found so far: #6448 (feature request) #2231 #6941 (this one apparently has the counterbore partially bridged option converting actual overhangs to bridges) There may be more but it really does seem like bridges and overhangs have some underlying issues.

I'm not sure if I have stated it here or somewhere else before, but no turning off "slow down for overhang" is not a solution to this problem. I've made various tests and extra perimeter, slowdown for overhang,... none of them can provide consistent fix for this issue.

The only rather consistent fix is the counterbore hole, by changing it to partially bridged. it doesn't work perfectly, but well enough or at least better than the wonky output...

This definitely fixes some things, but I think that's largely down to the counterbore hole option replacing so much of the normal sliced gcode with the feature specific gcode (which sometimes introduces it's own problems). In areas of the sliced model where counterbore doesn't activate I still have bridges being treated as overhangs.

But really, overhangs being jank has been an issue with all Prusa Slicer forks for a while. I've hopped between Prusa, Orca and Super trying to get consistent overhang/bridge behaviour, but now I can only hope that one of the next big releases is focused on bug fixes, cause a lot of these new fancy features (as great and exciting as they are) are breaking things.

[github-actions[bot]]

Orca bot: this issue is stale because it has been open for 90 days with no activity.

[hotellonely]

@hotellonely What's really strange is that the "fix" with setting the Bridge counterbore holes setting to "Partially bridged" seems to use the same routing that an internal bridge would but applies the external bridge speed. As a note, I think Orca Slicer always will view a bridge as a 100% overhang per this comment: #5788 (comment) Can you try disabling Slow Down for Curled Perimeters and seeing if the bridging speeds are correct? When I do that, I still get the same line types with the outer perimeters detected as overhang walls and continuing around walls of the structure being bridged to, but the speed of those lines are correct. Overall, I think there are several issues that may not necessarily be directly related but all stem from this overlap between bridges and overhangs that need to be addressed in some way. Related issues I have found so far: #6448 (feature request) #2231 #6941 (this one apparently has the counterbore partially bridged option converting actual overhangs to bridges) There may be more but it really does seem like bridges and overhangs have some underlying issues.

I'm not sure if I have stated it here or somewhere else before, but no turning off "slow down for overhang" is not a solution to this problem. I've made various tests and extra perimeter, slowdown for overhang,... none of them can provide consistent fix for this issue. The only rather consistent fix is the counterbore hole, by changing it to partially bridged. it doesn't work perfectly, but well enough or at least better than the wonky output...

This definitely fixes some things, but I think that's largely down to the counterbore hole option replacing so much of the normal sliced gcode with the feature specific gcode (which sometimes introduces it's own problems). In areas of the sliced model where counterbore doesn't activate I still have bridges being treated as overhangs.

But really, overhangs being jank has been an issue with all Prusa Slicer forks for a while. I've hopped between Prusa, Orca and Super trying to get consistent overhang/bridge behaviour, but now I can only hope that one of the next big releases is focused on bug fixes, cause a lot of these new fancy features (as great and exciting as they are) are breaking things.

Currently the only fork that worked rather consistenly for me is bambu (on this particular issue). It still thinks this is an overhang, but now it prints at bridging speed instead...

[digital0785]

@hotellonely What's really strange is that the "fix" with setting the Bridge counterbore holes setting to "Partially bridged" seems to use the same routing that an internal bridge would but applies the external bridge speed.

As a note, I think Orca Slicer always will view a bridge as a 100% overhang per this comment: #5788 (comment)

Can you try disabling Slow Down for Curled Perimeters and seeing if the bridging speeds are correct? When I do that, I still get the same line types with the outer perimeters detected as overhang walls and continuing around walls of the structure being bridged to, but the speed of those lines are correct.

Overall, I think there are several issues that may not necessarily be directly related but all stem from this overlap between bridges and overhangs that need to be addressed in some way. Related issues I have found so far: #6448 (feature request) #2231 #6941 (this one apparently has the counterbore partially bridged option converting actual overhangs to bridges)

There may be more but it really does seem like bridges and overhangs have some underlying issues.

the problemm with the partially bridged "fix" is that it also breaks things ..

this is no partially bridge which is printing concentric however the walls stay proper

this is turning on partially bridged obviously fixes the concentric issue however creates gaps in layers.. it clearly could print a perimeter around the bridge however it doesn't which creates an empty layer where the bridging happens. the bridge should only be over lapping 1 wall as an anchor which it does most of the time but for some reason it breaches the outer wall in 1 spot and doesn't add the wall on the rest

this happens both with arachne and classic as well and I've tried going down to 5% minimum wall thickness and it's still an issue

[andrewleek]

Howdy everyone, I have made a PR regarding overhangs and bridges and it should solve some of the issues in this thread.

It would be great to get some testing and feedback to make sure it works correctly and there arent any unforeseen side-effects.

PR: https://github.com/SoftFever/OrcaSlicer/pull/10565

You can download the builds under "artifacts": https://github.com/SoftFever/OrcaSlicer/actions/runs/17304272227?pr=10565

Thank you