slic3r / Slic3r

Open Source toolpath generator for 3D printers
https://slic3r.org/
GNU Affero General Public License v3.0
3.32k stars 1.29k forks source link

[feature suggestion] 2D Layer Modifiers #2640

Open Vicious-one opened 9 years ago

Vicious-one commented 9 years ago

There's one feature I've not yet seen in any slicing software:

Manually-defined (drawn by a mouse with lines or bezier curves) 2D per-layer polygon modifiers.

They can work exactly like 3D Modifier meshes, but with a single slice layer only.

If a user encounters a show-stopping bug or a suboptimal(segmented) infill, he just selects an anchor vertex (to account for subsequent rotation and/or cloning), draws a polygonal shape with a mouse, which overrides perimeter and infill settings, disables bridge detection, etc. directly in the toolpath window.

This can allow to produce acceptable results when automatic slicing just fails due to some regression or faulty 3rd party library.

In other words, this functionality will enable the technically-inclined user to tell Slic3r: "Listen, you fscking piece of software, stop impeding my efforts to produce a usable toolpath, disable your incomprehesible inhumane logic for a second and just fill this region exactly this way, because I have work to do besides fighting with your persistent efforts to waste my time".

dexy31337 commented 9 years ago

I'm almost sure this feature isn't going to be implemented, as it requires too much code to be written, which shouldn't be in slicing software. Also, "slice layer" comes after slicing is done, so it's hard to specify what exactly you want to be generated, especially if you'll want to modify something like layer height. Also, I believe that this task is done perfectly with modifier meshes, in 3d editing software, where it should belong IMHO. Just make a mesh with a height of 1 layer, depending on your printing preferences and place it on a corresponding height.

Vicious-one commented 9 years ago

@dexy31337 Yes, this is more of a post-processing than slicing. Currently I have to resort to serious g-code hacking when slicing goes wrong again. In fact, it does go wrong nearly every time when bridging tricky gaps or in narrow areas.

Yes, one might say I should taylor the models for my slicing software to avoid its army of bugs, but seriously...

By the way, there is currently no way you can disable bridge detection and subsequent infill segmentation in Slic3r, even using modifier meshes.

Anyway, I think this kind of tool, well-integrated into slicing software (using its profiles, infill algorithms, etc), is going to be invaluable considering ease of use and efficiency. Just sayin...

lordofhyphens commented 9 years ago

Well, we run on something of a do-ocrocy (with Sound having veto powers) here. If you want this feature and nobody else wants to work on it, you will probably have to do it yourself and submit a pull request. On Feb 9, 2015 2:34 PM, "Vicious-one" notifications@github.com wrote:

@dexy31337 https://github.com/dexy31337 Yes, this is more of a post-processing than slicing. Currently I have to resort to serious g-code hacking when slicing goes wrong again. In fact, it does go wrong nearly every time when bridging tricky gaps or in narrow areas.

Yes, one might say I should taylor the models for my slicing software to avoid its army of bugs, but seriously...

Anyway, I think this kind of tool, well-integrated into slicing software (using its profiles, etc), is going to be invaluable considering ease of use and efficiency. Just sayin...

— Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/2640#issuecomment-73584567.

santelelle commented 9 years ago

I support this feature, in some situations it would be very usefull

lordofhyphens commented 7 years ago

We have modifier meshes now that are movable and controllable, so set "slab" to your layer height and you have your "2d" to cover that part.