It appears that as long as support material is enabled, support will be generated for all overhang, even if the overhang angle is above the overhang threshold. For example, consider this object in openscad, which has 45-degree overhang:
cylinder(r1=5, r2=5+10, h=10);
Support material will be generated both if the overhang threshold is set to 40 and to 50. But it should not be generated if the threshold is 40 (or is it the other way).
something is deffinitely off with the overhang threshold
I tried to slice http://www.thingiverse.com/thing:18177
10° produces a lot of support - which seems to be ok, because ... well .. 10° are 10° :)
but 80° threshold, which should yield almost no support at all despite the cap and the teeth, still produces way too much support:
Even though it makes no sense at all, I tried to use 100° overhang threshold. Generating the GCode took forever but no support was generated :)
I tried slic3r 0.9.8 and 0.9.9. Both seem to have this problem.
btw: 80% threshhold with rectilinear-support instead of honeycomb:
and these were the settings for the last build:
been trying out the support feature - the model has some 45s that print well at low speeds - using an Overhang threshold of 120 I can eliminate the support for those however there is a requirement on another section - when slic3ed the resulting g code has several odd moves on every layer
see file links attached - line 195 in NLL34 - I suspect its something from the now missing support on the 45s which would be part of the path if they were to be printed - its a Z retract .37mm - NLL34Support shows missing support from NLL34
the print is one of the best prints I've had with support material but the extra moves are annoying
I am definitely experiencing this as well... the angle you enter in seems to have little actual effect on where the support is generated, and whatever effect it has is weird. 0 generates roughly the same as 15, 30, 60, 80, etc. At one point I got it to work by putting in numbers larger than 90 (i.e. 130) but I don't have the gcode for that available to upload.
I can confirm this issue, my test cases (sphere and horizontal cylinder) do also produce way to much support with overhang threshold set to automatic detection (=0) as well as manually set to 45°.
On a slightly related note, when I was printing my test sphere, it never worked very well because the support material was printed to far below the sphere, and it never got a chance to attach itself. I reduced the "interface layers" to zero, as well as the "interface pattern spacing" but neither had any effect. Then I went back to the old slicer 9.8 and it did it just fine (sphere attached to support).
@adjwilley that's exactly my observation, too. Just thought it may have been caused by my experimental support material, but I had a look on the gcode and indeed the support isn't connected well to the printed sphere. Thanks for the hint, so maybe my support material would have performed much better without this bug ;) This gives hope for more testing..
I'm also getting far too much support on even the steepest slopes when I only need it for a couple of overhangs.
Therefore, my options become:
A) Disable support material (the overhangs will collapse during printing)
B) Set threshold to 0-89 (support everywhere no matter what number, which ruins my surface finish unneccissarily)
C) Use angles from 91-180... which gives me unpredictable results, often not right either and missing some overhands.
Putting in 90 causes a crash.
I'm using 0.9.9 on Win7 x64
Same problem here. Slicer produces the same amount of support no matter what value I choose.
No problems with Slicer 0.9.8 though. And I'm also running Win7 64bit. I could upload some example files if necessary.
OK so i don't do something stupid, it's simply a bug
Hello, new support material is now merged in git master. The overhang threshold option, which was broken in 0.9.10b, is now working. Thank you!
Hi, just tested here on the latest git d7656f5.
Tried to set overhang threshold to 70, but it generate support everywhere.
tested on object http://www.thingiverse.com/thing:135194