Supports are not generated correctly when overhanging surfaces are small.

[michaelnew]

If my extrusion width is set to .5mm, any surface that's less than 1mm in diameter is either not supported correctly, or not supported at all.

Here's a test case I came up with. The cone on the right has a flattened point with a diameter of about 1.3mm, and the one on the left has a perfect point of diameter zero. Only the rightmost two cones have a diameter greater than 1mm, and they are the only two that are supported correctly. For the other cones, support is either not created at all, or doesn't reach the actual object.

This problem shows up frequently on organic models, and in some cases makes them unprintable.

I'm using OS X 10.10.4, and I'm on the latest dev build, commit ID 70ec433e6776627421e4724bfe6094ea0a74ed0b

2839.zip

[Lenbok]

Duplicate of #2222

[lordofhyphens]

Duplicate issue #2222 was closed, test case is dead links because Dropbox. Closing. If still a problem with 1.3.0-dev (be sure to fix the support threshold to 60%) please comment and I will reopen. Current -dev builds: http://dl.slic3r.org/dev (pick newest version) Attaching files: https://help.github.com/articles/file-attachments-on-issues-and-pull-requests/

[michaelnew]

It's improved, but not fixed. This is with slic3r freshly built from master, commit 4c14c656f5c9adf712dfbcea0dc1b7c044131c37.

The pillars still look a little odd, but they are at least printable now. Setting the support pattern to honeycomb or rectilinear rather than pillars gives a more reasonable support structure, but in any case there are still two problems.

The first problem, obviously, is that there's no support for the leftmost cone that comes to a point. I haven't been able to find any combination of settings that will get it to generate support there.

The second problem is that for the second-from-the-left point, the support structure doesn't have the correct contact distance.

Because the cone comes to such a small point, the very bottom can't be printed because it's smaller than the extrusion width. The support is spaced .2mm below the mesh rather than .2mm below the actual layers that are being printed. Here's a more exaggerated example to illustrate the point. Model on the left, slicing results on the right:

The support structure is so far away that it's effectively useless.

It might seem like an edge case, but I've run into these issues many times when trying to print organic models. Often times the model will be completely un-printable.

Here's those stl files. support_test_multi_point.stl.zip support_test_thin_point.stl.zip

[Lenbok]

Interesting case! It looks like the support is generated to support the surface of the STL file rather than to support the post-slicing volume of the object, suggesting that these aliasing problems may be present to a lesser degree everywhere (even on non acute angles, the calculated height for the support could be off by about half a layer height, affecting print quality and the ease of support removal). Supporting the post-slicing object volume could give much more consistent support results.

BTW, what happens if you use the prusa3d fork of slic3r, which apparently has a rewritten support implementation?

[michaelnew]

@Lenbok Here's what I get with the prusa fork:

Same two problems. I played around with support on their fork last week, and I get the feeling it's still very much in-flux. Might be worth waiting to see how it pans out for them, but the fact that there's still those two major issues isn't very promising.

I'm sure you're right about the way support is being generated. To me it seems like supporting the sliced version of the object might be simpler, but if it isn't being done that way now I'd image it would be a huge refactor.

[whosawhatsis]

The problem here is that the support algorithm looks at the angle of a face to see if it needs support. For a downward-pointing cone, there is no face at the bottom that needs support, so none is generated. Obviously, this means that downward-facing edges and points don't trigger support generation, which is a problem for some models.

An edge-based algorithm might work better than a face-based one, but it might also be necessary, as you say, to generate support based on the sliced layers rather than the geometry of the input model. You could use a rule in the form of, say, if you subtract the previous layer from the current layer, anything that is more than X% of an extrusion width thick needs support, and any new islands that weren't in the previous layer at all do too.

[lordofhyphens]

Sigh. I need to go through the entire hierarchy and close all but one. Really frustrating when there's 6 issues that are probably the same thing and should have been in the same issue (with their different test cases).

@whosawhatsis I bet that one with nothing under it has no bridging layers because they were either removed during a prune process (to clean up tiny areas... which is what all of these are).

@michaelnew With the current supports, could you set the support threshold to 60% and play around with that number? Also, you posted a STL, but not a config ^^;

[michaelnew]

@lordofhyphens I spent a few hours trying to isolate this issue as well as I could. As far as I can tell, layer_height and first_layer_height are the only things that affect it. Here's three examples along with config files to try and demonstrate. This is all with the latest master, commit 467dc324f61ebb324916faef07a748226e4c3f42.

This is with both first_layer_height and layer_height set to .1mm. I tried changing every other setting I can think of, including setting the support threshold to 60% (along with many other values), and nothing seemed to affect the problem. support-test-1.ini.zip

This is with first_layer_height set to .15mm and everything else exactly the same (I double checked with a file diff). I would describe it as... differently broken. And again, I played around with as many other settings as I could without any real effect. support-test-2.ini.zip

Leaving first_layer_height at .15mm and setting the layer_height to .2mm causes the support generation to hang indefinitely. I let it sit there for about 10 minutes and it just says generating support support-test-3.ini.zip

Let me know if there's something I can investigate further.

[lordofhyphens]

@michaelnew I see you have support_material_threshold=0. Set it to some value between 60% and 200%. The old value of 0 is erroneous. This is a relatively recent change (last couple weeks), sorry.

[lordofhyphens]

Sorry for the close/open spam. I'm confusing myself apparently.

[michaelnew]

@lordofhyphens I have, and it doesn't seem to matter. Here's those same 3 configs set to 80% support threshold if you like, but there's no difference.

support-test-1.ini.zip support-test-2.ini.zip support-test-3.ini.zip

[lordofhyphens]

Still hangs on the third case then? :-/

Thank you for your efforts in experimenting and providing these test cases.

[lordofhyphens]

I suspect that the points of the inverted cones are being removed as part of a filter pass, actually.

[michaelnew]

...actually no, I'm sorry; I was too hasty with that. It no longer hangs on the third case. # 3 now looks exactly like # 1. The other issues are still there, but it does at least generate support.

[lordofhyphens]

Oh good. Yes, setting that value to 0 is invalid and I can definitely believe that it would cause it to look like it's hanging. I'm just glad we don't have two problems instead of one.

[michaelnew]

Ha, yeah that's something at least :)

[lordofhyphens]

@michaelnew since I have your attention, can you take a look at https://github.com/alexrj/Slic3r/wiki/Support:-Requirements and add some edits to the bottom of the page if you have any comment?

(our OSX builds are now signed by the way)

[michaelnew]

I went ahead and added a comment with the proposed rule:

Support material shall not be generated without support material underneath it, unless it is at Z=0 (or rather, support can't start in mid air)

I think this, along with the other rules already spelled out, covers the different issues that are showing up here. Best I can figure, there are 3 different violations.

1)

Support material shall be generated for all areas that contain unsupported perimeters

The fact that the leftmost point is completely unsupported (depending on what the layer height is set to) obviously breaks this one.

2)

The distance from the top of the support to the bottom of the supported structure shall be defined as contact_distance_z.

The second-from-the-left point has a problem here. The bottom few layers of the cone are too narrow to be printed, and the support structure doesn't compensate. So the contact distance is too far. That long, thin, inverted cone example from a few comments up shows the issue pretty clearly.

3)

Support material shall not be generated without support material underneath it, unless it is at Z=0 (or rather, support can't start in mid air)

The second-from-the-left point sometimes has a problem here, depending on the layer height. Sometimes the support just starts in empty air. I think this only happens when the supported surface is very small (i.e. the polygon is smaller in diameter than extrusion_width * 2), but I haven't tested it enough to be completely sure. It also only seems to happen when support_material_pattern is set to pillars.

It also seems like some of the supports are a lot thinner than they should be when they're set to pillars, but I'm not sure if that should be a testable rule since sometimes you do want thin supports.

[NateTG]

This problem shows up frequently on organic models, and in some cases makes them unprintable.

As a practical matter, can you print the model as a modifier mesh? (i.e. load a bounding box as a part, set the perimeters to 0, and some non-zero infill density, then load your model as modifier mesh, and then add perimeters and other print settings to the modifier mesh?)

[bardiir]

+1 to this issue, you can also use this to test it: http://www.thingiverse.com/thing:2232766 The handle of the bow model does have sort of two cubes on top and bottom. With a layer size of .4 these do not generate support either.

As you can see the left handle did get support generated, the right one is just hovering in mid air.

[Kolodner]

I've been running into pillar generation issues especially with this part, where the hair/head isn't being supported adequately without encasing the whole print:

https://www.thingiverse.com/thing:2147079/#made