bridge_flow_ratio behavior not very intuitive

[jmding8]

Version

2.3.3

Operating system type + version

Windows 10

3D printer brand / version + firmware version (if known)

Kingroon KP3s, Marlin 2.???

Behavior

• The behavior of the bridge_flow_ratio parameter is not very intuitive.
• The tooltip describes reducing the flow to "slightly pull" the bridge for better quality, but doesn't describe what a sane range of values are. It is difficult for a user to know when to adjust the value, and what value to use.
• The tooltip also does not describe how the parameter affects the bridge line dimensions (XY width, and Z heighth).
• Furthermore, empirically I found that bridge_flow_ratio is actually proportional to the bridge_line_width^2. While this makes sense from a volumetric flow perspective, it is quite difficult for most users to reason about.

Possible Alternatives

I think what is likely to be the most important parameter for the user to be able to configure is the ratio of bridge_line_width / layer_height. Here's why I think this:

• Extrusions in free air form approximately circular cross sections
• Attempting to bridge with bridge_line_width > layer_height is basically attempting to print bridge lines with flat, rectangular bridge cross sections. However, since these bridge lines are printed in free air and will actually come out with a circular cross section, the printed line is taller (in z) and narrower (in x-y) than the slicer expects it to be. This results in poor clearances, and gaps between the bridge lines.
• Similarly, bridging with bridge_line_width < layer_height results in bridge lines that are shorter (in z) and wider (in x-y) than expected. This results in poor adhesion to the above and below layers.
• In my opinion, a sane value of bridge_line_width / layer_height would be ~1.2. This results in slightly thicker bridge layers than ideal, but also allows the bridge lines to anchor well at their start and finish.

Would love to get your feedback on this analysis!

[bubnikv]

In addition, in PrusaSlicer 2.4.0 we introduced a new parameter "thick_bridges", which is on by default to match the 2.3.3 behavior and the bridging works differently see the PrusaSlicer-2.4.0-alpha1 change log.

It is not easy to change the meaning of a settings as it is being used by a plenty of profiles around the world. It is reasonable however to change its default value and tooltip / documentation.

I understand your goal to cover a surface with bridges reasonably, however at the end of the day the bridging quality depends on your extruder, cooling, extrusion speed and this all depends on extrusion rate thus bridge flow ratio. I am not sure whether we could do much better than to let the user test his own machine and filament profiles on his own setup.

[jmding8]

Thanks for the feedback, and for pointing me to the changelog. I read up on it and have a few thoughts:

It is not easy to change the meaning of a settings as it is being used by a plenty of profiles around the world.

Good point, that makes total sense. It's the classic backwards-compatibility issue. It may make sense to invest in a more future-proof versioning system. Effectively, 2.4-alpha1 introduces a simple versioning system for bridging via a true/false boolean toggle thick_bridges_enabled. The limitation here is that a boolean toggle locks us into only 2 bridging implementation versions. If instead we offer a dropdown menu { bridging_mode: [v0_thick_bridges, v1_modern_bridges, ...] }, that leaves more flexibility to update bridging implementations in the future, while still allowing users to select legacy modes to maintain compatibility.

at the end of the day the bridging quality depends on your extruder, cooling, extrusion speed and this all depends on extrusion rate thus bridge flow ratio.

Yes, all of these factors influence bridge quality. However, the fact that these other variables are important is separate from the fact that bridge_strand_diameter should always be ~1.2 * layer_height (assuming my reasoning is correct).

Arguably, we're no longer in the early days of 3d printing where flexibility and customizability was the priority. We should be trying to empower users to get the most out of their prints by reducing the immense dimensionality of the slicer-parameter space.

Right now, every time a user changes layer heights, they will need to re-tune bridge_flow_ratio in order to hit that ideal bridge_strand_diameter of ~1.2 * layer_height. Additionally, this is made more difficult by the fact that bridge strand diameter is an opaque function of bridge_flow_ratio and nozzle_diameter.

However, if we expose a parameter bridge_strand_diamter_ratio, that adjusts that ~1.2 scalar value, then we reduce the dimensionality of bridging parameters from two inter-related variables (layer_height and bridge_flow_ratio), to one independent variable (layer_height) and one basically constant value (bridge_strand_diameter_ratio).

The other bridging parameters (cooling, speed, etc) should all be tuned after bridge_strand_diamter_ratio, since they don't affect the relationship between bridge_strand_diameter and layer_height.

Separately, looking at the changelogs it mentions that:

With "thick_bridges" disabled... extrusion spacing is maintained while modifying the extrusion width and / or height to reach the prescribed extrusion ratio.

This suggests that the new implementation attempts to independently control extrusion width and height. In reality, because bridge extrusions are performed in free air, the bridge strands are circular in cross section and cannot have their width and height independently adjusted. Thus the new implementation will not achieve it's design intent.

Additionally, regardless of whether we are in legacy_implementation land, or moder_implementation land, the bridge_strand_diameter / layer height ~ 1.2 relationship is still fundamental to bridging performance, so it would make sense to make it directly controllable.

Sorry thats a bit rambling. In summary:

1. Backwards compatiblity is a challenge, but a robust versioning system can help us cope
2. The bridge_strand_diameter vs layer_height relationship is significant and independent from other bridging parameters. The current system forces the user to re-tune bridge_flow_rate on a per-layer-height basis, which is unnecessarily difficult.
3. The bridging implementation in 2.4-alpha1 seems to be built on a faulty assumption of oval/rectangular/flat bridge strands

IMO, the solution would be:

1. An enum-based versioning system for bridging, instead of a boolean flag.
2. Re-working the bridging implementation in 2.4-alpha1 taking into account the fact that bridge strands are circular in cross section
3. Expose a new parameter for the new 2.4-alpha1 bridging implementation: bridge_strand_diameter_ratio, instead of relying on the old parameter bridge_flow_ratio which seems to have little basis in the physical reality of bridging behavior.

Let me know what you think?

[bubnikv]

The issue with bridging is that one transitions from non-bridging to bridging strand while maintaining the thread separation. Your assumption on extrusion rate to achieve thread spacing where the threads touch may be correct from the geometric point of view, however the best bridging may be achieved with different thread thickness, thus for example leaving some gaps between the threads. Thus your proposal optimizes for one of the criteria only.

The bridging implementation in 2.4-alpha1 seems to be built on a faulty assumption of oval/rectangular/flat bridge strands

No. The "no thick bridges" implementation in 2.4-alpha1 is designed for bottom surfaces over supports.

There is just too many contradictory conditions to be optimized for, which is difficult.

[bubnikv]

What I am saying is that you are trying to apply one geometric formula, while there are other constraints to optimize for and IMHO at the end of the day one has to tune many parameters in accord and that takes a lot of time. This is also one of the reasons why Prusa's own printers print so well, because we invested a lot of time fine tuning the parameters to work together.

[jmding8]

Hmm, @bubnikv I think we're talking past each other a bit. I would like to convince you that:

1. unsupported bridge strands always form circular cross sections
2. there is a strong constraint that for good results, bridge strand diameter needs to be ~1.2x layer height
3. this constraint needs to be enforced regardless of all the other bridging parameters

Do you agree in principle that if I can convince you of those three points, then it would make sense for PrusaSlicer to allow direct configurability of the bridge_strand_diameter / layer_height ratio?