Bridges starts in free air

[simonbuehler]

Describe the bug
When printing a overhang the bridge starts disconnected in the air, already switched to infill/inner/outer

3mf File for This Bug
sprocketwheel-Body.zip

To Reproduce
slice the file

Expected behavior
the bridge should start connected (there is enough space)

Screenshots

Printer model
p1p
Desktop (please complete the following information):

• OS: win10
• Version 1.6.3

[simonbuehler]

after more fiddling it seems that the slicer acts as if the outer wall is already present ( it would with default wall_infill_order ) so it would connect, but the changed order isn't taken into account for a updated "bridge" path so it starts unconnected.

[github-actions]

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

[tastyratz]

I've also been experiencing this and it drives me nuts. A perfect example is this Nevermore XL cartridge.

Orcaslicer is trying to free air print bridges and connect them second. This obviously does not work and the result is a ton of dropped bridges and the mesh looking like garbage.

Changing wall order does not make any difference.

This is still happening in 1.7.0

[tastyratz]

Also to note that this behavior at least in my old copy of superslicer is not happening consistently, but, does seem to happen on the first bridge of each row.

This is my example file: https://github.com/nevermore3d/Nevermore_Micro/blob/master/V6/STL/XL_HEPA_Cartridge/1_XL_Cartridge.stl

The path on superslicer is making a row of rectangles and incorporating the outside wall to the bridge path.
Orcaslicer is performing all bridging operations first and THEN creating all outside walls.

The order of operations in Orcaslicer is causing bridge failures. Let me know if I could be better explaining this one @SoftFever

I tried this with classic with and without detect thin walls and arachne, same patterning.

[SoftFever]

Also to note that this behavior at least in my old copy of superslicer is not happening consistently, but, does seem to happen on the first bridge of each row.

This is my example file: https://github.com/nevermore3d/Nevermore_Micro/blob/master/V6/STL/XL_HEPA_Cartridge/1_XL_Cartridge.stl

The path on superslicer is making a row of rectangles and incorporating the outside wall to the bridge path. Orcaslicer is performing all bridging operations first and THEN creating all outside walls.

The order of operations in Orcaslicer is causing bridge failures. Let me know if I could be better explaining this one @SoftFever

I tried this with classic with and without detect thin walls and arachne, same patterning.

@tastyratz
thanks for the information.
Yeah, I checked with PrusaSlicer as well, it also has this issue.
Need more investigation for such edge cases.

[github-actions]

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

[github-actions]

Orca bot: This issue was closed because it has been inactive for 7 days since being marked as stale.

[tastyratz]

I was really hoping #3319 would also resolve this, but, unfortunately not the case as verified with 2.0 trying to slice the nevermore cartridge just now. I tried disabled, limited, and none but it still bridges over open air.

I did, however, just figure out that the problem ONLY happens with Arachne and does NOT happen when using classic wall generator when testing on 2.0

This behavior is different from when I first reported the problem happening in 1.7 where classic also appeared impacted.

[netweaver1970]

for me, on 2.0 I get the same behaviour. I'm also on arachne. It happens on higher-up layers as well, as long as they are single line bridges, they are all floating. Actually they are identified as overhang wall line type, maybe that's the issue?

I didn't check classic yet. Maybe something to do with these very thin (single line) walls?
Double line walls, on top of the single line bridges below, are properly handled with a serpentine style of extrusion.

Anyway, easy enough to replicate. So it can be debugged, by people smarter than me :)

Higher up:

[tastyratz]

prusa3d/PrusaSlicer#9074

prusa3d/PrusaSlicer#11151

These 2 bugs have been upstream reports for the last few years and remain open. It does not appear to be a priority there. The nevermore is probably the most perfect example to highlight the issue.

[tastyratz]

I have done some additional GIT digging and found this supermerill/SuperSlicer#3567

I've replicated this superslicer bug myself on Orca 2.0 by changing the perimeter count (wall loops) from 3 to 1. Once I dropped to 1 perimeter then Arachne is generating the bridges AFTER drawing the perimeter with the little nipples to attach to. This appears to be the correct behavior to me on layer 299.

I'm hoping by linking these reports together and presenting my findings across projects that someone on this or other bug reports connects the dots.

This seems to be further narrowed down to Arachne perimeter order when single wall bridges are present and more than 1 perimeter/wall loop is selected.

I also did MORE investigation and changed Wall printing order to Outer/Inner.

When wall printing order is Inner/Outer, the bridges fail in open air.
If wall printing order is Outer/Inner, it prints the supporting bridge wall first on layer 299 but only sorta fixes things on layer 314 which behaves extremely strange

Some bridges then are drawn before perimeters/open air, some are drawn after perimeters.

Ultimately:

This could be solved by forcing "Print bridges after perimeters" either by an option or default behavior as I can't see why you might ever want to print bridges before perimeters.

If we can detect bridges, this seems like a viable solution to present.