Explicit control override for the first solid infill layers applied over a bridge. #42

Open
opened 2026-04-05 16:18:14 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @derei on 4/1/2026

Is there an existing issue for this feature request?

  • I have searched the existing issues

There has been a similar issue raised a bit long time ago ( https://github.com/OrcaSlicer/OrcaSlicer/issues/3847 ) and it was closed by allowing a 2nd bridge layer that is now part of OrcaSlicer.
The problem is that doesn't fix the real issue - it just narrows the failure scenarios.

Which printers will be beneficial to this feature?

All

Describe the solution you'd like

The solution would be a clear override set of controls that allow to control at minimum the flow and speed of the 1st solid infill layer deposited on top of the bridge. Even better if it would allow a ramp over the next n layers.

Example:
Assuming we could set 1st solid infill on top of a bridge at 60% speed, and a ramp of 2 layers:

  • 1st layer: 60% speed
  • 2nd layer: 80% speed
  • 3rd layer: already back to global configuration

And if the goal is for it to not affect the entire solid infill on that layer, only the one that gets applied on top of the bridge infill, it would benefit of being defined as a specific type of line, such as "over-bridge solid infill", for example.

Describe alternatives you've considered

  • Extra bridge layers - reduces the extent the failure and the scenarios when it happens, but it doesn't solve the problem
  • Thick bridge lines - can be a partial solution for small gaps (holes, cut-outs), but if the part has also longer bridging areas, the setting being global will negatively impact long bridges

Additional context

EDIT: Perhaps a quick workaround would be if Orca could do Extra Bridge Layers + Thick Bridge only on 2nd layer. I haven't tested it, but it makes sense: the thin bridge lines can span for longer distances, and they can act as support for the 2nd thicker pass.
For best results it would require separate density adjustment for each thin and thick - but that could potentially fix the issue in the cleanest way without requiring extensive code rewrite.

*Originally created by @derei on 4/1/2026* ### Is there an existing issue for this feature request? - [x] I have searched the existing issues ### Is your feature request related to a problem? There has been a similar issue raised a bit long time ago ( https://github.com/OrcaSlicer/OrcaSlicer/issues/3847 ) and it was closed by allowing a 2nd bridge layer that is now part of OrcaSlicer. The problem is that doesn't fix the real issue - it just narrows the failure scenarios. ### Which printers will be beneficial to this feature? All ### Describe the solution you'd like The solution would be a clear override set of controls that allow to control at minimum the flow and speed of the 1st solid infill layer deposited on top of the bridge. Even better if it would allow a ramp over the next n layers. Example: Assuming we could set 1st solid infill on top of a bridge at 60% speed, and a ramp of 2 layers: - 1st layer: 60% speed - 2nd layer: 80% speed - 3rd layer: already back to global configuration And if the goal is for it to not affect the entire solid infill on that layer, only the one that gets applied on top of the bridge infill, it would benefit of being defined as a specific type of line, such as "over-bridge solid infill", for example. ### Describe alternatives you've considered - Extra bridge layers - reduces the extent the failure and the scenarios when it happens, but it doesn't solve the problem - Thick bridge lines - can be a partial solution for small gaps (holes, cut-outs), but if the part has also longer bridging areas, the setting being global will negatively impact long bridges ### Additional context EDIT: Perhaps a quick workaround would be if Orca could do Extra Bridge Layers + Thick Bridge only on 2nd layer. I haven't tested it, but it makes sense: the thin bridge lines can span for longer distances, and they can act as support for the 2nd thicker pass. For best results it would require separate density adjustment for each thin and thick - but that could potentially fix the issue in the cleanest way without requiring extensive code rewrite.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/OrcaSlicer#42