no support under solid infill if sparse infill is used

slic3r / Slic3r

Open Source toolpath generator for 3D printers

https://slic3r.org/

GNU Affero General Public License v3.0

3.29k stars 1.29k forks source link

no support under solid infill if sparse infill is used #2060

Open curiouspl2 opened 10 years ago

curiouspl2 commented 10 years ago

it affects all versions.

there is issue with infill falling down in case of sparse infill being used. screenshot from 2014-05-27 16 47 10

it could be solved in several ways :

support all the way down as anchoring perimeter
modification of shape of infill (deformation) up to shape of top infill
extending bridges of top infill to nearest edges
increasing density of infill few layers before top infill occuring
alternating solid and concentric fill (simplest but will fail in case of lack of 'corners')

screenshot from 2014-05-27 16 48 51

perhaps some more?

simple test files : http://83.15.83.106/tmp/slic3r/void%20infill.stl http://83.15.83.106/tmp/slic3r/void%20infill.gcode

use less than 10% of infill , or no infill at all for 'best' results.

whosawhatsis commented 10 years ago

I've been saying for a while that in cases like this, the solid fill needs to take the density of the sparse fill into account. Ideally, it would extend the lines until they intersect either a perimeter or a line of infill underneath, but it would be simpler to just include an extra margin all the way around the area being filled wide enough to ensure that it touches such a feature.

alranel commented 10 years ago

@whosawhatsis's idea is the easiest one. I've not been ignoring it, just had no time to work on it. :) A long time ago I also implemented a feature that projects the boundaries of solid infill to the ground, providing anchors for it to bridge on. This also allows hollow objects to be bridged.

whosawhatsis commented 10 years ago

@alexrj That algorithm was actually in one of the releases, wasn't it? I have a yoda head on the shelf that is almost completely solid and used more than half a spool because of something like that.

alranel commented 10 years ago

@whosawhatsis, no, that work was never merged...

whosawhatsis commented 10 years ago

That's odd, because I know that that model had some weird extra lines within the infill area, which seemed to follow the contours of features higher-up in the model. IIRC, this would have been 0.9.9, or possibly a bit earlier. Might be what the "Superfluous extra perimeters were generated" item listed in the 0.9.10b changelog was referring to?

alranel commented 10 years ago

Could be..

curiouspl2 commented 10 years ago

perhaps it could be somehow possible to just enforce full solid layer somehow in such situations? this would be quite 'good enough' at least in meantime.

even 'manual' enforcement of full solid layers would be quite ok. (i.e. ability to just specify at which layer full solid layer should be enforced, or - even better - option to just manually change fill density at specific layer heights)

was also thinging as 'post-pre processor' hack. it's somehow slow method - first generate gcodes as usual, then check for all solid layers present by analyse of i.e. comments . then compare them with previous infill layers, and draw simple .stl file containing small extruded structures of shape being merge of voids of infill + shape of solid infill at specific layer height. this way one would get 'corrective stls' which one could just merge into object, and with those one can slice again and generate 'proper' gcode.

curiouspl2 commented 9 years ago

hello any news on that bug? how about just option to trigger solid layer temporaily? it's really annoying as-is...

lordofhyphens commented 7 years ago

@curiouspl2 your test case is a dead link now. Please upload here to github: https://help.github.com/articles/file-attachments-on-issues-and-pull-requests/

Could you check with 1.3.0-dev as well?