Incorrect bridges depending on the number of perimeters

[Alexx40in]

Is there an existing issue for this problem?

• [x] I have searched the existing issues

OrcaSlicer Version

2.3.0-beta

Operating System (OS)

Windows

OS Version

Windows 10

Additional system information

No response

Printer

Bambulab X1

How to reproduce

The error is reproduced when slicing attached project file

Actual results

If the number of walls in the settings exceeds the thickness of the walls of the part, the bridges are built incorrectly

Expected results

The construction of bridges should not depend on the number of walls in the settings

Project file & Debug log uploads

Bridges.zip

Checklist of files to include

• [ ] Log file
• [x] Project file

Anything else?

No response

[igiannakas]

Walls are prioritised over bridges. This has been consistent throughout all the releases. If you would like to reduce the number of walls on a specific layer to enable a larger bridge please use a height range modifier :)

[Alexx40in]

Walls are prioritised over bridges. This has been consistent throughout all the releases. If you would like to reduce the number of walls on a specific layer to enable a larger bridge please use a height range modifier :)

Special modes such as "sacrificial layer" or "partially bridged" do not depend on the number of walls in the settings

[lhndo]

Same issue here: https://github.com/SoftFever/OrcaSlicer/issues/5376 It went stale among other things.

[igiannakas]

There is a misconception as to how bridges are defined in orca/ prusa/ Bambu etc.

A bridge is composed of two parts:

1. Bridge perimeters
2. bridge infill

The bridge perimeters are technically perimeters, not bridge infill. They are printed with either the lowest overhang speed or the external bridge speed if detection for curled perimeters is disabled. These are shown as dark blue in the slicer. Also from the second layer and above they get printed with perimeter speeds.

The bridge infill is always printed with the external bridge speed, flow and spacing. This is shown as light blue in the slicer.

The implemented feature creates additional bridge infill regions and applied bridge logic (speed, spacing, flow) to them. It does not touch the perimeters.

In terms of print priority the perimeters always take priority in terms of space. Then any left over space is printed with bridge infill. Hence why narrow bridges don’t have any bridge infill - they are all technically overhang perimeters.

To optimise your print quality for narrow bridges the best way is to disable detection of curled overhangs for the object - this will force bridge speed on the bridge perimeters. Then if the bridge area is too narrow and flimsy, use a modifier to reduce the number of perimeters in that region. Lower number of perimeters also affects the space the bridge have for anchoring too.

In my view this is fundamentally how all the slic3r derivatives work. Learning to operate within their constraints with the tools available is a must - think bridges - use modifiers to reduce number of walls, disable curled overhangs for the object / region.

The above new feature works exceptionally for large bridges, which tend to be the ones where the bridge infill tends to get destroyed by the zig zag motion from the solid infill layer above. why? Because the solid infill above a bridge infill extrudes at an angle and not parallel to the bridge.

Too narrow bridges only extrude perimeters hence they don’t suffer from this issue to that extent - as the layer over the bridge extrudes perimeters parallel to the walls and the bridge underneath. The problem there arises from print speed and / or too little anchoring space at the edges.

To get better quality on skinny bridges one should aim to reduce wall print speed, reduce number of walls in that area to convert the perimeter space to bridge infill or increase fan speed or all of the above.

Automatically converting the perimeters to bridge infill is something not desirable as it will also mess with overhangs. If you’re interested I can post you pictures of the side effects of doing so (I had experimented with that ages ago).

You can see some examples of the improvement areas in the Pr

[lhndo]

Walls are prioritised over bridges. This has been consistent throughout all the releases. If you would like to reduce the number of walls on a specific layer to enable a larger bridge please use a height range modifier :)

Special modes such as "sacrificial layer" or "partially bridged" do not depend on the number of walls in the settings

Yeah, that feature is quite amazing and similar to the SuperSlicer "No perimeter on bridge area" options. I just wish there was a way to specify the minimum amount of perimeters to keep.

[ShaneDelmore]

@igiannakas I worry "To optimise your print quality for narrow bridges the best way is to disable detection of curled overhangs for the object" is barely teachable, and never what anyone would expect. Have you thought of any ways to change that behavior to something more intuitive. I can't help but chuckle a little as I read it because I know you are being serious but it reads like you are joking almost. "Oh, of course, I need to untick the box related to overhangs to get bridges to work better". The poor users on orca discord chat then consistently think "but I don't want curled overhangs either" having no idea of the internal machinations related to these settings.

[github-actions[bot]]

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

[lexxxel]

Ping, to keep the issue open

[github-actions[bot]]

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

[github-actions[bot]]

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