supermerill / SuperSlicer

G-code generator for 3D printers (Prusa, Voron, Creality, etc.)
4.11k stars 519 forks source link

[Feature Request] Maximum Unsupported Bridge Length #522

Open TD5023 opened 4 years ago

TD5023 commented 4 years ago

Version

2.2.53

Operating system type + version

Any

3D printer brand / version + firmware version (if known)

Any

Is this a new feature request? Yes If possible/reasonable, it would be nice to have a user-defined maximum bridge length for which supports are not needed. Then, instead of supporting across the entire length of the bridge (which is the result if "don't support bridges" is unchecked), it will only create singular support structures spaced in intervals so that the unsupported length never exceeds the user value. I currently design in these structures, but they affect the rest of the print slightly (mostly due to being included in adaptive layers) and having them calculated as support would be much more convenient.

As an example, I print off light switch covers, but the face designs require that side to be printed up. This means that on the bottom side, there could be up to 150 mm of bridge material. That is too long to stand any chance of coming out clean, so I currently design in structures that limit the unsupported bridge to ~30 mm. I would love for that to be slicer generated instead of modeled in.

I'm not on my home computer currently, but if there is any confusion, I would be happy to upload any photos later if it will help. Also, if this is completely unreasonable to program in, please go ahead and close.

supermerill commented 4 years ago

You can add a support enforcer where it's needed. right-click-> support enforcer->cube, move it and resize it (the only overlap taken in to account is where the interface is, between the support and the part)

TD5023 commented 4 years ago

@supermerill I tried doing that before (in PS, so I'm not sure if it would be treated differently there), but it didn't do anything. I could have been messing it up (this is probably the case), but I figured it was because the item being a bridge took precedence, so it still didn't calculate anything for it. I will try again later.

supermerill commented 4 years ago

ah, maybe. That's somehting else to improve. Did you try with "not on bridge" unchecked?

TD5023 commented 4 years ago

Not sure. I don't recall doing anything with it, so I'm sure I used whatever was the default. I will look for it when I get back to my home computer.

yschroeder commented 4 years ago

I just tested this: Support enforcers work, just make sure to uncheck dont_support_bridges.

However, there is a problem with the dont_support_bridges setting: When also having overhangs checked it prints the perimeters with bridge speed but creates support for the perimeters.

support_bug

I think in case the perimeters are printed with bridge speed, there should be no support support generated here.

TD5023 commented 4 years ago

Ok, doing it that way made it generate properly. The issue that now arises from that is there is no way to make it recognize enforcers while still naturally generating supports in the areas that otherwise would get them (in the example above, the switch and screw hole perimeters). I guess the larger point here is that I'd rather not rely on enforcer control of support placement in these situations; I'd much rather have some additional parametrically calculated supports to help the bridge sagging so it can function more smoothly with its surroundings.

yschroeder commented 4 years ago

You can use enforcers together with regular support. Also you can load custom STL files as support enforcer, so you might want to look into that and generate the correct support positions directly in CAD.

TD5023 commented 4 years ago

The problem with enforcers and regular support here is that I can't enable regular because it will fully support the entire bridged area, which is what I'm trying to avoid. This would end up requiring modeling of all support for anything with longer bridges, which is fine for simpler objects, but tedious over complex and multiple objects where what I'm requesting would greatly simplify things (on my end, anyway). I don't know how much effort the programming would be, so if it's a lot, I can work with it as is.

yschroeder commented 4 years ago

You can also add support blockers. Put a large one under the bridge and then an enforcer where you need it.

TD5023 commented 4 years ago

That will work, but it still leaves the same issue for complex objects where hitting (or avoiding, in the case of blockers) every support point can become quite tedious and very easy to miss one when doing it manually. Having the slicer able to auto-generate everything would be safer and more efficient, both in modeling time and in material usage/print time since everything would just be settings-based and there wouldn't be a possibility of accounting for oversized enforcers.

(As a side note, I certainly hope I'm not coming off as whiny or complaining here. I do appreciate the pointers and enjoy the discussion, but I just think that automating this would be quite helpful for many people. There are years-old threads over in the PS hub asking for it, and I've personally wanted it for a long time.)