Feature request: Modifier meshes should include "supports" options

[bitsandbooks]

I frequently print things that only require supports in one small section, but at the moment, supports in Slic3r are all-or-nothing (i.e., you're either adding supports throughout, or you're adding none). Some slicing software (e.g., PreForm, used with the Form 1 printer) allows you to select and delete supports where you don't want them, but adding that to Slic3r is probably a long-term goal, due to the work involved.

Slic3r does have one feature that could accomplish the same thing: modifier meshes. Right now, modifier meshes can change a few options: extruders, extrusion width, infill, layers/perimeters and speed. However, if options for supports were added to modifier meshes, I could tell Slic3r that I only need supports in this one region of the part, which would save time and material.

(Credit for the Superman Bust model used in the image goes to Geoffro.)

[a4jp-com]

Very nice idea.

[alranel]

Looks like Superman needed an orthopedic collar. New feature! :P

Kidding, I'm going to implement this not too far in the future.

[a4jp-com]

Thank you very much ^^

[oschonrock]

I had the same idea/request, and found this. Great that its on roadmap.

Another "easy" toggle would be: "only generate from build plate" not "on the part". This avoids having such a modifier stl, but would be an even easier "generate less support" option. Overhangs which are "over the part" would remain unsupported if this option is turned on.

The modifier stl would be for more advanced, selective placement of support.

Separate feature?

[bitsandbooks]

That's the opposite of what my request is about -- I want to be able to specify which regions of the build need supports, as in the example image above -- but that's a worthy idea. Sounds like a separate issue to me, but I'd support that.

[lordofhyphens]

@oschonrock there's a PR open for "build for supports over plate only".

@bitsandbooks I've started to look at this from a removal of supports (allowing selective removal of supports with a modifier mesh).
Currently with the way things are it looks like I'd need to slice the modifier mesh separately and use that to clip/remove from the support generated. I'll have to look at the overhang and contact surface stuff more closely to make it work.

[Patola]

@lordofhyphens slicing the modifier mesh separately and use that to clip or remove from the support generated wouldn't screw up the other upcoming feature of manual support placement? Or at least make it much more difficult to implement. Isn't it better to reincorporate supports as some sort of "special" mesh to be added to the build plate, and when using modifier meshes, just use the boolean on/off of that region to include or not this special mesh? I reckon it would require some refactoring and changing the slicing sequence, but I consider it a welcome change that would make slic3r more malleable and understandable.

[lordofhyphens]

@Patola What I meant is that the modifier mesh needs to be at least broken down into individual layers in order to get intersected with the model, and the slicing method (so far as I know at this time) discards that extra information after it's been sliced.

The model is sliced and then support is generated. Modifier meshes affecting support means that we need a good way of referencing intersection of the final slicing and the object.

There's a open issue over at the Prusa3d fork prusa3d/PrusaSlicer#22

[bubnikv]

It does not make sense to trim the supports. What one needs to trim is the supported surface. Ideally one would let Slic3r calculate and display the overhangs to be supported and the user would add or remove overhangs manually to that.

Technically it is not that easy because:

1. The mesh triangles may be large. One may either split the triangles or keep some kind of map for triangles, which are not covered completely. The map may be polygonal or a bitmap through some kind of texture mapping, like in the gaming industry.

2. The sliced model is different from the triangular model. Some detail is added due to the slicing, some is reduced. So the overhang information extracted from the triangular model does not reflect the properties of the sliced model exactly. Still it is better than nothing.

Simplify3d has a nice user interface and the generated supports are probably the state of the art, but they are not perfect either. Sometimes Simplify3d creates tiny towers of supports above the model supporting nothing, just protruding through the model from below. But Simplify3d generates these supports very quickly :-)

[RafaelEstevamReis]

(this first part is only a "I need that too because of this specific case")
I am currently with a specific region support problem which nor slic3r or cura can fix.
Is a model with tiny "floating" regions and a big floating region.

The tiny ones can be build without support as you barely not see the fell plastic but enables support will be aesthetically bad and can not be removed (too small to reach but very visible).

This regions "let plastic fall" would be good enough
The hole at the orange circle is 4mm wide

Top view of support layer (same orange circle)

But the big one need to be supported

A better view after supports were removed

I printed this ones with cura. (their "lines" support are easy to break in hard to reach areas)

[RafaelEstevamReis]

(Second part)
A possible solution (which will slow down slicing process):
If I understand correctly, support are generated after slicing model.
How feasible is: (use this method only if has modifier mesh)

1. Start slicing file normally
2. Before support step create a temporary mesh which is a boolean intersection of Model and support Modifier mesh
3. Calculate supports within this new mesh - this is the "second" slicing process
4. Apply this to first sliced mesh
   I think it will change less logic on current process.

I am not sure if this is what @Patola means

[bubnikv]

The only thing to avoid generating a support where you do not want it is to trim the overhang surfaces by the modifier meshes or by another means. This is very similar to the "support over bed only" feature I have implemented.

…

On Thu, Dec 8, 2016 at 1:40 PM, RafaelEstevamReis ***@***.***> wrote: (Second part) A possible solution (which will slow down slicing process): If I understand correctly, support are generated after slicing model. How feasible is: (use this method only if has modifier mesh) 1. Start slicing file normally 2. Before support step create a temporary mesh which is a boolean intersection of Model and support Modifier mesh 3. Calculate supports within this new mesh - this is the "second" slicing process 4. Apply this to first sliced mesh I think it will change less logic on current process. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2570 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFj5Iw4uA7eWok13LTbFQb4oSAaMusOqks5rF_q1gaJpZM4DU1Hi> .

[lordofhyphens]

@bubnikv yeah I did a crappy job of explaining things, addibg/removing the areas to be considered for supports is the correct approach with modifier meshes.

…

On Dec 8, 2016 6:47 AM, "bubnikv" ***@***.***> wrote: The only thing to avoid generating a support where you do not want it is to trim the overhang surfaces by the modifier meshes or by another means. This is very similar to the "support over bed only" feature I have implemented. On Thu, Dec 8, 2016 at 1:40 PM, RafaelEstevamReis < ***@***.***> wrote: > (Second part) > A possible solution (which will slow down slicing process): > If I understand correctly, support are generated after slicing model. > How feasible is: (use this method only if has modifier mesh) > > 1. Start slicing file normally > 2. Before support step create a temporary mesh which is a boolean > intersection of Model and support Modifier mesh > 3. Calculate supports within this new mesh - this is the "second" > slicing process > 4. Apply this to first sliced mesh > I think it will change less logic on current process. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#2570 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ AFj5Iw4uA7eWok13LTbFQb4oSAaMusOqks5rF_q1gaJpZM4DU1Hi> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2570 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB8CggpH0qujZSwE5TVKnA0VcoBpTM-ks5rF_x3gaJpZM4DU1Hi> .

[Heinz-Loepmeier]

Is selective support via modifier meshes possible yet?

[steelydev]

I would like to add the suggestion:

Allow any modifier mesh to either 'generate support material' or 'do not generate support material'.

[alexwhittemore]

Support for modifier mesh support modifications would basically bring Slic3r supports from borderline useless to highly functional. I'm surprised this issue hasn't gotten any love since basically 2014.

[lordofhyphens]

It involves a lot of restructuring and careful consideration of how to make the information available. Right now there isn't a useful way to transmit the information about modifier meshes to the code that does the support. So when nobody else is stepping up to work on it and there are other, easier, to work on... the other needs get worked on. On Dec 13, 2017 10:59 PM, "Alex Whittemore" <notifications@github.com> wrote: Support for modifier mesh support modifications would basically bring Slic3r supports from borderline useless to highly functional. I'm surprised this issue hasn't gotten any love since basically 2014. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2570 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB8Ckv5e_l6CBzT03HyKnJa2s-IEZtJks5tAKs0gaJpZM4DU1Hi> .

[stephanpark]

Has this been dropped? I wrote a clumsy script that manually builds break away supports in my CAD app based on modifier volumes but having such a thing in Slic3r would be a far more desireable workflow. The button is in Slic3r but does nothing. Maybe get rid of the button so others don't reach this dead end as well.

[lordofhyphens]

@stephanpark it has not been dropped as a desired feature, but nobody has stepped up to work on it. Just a classic problem of not enough resources to fix everything now.

AFAIK there is not a nonfunctional button in Slic3r for this.

[Matts-Hub]

@lordofhyphens There is an option in the drop down for "support material" but clicking it does nothing

[lordofhyphens]

That isn't an option on its own, it is a menu with no submenus. You can turn support material off per-part.

…

On Sat, Jun 30, 2018, 3:15 AM Quintox303 ***@***.***> wrote: @lordofhyphens <https://github.com/lordofhyphens> There is an option in the drop down for "support material" but clicking it does nothing [image: screen shot 2018-06-30 at 6 14 08 pm] <https://user-images.githubusercontent.com/26502465/42123221-8b8e7b18-7c91-11e8-9b9c-e745f788b757.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2570 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB8Codo4utiuwX86K2GCVTXXzKXOPrZks5uBzO6gaJpZM4DU1Hi> .

[stephanpark]

I see. The menu is only available on parent node called "Object". Support settings can be altered for object (listed in the object list in the right palette). Sub-objects whether they be added via manual loading or by splitting obey the master object's Support settings only unlike some of the other settings which can be set per sub-object. So, a multi-parent Object print can have different support sub-menu settings. For example, the print can be set to have supports, then one of the objects can be drilled down to Settings>Object>Support>Generate support material and UNCHECKED resulting in all but your specified object (sub-objects follow parent in this regard). You can inversely, NOT have support for the print session and only turn on supports objects via same method. I won't even get into Object clipping and supports. Kind of clumsy UI IMHO.