Bridging Philosophies

[OhmEye]

I've always found bridging with Slic3r to be more challenging than with Skeinforge-based slicers, and now I as I compar to KISSlicer I am curious why this is. I have three different issues with the way Slic3r does bridges.

1. The bridge lines are very close together and result in my most common bridge failure mode: The nozzle dragging adjacent lines into a mess. This is hard to fix by printer tuning, the nozzle is just so close to the adjacent line.
2. The bridge ends often overlap the anchoring perimeters by an extremely small amount even if there's plenty of room to get a good "running start." An extremely well-tuned setup will often survive this, but I see no reason to make anchoring the bridge ends more challenging than necessary.
3. The bridge angles are often inconsistent or not optimal. Sometimes the bridge angle is the most difficult direction possible, and often multiple bridge areas in the same layer will be at different angles, even if they are similar shapes. For me this is often as much an cosmetic issue as functional one. When I have an object with a surface that includes bridges it can look terrible to have them at inconsistent angles.

Issue 1 is by far the largest source of my bridge failures. Here are examples of the same bridge layer sliced by Slic3r and KISSlicer:

The Slic3r bridge lines are so close together they appear in gcodeview as a solid area, and the nozzle often drags adjacent lines and creates a mess.

The KISSlicer bridge lines are the same distance apart as solid fill and print very easily.

Why does Slic3r bridge this way, and are any of these 3 issues considered problems by anybody else?

Files:
http://ohmeye.com/download/debug/debug_bridging/config.ini
http://ohmeye.com/download/debug/debug_bridging/bar_support_8mm_clip_fab.stl

[haasebert]

I have not tried Skeinforge recently and have never tried KISSlicer, but I have the exact same issue as you describe. Lots of bridges really close together, and eventually they curl up and brush against the print head.

[jib77]

I am also having these issues ... I can make it do ok in most instances by tweaking bridging speed and extrusion ratio. But often a good speed/extrusion combination results in poor bridge anchors because not enough material is extruded at the anchor points.

[KnechtRuprecht]

I'm having the same issues and you described it very good.

I would like to add a fourth issue I detected.

1. When a bridge is on the perimeter the fan speed won't change to the selected fan speed in the settings.

[diggit]

I must agree too. Bridges are too thin. They fail really often. After bad bridge layer follows common layer and it works much better.
IMHO this could be solved by adding another box into advanced print settings to set bridge extrusion width. Manual settings is welcome.

[haasebert]

I was hoping that the extrusion width settings on the Advanced page of the Print Settings tab would let us do just that: set width separately from speed. Unfortunately it ties path planning in an sets the distance between path accordingly.

-CH

Sent from my TRS-80.

On Apr 8, 2013, at 9:06 AM, Patrik Bachan notifications@github.com wrote:

I must agree too. Bridges are too thin. They fail really often. After bad bridge layer follows common layer and it works much better.
IMHO this could be solved by adding another box into advanced print settings to set bridge extrusion width. Manual settings is welcome.

—
Reply to this email directly or view it on GitHub.

[nodje]

I've been trying to get a good print of the Reprap bridging calibration test http://reprap.org/wiki/Calibration#Bridging for days...

I've slow down bridge_speed, increased bridge_flow_ratio, increased nozzle size a bit to get an overlap, increased head temp for ABS, all to no avail...

Cura does a perfect bridge, but the corners of the cube are just very bad, where Slic3r make absolutly perfect:

Bridge anchor is the biggest problem to me. The bridge always starts a little bit off the perimeter which makes it drop .

[jamesarm97]

I have also noticed like the picture with all the white cubes that there doesn't seem to be enough overlap between the starting points of the bridge and the inside perimeter and doesn't grab enough to the inside perimeter to hold. Maybe a perimeter overlap ratio for bridge layer?

[TopperDEL]

I definitely agree that the bridging in Slic3r is very challenging. I would suggest the "Perimeter overlap Ratio for bridge-layer"-Parameter as the bridging simply start way too far on the inside of the object so the Bridge can't connect to the part itself. This should be quite easy to implement but help in quite all cases.

[nophead]

Skeinforge would force the number of perimeters to one to give the bridge
something to land on, i.e. the extra perimeters in the layer below.

On 14 April 2013 11:37, TopperDEL notifications@github.com wrote:

I definitely agree that the bridging in Slic3r is very challenging. I
would suggest the "Perimeter overlap Ratio for bridge-layer"-Parameter as
the bridging simply start way too far on the inside of the object so the
Bridge can't connect to the part itself. This should be quite easy to
implement but help in quite all cases.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1090#issuecomment-16349069
.

[adjwilley]

Very good description of what I'm seeing.

[jamesarm97]

Is there any way to get a quick hack or point me in the direction (this slic3r code is greek to me) to temporarily adjust the perimeter overlap used on bridging? Bowden /Rostock bridging is almost useless they way it is currently printing. Doesn't usually overlap enough on the endpoint when it turns around.

[OhmEye]

Here's another example of a typical situation in my daily workflow. I have a small object that for multiple reasons is best printed in an orientation that requires bridging, so I have to choose whether or not to compromise other issues to eliminate the bridge. If the bridge executes well then I end up with a great part with no compromise, so I compare the bridge results from multiple slicing apps to see which does it best and choose one. In this case it's Cura that does the best bridge but slic3r does the best perimeters and fill for the requirements I have, so I decide to replace the bridge layer in the slic3r gcode with the layer generated by Cura. It's worth the extra effort in this specific case because the part will be mass produced, but it's another example of how I find myself working around the bridging issues in Slic3r.

Here is the layer under the bridge, I will be comparing how Slic3r, KISSlicer, and Cura bridge this gap.

Here's how Slic3r bridges this layer, closely spaced lines anchored to bridged perimeters, the anchors often don't stick well and when they do they pull the perimeter in and droop, and even if this doesn't go badly the nozzle drags adjacent lines and rips up into a mess.

Here's how KISSlicer bridges this layer, diagonal lines to the bridged perimeter that anchor poorly and the lines that do anchor to the bridged perimeter tend to pull it inward and droop.

Here's how Cura bridges this layer, parallel lines to the bridge fully anchored, no anchoring to bridged perimeters, good line spacing so the nozzle doesn't drag adjacent lines.

These examples highlight 2 of the primary issues that result in poor bridges for me:

1. Using a bridged perimeter to anchor infill bridging. This requires the bridged perimiter to be perfect for the anchor overlap to even have a chance of sticking, and even when it does, the weight and contraction of the infill lines pulls the perimeter inward and the whole bridge area tends to droop. This is adding unecessary challenge. Clean bridges are very much more likely if the bridge lines are parallel to bridged perimeters and as perpendicular as possible to anchor perimeters, which also usually gives much more potential anchor area instead of minimizing the anchor overlap to a single perimeter.

2. Using dense line spacing. Even if bridging angle and anchor area is good, if the line paths are so close together that the flat of the nozzle overlaps adjacent lines it often causes the nozzle to drag on the previous line and destroy the entire bridge, especially if the plastic curls up at all as it cools which is a common problem.

Files:
http://ohmeye.com/download/debug/debug_bridging/config.ini
http://ohmeye.com/download/debug/debug_bridging/ohmeye_mm2_extruder_guide_lower_b2.stl

[nophead]

As a matter of interest, when you say "slic3r does the best perimeters", in
what way are they better? Shouldn't all slicers give exactly the same
perimeters that are simply the outline of the object?

On 28 April 2013 20:57, OhmEye notifications@github.com wrote:

Here's another example of a typical situation in my daily workflow. I have
a small object that for multiple reasons is best printed in an orientation
that requires bridging, so I have to choose whether or not to compromise
other issues to eliminate the bridge. If the bridge executes well then I
end up with a great part with no compromise, so I compare the bridge
results from multiple slicing apps to see which does it best and choose
one. In this case it's Cura that does the best bridge but slic3r does the
best perimeters and fill for the requirements I have, so I decide to
replace the bridge layer in the slic3r gcode with the layer generated by
Cura. It's worth the extra effort in this specific case because the part
will be mass produced, but it's another example of how I find myself
working around the bridging issues in Slic3r.

Here is the layer under the bridge, I will be comparing how Slic3r,
KISSlicer, and Cura bridge this gap.
[image: Slic3r bridge layer]https://a248.e.akamai.net/camo.github.com/c736dea25d1f92056cb7945d04a35511158d614b/687474703a2f2f6f686d6579652e636f6d2f646f776e6c6f61642f64656275672f64656275675f6272696467696e672f327072656272696467652e706e67

Here's how Slic3r bridges this layer, closely spaced lines anchored to
bridged perimeters, the anchors often don't stick well and when they do
they pull the perimeter in and droop, and even if this doesn't go badly the
nozzle drags adjacent lines and rips up into a mess.
[image: Slic3r bridge layer]https://a248.e.akamai.net/camo.github.com/8dbb561da05ec09aa2dba6cba5a4c85b58b1b5d9/687474703a2f2f6f686d6579652e636f6d2f646f776e6c6f61642f64656275672f64656275675f6272696467696e672f32736c696333722e706e67

Here's how KISSlicer bridges this layer, diagonal lines to the bridged
perimeter that anchor poorly and the lines that do anchor to the bridged
perimeter tend to pull it inward and droop.
[image: Slic3r bridge layer]https://a248.e.akamai.net/camo.github.com/8b34e179440e918d03f3c917ae5850c46f3470be/687474703a2f2f6f686d6579652e636f6d2f646f776e6c6f61642f64656275672f64656275675f6272696467696e672f326b6973736c696365722e706e67

Here's how Cura bridges this layer, parallel lines to the bridge fully
anchored, no anchoring to bridged perimeters, good line spacing so the
nozzle doesn't drag adjacent lines.
[image: Slic3r bridge layer]https://a248.e.akamai.net/camo.github.com/17c24aed4b73b9b7e2a2485d6ee926c06c7ad203/687474703a2f2f6f686d6579652e636f6d2f646f776e6c6f61642f64656275672f64656275675f6272696467696e672f32637572612e706e67

These examples highlight 2 of the primary issues that result in poor
bridges for me:

1. Using a bridged perimeter to anchor infill bridging. This requires the
   bridged perimiter to be perfect for the anchor overlap to even have a
   chance of sticking, and even when it does, the weight and contraction of
   the infill lines pulls the perimeter inward and the whole bridge area tends
   to droop. This is adding unecessary challenge. Clean bridges are very much
   more likely if the bridge lines are parallel to bridged perimeters and as
   perpendicular as possible to anchor perimeters, which also usually gives
   much more potential anchor area instead of minimizing the anchor overlap to
   a single perimeter.

2. Using dense line spacing. Even if bridging angle and anchor area is
   good, if the line paths are so close together that the flat of the nozzle
   overlaps adjacent lines it often causes the nozzle to drag on the previous
   line and destroy the entire bridge, especially if the plastic curls up at
   all as it cools which is a common problem.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1090#issuecomment-17141388
.

[OhmEye]

@nophead In this specific case I wanted more than one perimeter loop and was looking at a particular acute angle where slic3r does a better job of the inner perimeters matching the angle and not leaving a gap between the outer and inner perimeter at the corner. I didn't use Cura's output for the whole file because the infill pattern was horribly broken, and I didn't use KISSlicer's output as the base file because Slic3r's infill and perimeters were superior.

Here's an example of KISSlicer's perimeters, notice how the inner perimeter does not closely follow the exterior perimeter and leaves a slight gap and some corners have unecessary additional segments. The arc segments are also not very smooth.

Here is Slic3r's output for the same layer, the inner perimeters match the exterior path nicely and are very clean:

None of this is related to bridging, but do serve as more examples of differences between slicing apps.

[alranel]

Okay, let's go through this.

@OhmEye, you should really follow the usual method for discussing problems: STL file and config.ini, along with description of the actual problem encountered during that single print. This is the only way to allow me or other people to try printing the object and check your report. I understand your effort in generalizing your diagnosis, but we should really work on single, clear, reproducible test cases. This applies to all of your points: extrudate overlap, poor anchors, bad direction.

@diggit, you can't set extrusion width for bridges. When you extrude filament in free air, there's no way you can influence the width of filament, other than changing your nozzle. You might still want to use the existing Bridge flow ratio option to influence the amount of extrusion.

@nodje, as @nophead explained Skeinforge removes all perimeters except for the external one so that the internal ones act as anchors. Slic3r never reduces the configured number of perimeters, and I really think it never will. This is why you get different results. (I have been playing with something similar in the internal-support branch, though, where additional internal perimeters are generated where needed).

@jamesarm97, @TopperDEL: no extrusions should actually overlap (except for a small amount needed to fill the side gaps). Bridges are sustained by anchors, not by overlap.

[jamesarm97]

@jamesarm97, @TopperDEL: no extrusions should actually overlap (except for a small amount needed to fill the side gaps). Bridges are sustained by anchors, not by overlap.

—

Well what ever it is called overlap vs anchor, it doesn't work well, at least with the Bowden/Rostock type printer as more than I have pointed out. As far as I can tell, the far side anchor (opposite starting point) doesn't quite grab hold and anchor onto the perimeter and therefore gets dropped down into the model or gets pulled off by the hotend nozzle the next pass.

Reply to this email directly or view it on GitHub.

[OhmEye]

@alexrj Point taken. I had the files in the same directory as the pictures but forgot to link them, posts are updated to include the file links.

I'm not sure of the semantics of anchor vs. overlap. There has to be some overlap for bridge lines to anchor at the ends, whether that is called "anchoring" or "overlapping" is unclear to me. Without any overlap, the end of the bridge doesn't contact anything to anchor to. Whatever the terminology, I see two different properties in play here:

1. The endpoints of the bridge contacting anchor points in the same layer.
2. The endpoints of the bridge extending beyond the bridge length and over filled area of the previous layer.

Anchoring to bridged perimeters is an example of # 1 where there is no contact with a previous layer at or beyond the end of the bridge line. There still needs to be some overlap of the endpoint and the perimeter, else there is no contact and the endpoint fails to anchor and just falls into air.

Anchoring to a non-bridged perimeter that has more perimeters and/or infill beyond it in the layer below is an opportunity to extend the bridge points past the anchor points. This gives the bridge a good "running start" over a layer to adhere to, and a longer run at the other end before it reverses for the next bridge line. This is what Cura and Skeinforge do and it's very successful with minimal challenge.

[diggit]

Yeah, I know about flow ratio settings for bridges, but extruder paths are too close to each other when bridging. Is it was described above in 1st post "The bridge lines are very close together and result in my most common bridge failure mode: The nozzle dragging adjacent lines into a mess..."
By "extrusion width" I meant distance between those bridge paths. Sorry for misunderstanding.

[nophead]

With skeinforge the bridge spacing is the same as any other solid layer.
That means the filaments don't actually touch each other because they are
cylindrical instead of rectangular. The nozzle would still brush over the
adjacent ones though.

On 28 April 2013 22:25, Patrik Bachan notifications@github.com wrote:

Yeah, I know about flow ratio settings for bridges, but extruder paths are
too close to each other when bridging. Is it was described above in 1st
post "The bridge lines are very close together and result in my most common
bridge failure mode: The nozzle dragging adjacent lines into a mess..."
By "extrusion width" I meant distance between those bridge paths. Sorry
for misunderstanding.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1090#issuecomment-17143002
.

[nophead]

BTW, the width is defined by the flow rate / freed rate ratio, not the
nozzle size.

On 28 April 2013 22:33, nop head nop.head@gmail.com wrote:

With skeinforge the bridge spacing is the same as any other solid layer.
That means the filaments don't actually touch each other because they are
cylindrical instead of rectangular. The nozzle would still brush over the
adjacent ones though.

On 28 April 2013 22:25, Patrik Bachan notifications@github.com wrote:

Yeah, I know about flow ratio settings for bridges, but extruder paths
are too close to each other when bridging. Is it was described above in 1st
post "The bridge lines are very close together and result in my most common
bridge failure mode: The nozzle dragging adjacent lines into a mess..."
By "extrusion width" I meant distance between those bridge paths. Sorry
for misunderstanding.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1090#issuecomment-17143002
.

[OhmEye]

@nophead I would think it depends on the line widths and size of the nozzle flat, but regardless in actual practice I have significant problems with slic3r's close spacing resulting in the nozzle dragging adjacent layers and essentially no such problem at all with the bridging as done by KISSlicer or Cura. The main problem I have with KISSlicer is when it bridges on an angle to a bridged perimeter, the line spacing itself works very well and only unsuccessful anchoring to a slightly drooped bridged perimeter.

@nophead As I understand it, the nozzle size in slic3r is used for line width and spacing for bridging. Also, I'm no longer used to thinking of line width in terms of ratio, since configuration starts with the width setting and the flow rate / feed rate is calculated from the width, not the other way around.

[nophead]

I suppose the difference is the bridge filaments are discrete and don't
touch, whereas with slic3r they do so drag on each other (rather than the
nozzle).

On 28 April 2013 22:45, OhmEye notifications@github.com wrote:

@nophead https://github.com/nophead I would think it depends on the
line widths and size of the nozzle flat, but regardless in actual practice
I have significant problems with slic3r's close spacing resulting in the
nozzle dragging adjacent layers and essentially no such problem at all with
the bridging as done by KISSlicer or Cura. The main problem I have with
KISSlicer is when it bridges on an angle to a bridged perimeter, the line
spacing itself works very well and only unsuccessful anchoring to a
slightly drooped bridged perimeter.

@nophead https://github.com/nophead As I understand it, the nozzle size
in slic3r is used for line width and spacing. Also, I'm no longer used to
thinking of line width in terms of ratio, since configuration starts with
the width setting and the flow rate / feed rate is calculated from the
width, not the other way around.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1090#issuecomment-17143377
.

[nophead]

In fact the plastic is being stretched as it is pulled across the bridge
(otherwise it would sag) which means its surface is expanding so if that
bonds to the path next to it it will exert a shearing force on it, hence
the disruption.

On 28 April 2013 22:58, nop head nop.head@gmail.com wrote:

I suppose the difference is the bridge filaments are discrete and don't
touch, whereas with slic3r they do so drag on each other (rather than the
nozzle).

On 28 April 2013 22:45, OhmEye notifications@github.com wrote:

@nophead https://github.com/nophead I would think it depends on the
line widths and size of the nozzle flat, but regardless in actual practice
I have significant problems with slic3r's close spacing resulting in the
nozzle dragging adjacent layers and essentially no such problem at all with
the bridging as done by KISSlicer or Cura. The main problem I have with
KISSlicer is when it bridges on an angle to a bridged perimeter, the line
spacing itself works very well and only unsuccessful anchoring to a
slightly drooped bridged perimeter.

@nophead https://github.com/nophead As I understand it, the nozzle
size in slic3r is used for line width and spacing. Also, I'm no longer used
to thinking of line width in terms of ratio, since configuration starts
with the width setting and the flow rate / feed rate is calculated from the
width, not the other way around.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1090#issuecomment-17143377
.

[OhmEye]

Here's an example of Slic3r placing bridge anchors in midair. Instead of simply bridging across the gap, it chooses patterns that I don't understand that result in poor bridge paths that cause extrusion to fall into the empty gap.

Here is the layer before the bridge:

Here is the bridge layer:

Just for reference, the bridge layer that Cura produces is clean and prints easily and nicely:

The STL and Config used with recent git master:
http://ohmeye.com/download/debug/debug_bridging/config3.ini
http://ohmeye.com/download/debug/debug_bridging/bushingmount.stl

[MLWORKX]

Same here: strange angle of bridging and no option for setting it - causes drop on some lines especially on the edges.

[alranel]

@OhmEye, I reduced overlap now and got positive feedback from @Joaz about it. Looking forward for yours.

[OhmEye]

After looking at current results in a viewer for my test files, I'm not sure what I should be looking for, the bridge layers appear the same. What does BRIDGE_OVERLAP_FACTOR affect? Is it related to bridge line spacing, anchor endpoints, or something else?

[jamesarm97]

I didn't really see a difference when I sliced by just looking at the preview. I do have some feedback on a file I just sliced and looked at. Why wouldn't you do a perimeter around the area being bridged to give it something to grab onto (at least in this example). You can see in Bridge1 that it has an internal hex pattern then in Bridge2 as it puts down the first bridge layer that there are lots of areas where the lines end and are over "air". If there was a perimeter put down first at least there is a better chance that there will be something to grab ahold of on the ends.

The other slicer always bridges at a 90 degree so it will usually anchor to the outside perimeter:

[whosawhatsis]

The bridge spacing is good for some materials. With nylon, it allows me to print bridges that are perfectly flat and water-tight in one layer, though it does cause some problems with PLA due to the heat staying in the area of the just-printed plastic and the plastic's tendency to stick to the nozzle (different nozzle geometry/material choices make a big difference here), so maybe there should be a configuration option?

Like others, I am frequently annoyed by Slic3r's choice of direction and amount of anchoring for bridges. At a minimum, the bridge should overshoot the edge by the spacing of the infill pattern (assuming it doesn't encounter another perimeter first). This also goes for internal bridges (first solid layer after infill), as these are frequently insufficiently anchored. Of course, when printing with zero infill, internal bridges MUST extent all the way until they encounter a perimeter (skeinforge does them this way regardless of infill density) to be anchored at all.

For bridge direction, it seems the best way to choose the direction is to average the angles of the perimeter segments (weighted by length) of the bridged area. This should ensure that as many of the threads crossing the bridge are anchored on both sides (rather than starting/changing direction in mid-air) as possible.

[jamesarm97]

Perfect explanation from everything I have seen using both skeinforge on my makerbot and slic3r on the Rostock.

James Armstrong

On May 31, 2013, at 7:34 PM, whosawhatsis notifications@github.com wrote:

The bridge spacing is good for some materials. With nylon, it allows me to print bridges that are perfectly flat and water-tight in one layer, though it does cause some problems with PLA due to the heat staying in the area of the just-printed plastic and the plastic's tendency to stick to the nozzle (different nozzle geometry/material choices make a big difference here), so maybe there should be a configuration option?

Like others, I am frequently annoyed by Slic3r's choice of direction and amount of anchoring for bridges. At a minimum, the bridge should overshoot the edge by the spacing of the infill pattern (assuming it doesn't encounter another perimeter first). This also goes for internal bridges (first solid layer after infill), as these are frequently insufficiently anchored. Of course, when printing with zero infill, internal bridges MUST extent all the way until they encounter a perimeter (skeinforge does them this way regardless of infill density) to be anchored at all.

For bridge direction, it seems the best way to choose the direction is to average the angles of the perimeter segments (weighted by length) of the bridged area. This should ensure that as many of the threads crossing the bridge are anchored on both sides (rather than starting/changing direction in mid-air) as possible.

—
Reply to this email directly or view it on GitHub.

[alranel]

@OhmEye, I reduced overlap further since I last wrote a message here. I actually removed any overlap and added a 0.05mm empty gap between bridge threads. I got positive feedback about this. Can you check how this works on your side?

[OhmEye]

I have been using it and find the spacing is very much improved. The angle is often improved as well, bridging perpendicular and in an optimal direction. I still am having a high rate of bridge failures due to some anchors not sticking in cases where it would succeed if it used longer anchors instead of barely overlapping the perimeter of the layer below before reversing direction.

When I do a plate of 30 copies of an object with a bridge, often all the copies have identical bridge failures. I can look down the rows of completed prints and see the same dragged loops due to failed anchors. This seems so consistent to me that I don't believe it's entirely printer tuning or random poor luck when an anchor fails to stick.

[alranel]

@OhmEye, let's stick to test cases. Do you have a reproducible test case that shows one problem so that we can work on that one? How should we consider the status of this issue? Fixed?

[OhmEye]

I will work on providing reproducible test cases. I'm not using current HEAD now due to other issues and will make this a priority when I have some printer time available to specifically print bridge tests.

[OhmEye]

Current stable branch does nice bridging, but master branch has reverted to some of the old bad bridging, specifically it again is bridging at an angle and anchoring to bridged perimeters. I hope this is a reversion and not intentional. Here are examples:

The layer before bridge:

Bridge layer 1, perpendicular to bridge, no anchor to bridged perimeter with stable branch:

Bridge layer 1, angle to bridge, anchors to bridged perimeter with master branch:

Bridge layer 2, perpendicular to bridge, no anchor to bridged perimeter with stable branch:

Bridge layer 2, angle to bridge, anchors to bridged perimeter with stable branch:

The bridge 1 and bridge 2 that master branch does are even at different angles. Is there are reaon that master branch has returned to doing angled bridging, or can it be returned to the much better perpendicular angle that stable branch uses? This is causing master branch to make bridging be unecessarily challenging again in my opinion.

Files to reproduce this:
http://ohmeye.com/download/debug/debug_bridging/Y-Idler-tensioner.stl
http://ohmeye.com/download/debug/debug_bridging/bridge_angle_config.ini

[ledvinap]

There are few bugs in bridge code in master. One is clipper related (#1894). Then there are few problems with code (wrong incremental rotation, cliped lines end on anchor edge and are not recognized as valid, valid bridge test is inverted. I have a crude fix, I'll try to post it.

[ledvinap]

Here is pull request with temporary fix: #1917

[ledvinap]

Current master should work as long as perimeter width is larger than infill width.

[alranel]

Current master was fixed. @OhmEye, when you have some time could you test it and tell me whether we can close this issue? Thank you!

[alranel]

As of current master, all bridges in @OhmEye's test object are orientated correctly. A little test suite is also attached to the bridge detection algorithm, so any regression caused by further development should be prevented.