Bridges being sliced as Overhang wall

[blownupp]

OrcaSlicer Version

1.7.0-beta

OS version

Windows 10.0.19045

Additional system information

CPU: 13th Gen Intel Core i5-13600k RAM: Corsair 64GB GPU: EVGA 3080TI

Printer

Voron 2.4

How to reproduce

Slice this bridge test: - checking/unchecking Slow Down For Overhang/Classic Mode doesn't change the result.

Actual results

Bridged gaps are sliced as overhangs:

Expected results

The bridged perimeters should be sliced with "Bridge flow", "Bridge density" and "Thick bridges" enforced per slicer settings.

Project file & Debug log uploads

Attached is the STL and a saved project file with the issue prevalent.

bridge_test_orca_errors.zip

Here's a log file including the color change bridge issues described in my comment below:

debug_Tue_Nov_21_09_24_08_41440.log.zip

Checklist of files to include

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

[Lt-Kammello]

Might my request/issue have to do with this?

https://github.com/SoftFever/OrcaSlicer/issues/2227#issue-1911382256

[floorcat]

(OrcaSlicer 1.7.0 on linux)

I think this is the same issue here.

Benchy inner ceiling sliced wrong. (classic and arachne same result)

Unchecking "Detect overhang walls" seems to fix it.

[floorcat]

still happening as of 1.8.0-rc2

[blownupp]

Still happening on official 1.8 release (and on upstream Bambu Studio - you can't print overhang walls on thin air!)

EDIT: I've noticed that color painting is messing this up. Here's a print with a couple letters on the left colored in and a letter on the right without a color change - all the letter features have the same draft angle and extruded cut depth:

Here it is by feature type:

After coloring in the letter that had proper bridging:

When using the "height range" color paint tool this does not seem to be an issue, it's only when using the fill/brush color paint tools that the bridging is sliced like overhang walls and tries to print in air.

I'm attaching a log file and the project file for reference:

debug_Tue_Nov_21_09_24_08_41440.log.zip P000113.zip

[Ltek]

@SoftFever this causes huge problems and seem FAR worse in 1.8.1 and 1.9 beta and it seems there is no workaround. I have mini figures that have 6 to 10 mm bridges that fail because Orca does not treat them as a bridge. Please fix.

[SoftFever]

Hey guys,

There are different questions and cases involved in this thread. I will reply to the first one here. The reason it treated as bridge perimeter instead of bridge infill is because it's a narrow bridge and you have specified 4 wall loops, so no bridge infill is generated. If you change the wall loops to 2, you will be able to see it:

[Ltek]

@SoftFever what if Orca had the option like "Make overhang wall printable" -- the current "Make Overhang Printable" doesnt work at all for the model attached; it will plug the bottom hole completely with infill. In other slicers I've see this add a bridge or two under overhang wall, against the current solid wall to help it cantilever out.

I'm seeing the largest issue on miniature models and/or areas where the thickness changes from high to lower (area that can sustain 3,4,5 walls to and area that can only sustain 2. Orca is making that transition using Overhang Wall, and they are failing every time for me. These are only 4mm long + 10mms + 100% cooling. Bridging is nearly perfect on that same filament doing the orca temp tower -- I did the temp tower after about 6 failed Overhang Wall attempts.

I've attached my STL so you can see it for yourself.

I modeled multiple version and printed ~20 various ones and the problem is always Overhang Walls fail (I get filament strands falling). I had to completely redesign my part so I could avoid overhang walls and make the entire model sustain 3 walls to avoid the transition to 2 walls. If someone wants to add strength to an STL they inherited (did not design themselves), the print will fail (or at least in part) every time if it does a transition like this.

turned Precise Wall on... issue.zip

[Ltek]

playing more today Now with this newer model, it creates a full overhang wall "layer"

project file attached Figure_FullOverhang Wall.zip

[Ltek]

Here's one where there are more walls below than above but it still adds an Overhang Wall where its not needed at all, or a bridge would have been better. I've tried printing this a few times, 100% fan and it fails every time.

It adds the Overhang Wall even I change to 0% infill for the model.

3 layers in order bottom to top...

Figure_topple_MyKlipper_Hyper_30-MyKlippe__Tapered-test1.zip

[SadBones]

Bump. Walls that are part of bridges print at overhang wall speeds rather than bridge speed causing the print to fail.

[SadBones]

Hey guys,

There are different questions and cases involved in this thread. I will reply to the first one here. The reason it treated as bridge perimeter instead of bridge infill is because it's a narrow bridge and you have specified 4 wall loops, so no bridge infill is generated. If you change the wall loops to 2, you will be able to see it:

The problem is the "bridge perimeters" are being sliced at the "overhang 75% - 100%" speed, rather than the "bridge" speed. You would want a 90% over hang to be printed extremely slow, but the perimeters of a bridge need to be printed quickly.

[Ltek]

All I know is what I see... and its creating really odd overhang walls (see my prior screenshots) where it makes no sense at all (like covering holes with a concentric pattern "wall").

No matter what I try, even on overhang walls that are 3 to 4mm long (see screenshots below) they fail every time. I printed over 60 miniatures with multiple different wall speeds... the last 20 were at 40mms wall speed and this is what it happens...

[riddlemd]

I had this bug get me good today, was printing a case and the part of the wall that the slicer thought was bridge was not being printed before the bridge was started so the bridge just fell off into air. Turning off "Detect overhang walls" fixed it.

[Ltek]

I had this bug get me good today, was printing a case and the part of the wall that the slicer thought was bridge was not being printed before the bridge was started so the bridge just fell off into air. Turning off "Detect overhang walls" fixed it.

I dont see that as a real fix? The point of detecting them is so the slicer can slow the print down, and increase the cooling, for those areas that need it. There seems to be 2 actual problems here (maybe separate bugs, not sure)...

1. Orca is simply not always correctly detecting overhang walls and placing them in odd spot.
2. When it does properly detect them its not using bridge settings and they fail to print properly. Evidenced by printing success with much long/harder bridges using the same filaments.

[CaptainFalcon63]

I ran into this today (V1.7---the issue made me look for a new version/why I'm here) when using some built-in supports on a part I designed. The workaround I used was to place a modifier at the bridge location and change the settings to have 0 walls. As expected it wouldn't create an overhang wall if walls weren't being generated.

This is the first time I've experienced this but I looked at it as more of a "bridges not reaching walls" problem rather than a "bridges sliced as walls" problem. In the future it would be great to not need to create modifiers to fix the problem because built-in support can save time and material over slicer generated support if done correctly.

[danno131313]

I've noticed enabling "Classic mode" in the dynamic overhang speed settings still slices bridges as overhang walls, but it causes them to use the bridge speed setting rather than the overhang speed setting for 75%-100%:

[obertini78]

Same issue here - v2.0.0-beta linux. Bridge is being marked a bridge but speeds are set to those of overhang I guess. In the case below, speed goes down to 2 mm/s!

If I check the 'Classic mode' under 'Overhang speed', I get a 30-50 mm/s as expected.

Note: result is the same with v1.9.1

[kpipes556]

Same problem here. Trying to do a temp tower and the overhangs were too slow because they were using bridging speeds.

Turned off "Detect overhang walls." This fixed the overhang issue but created a bridging issue: outer and inner wall speeds were applied to the bridge.

Classic mode or not, I couldn't find a combination of settings to fix this and allow changing overhang and bridge speeds independently.

[SoftFever]

Same problem here. Trying to do a temp tower and the overhangs were too slow because they were using bridging speeds.

Turned off "Detect overhang walls." This fixed the overhang issue but created a bridging issue: outer and inner wall speeds were applied to the bridge.

Classic mode or not, I couldn't find a combination of settings to fix this and allow changing overhang and bridge speeds independently.

This is most likely min layer time slowdown. Try to set the "slow_down_layer_time" to 0 and try again

[kpipes556]

Same problem here. Trying to do a temp tower and the overhangs were too slow because they were using bridging speeds. Turned off "Detect overhang walls." This fixed the overhang issue but created a bridging issue: outer and inner wall speeds were applied to the bridge.

Classic mode or not, I couldn't find a combination of settings to fix this and allow changing overhang and bridge speeds independently.

This is most likely min layer time slowdown. Try to set the "slow_down_layer_time" to 0 and try again

I tried turning off the min layer slowdown time and turned up the max volumetric just to take them out of the equation and it is still doing the same thing.

No matter what setting I try, it either adds walls to the bridge or doesn't let me set the overhangs independently and sets them equal to the bridge speed. For TPU, this just isn't working :(

2.0.0 on M1 Mac

[mfish38]

Same issue on 2.1.0-beta linux. I have noticed that quite often orca slicer will try and print into thin air, sometimes even trying to make the first layer of a hole using a concentric pattern starting from the center of the hole working out towards the hole edge, which is just extrude a bunch of plastic into thin air and do nothing.

Turning off Extra Perimeters on Overhangs appears to make it stop while still allowing Detect Overhang walls to be on.

[Felixoid]

I have the same issue in 2.1.1-1

It prints a completely hanging bridge, and I can't get rid of it.

Buse_V6_BLT_ED3V6.tar.gz

[vadixidav]

This issue causes issues with bridging. Notably, my bridge speed is very fast, at 150mm/s, but regardless of whether "detect overhang wall" is checked or not, these "walls" are printed at 25mm/s, which is too slow for bridging in this case, as I am printing very hot at this time. It is important that all bridging occurs at the same speed. Even if this is part of a wall, it is still a bridge. It is a bridge wall, not an overhang wall.

[Ltek]

@SoftFever this bug has been here for a year or so. Would really appreciate if you can address this in Orca and somehow make this 'stupid proof' (for people like me). If you believe there is a specific combo of setting that will avoid this problem, please have them set automatically (when changing a given setting/variable) so this doesnt happen or have a pop-up stating something like "you are changing setting ABC, in order to avoid slicing problem with Bridges you must set XYZ1 to blah and XYZ2 to bla-blah"

[ShaneDelmore]

I ran into this today as well. I am currently working around the issue by unchecking "detect overhang walls". I ran into at least 2 issues with the feature, first, it slices my bridges as if they are overhangs, but 2nd, the tooltip says "for 100% overhangs bridging speed is used" but it actually used the overhang speed for 75-100% overhang.

[vadixidav]

I ran into this today as well. I am currently working around the issue by unchecking "detect overhang walls". I ran into at least 2 issues with the feature, first, it slices my bridges as if they are overhangs, but 2nd, the tooltip says "for 100% overhangs bridging speed is used" but it actually used the overhang speed for 75-100% overhang.

This bug has been present for quite a long time now. I recommend making the largest overhang setting (75% to 100%) the same as your bridging speed and it fixes the issue. You will no longer be able to print anything going beyond 50% overhang (due to interpolation), but it improves print quality dramatically. I would just suggest not printing any parts that go beyond a 50% overhang, otherwise you have to fiddle with settings to work around the various bugs related to bridging speed.

[hotellonely]

This bug is still presenting and quite sad. Someone has submited a fix for bambu studio and hopefully it can be integrated here.

https://github.com/bambulab/BambuStudio/commit/0efa2db823fa3b69cfde2d40b47b0724211f18d6