Don't cancel support enforcers with "don't support bridges" #5105
Comments
|
This also appears when using good-old custom box enforcers, so it is not a bug in the new painter. Even a small change from 0.2 mm fixes it. |
|
Maybe you have "dont't support bridges' enabled? |
Yes it is included, but sometimes support was needed for large bridges, but not needed for normal ones. |
|
Currently the support enforcers (painted or boxes) are canceled by the
"don't support bridges" feature. We may change it in the future, but for
now this is what we have. We will not be able to change the behavior in
PrusaSlicer 2.3.0 release.
pá 11. 12. 2020 v 15:52 odesílatel Shama71 <[email protected]>
napsal:
… Maybe you have "dont't support bridges' enabled?
Yes it is included, but sometimes support was needed for large bridges,
but not needed for normal ones.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5105 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMPSI753ZDVCHYVPCXVWWLSUIWZBANCNFSM4TN5O2KA>
.
|
|
Out of curiosity, what would be the design requirements for that logic? I understand the logic behind the automatic support planner not generating support for every bridge feature. But, if a user wants to print a cup type object, and using "Support enforcers only", explicitly define his own supports, why would this option stop him from doing so? |
It was not by design, it was by implementation. The implementation of support enforcers was significantly simpler that way. We may change the behavior in the future. |
|
@bubnikv thanks for the prompt response. That makes more sense. Since it is not hard to workaround by disabling that checkbox, it shouldn't be a high priority task. There may be some value in disabling that box in the default profiles though, or adding some context in the tool tip, to avoid duplicate ticket/bug reports from new users. |
bubnikv
changed the title
|
The support enforcers newly take precedence over "don't support bridges" and "on build plate only".
|
|
Actually, in the first message, I pointed out that when the height of the layer changes, the behavior of the support placement changes. |
1) If "support on build plate only" is enabled, the support columns are newly trimmed to not land on top of an object. However this may make the column too small to be stable. 2) Support enforcers newly take precedence over "supports on build plate only" and over "don't support bridges". 3) Some refactoring of the support generator code for clarity: Reduced some of the worst spagetti offenders. Fixes Support generated even if support on build only activated #915 Fixes Bug: supports on build plate only #1340 Fixes Bottom interface layer is not generated , support on build plate only. (long open defect) #4199 Fixes option "supports on build plate only" does not work #3980 Fixes No support interface layers generated #1997 Fixes Feature Request: Option to combine results of 'support from build plate only' and 'support enforcers only' #2801 Fixes Support interface isn't generated: build plate only + blocked by model + support enforcer #3831 Fixes Support Enforcer don't create interface layers #5748 Fixes Support Enforcers Don't Have Top Loops/Raft #1870 Fixes Don't cancel support enforcers with "don't support bridges" #5105
|
Fixed with 9f09f03 |
Version
2.3.0-alpha3+win64
Operating system type + version
Windows 10
Behavior
Custom supports by painting no support with 0.2mm.
For other layer height support is correct.
Project File (.3MF) where problem occurs
Is correct
No support
Bug - Support.zip
The text was updated successfully, but these errors were encountered: