Lightning Supports (not just Infill)

[jaggzh]

Is your feature request related to a problem?

Modern supports, like infill, are wasteful of time and materials.

Describe the solution you'd like

The new lightning infill, with just a few support-related options (spacing, spacing for the bottom-join, etc.) could allow nice breakable supports to use the same rib algorithms, but for external overhangs.

I presently model fins/ribs like this, by hand, which join at the bottom of the ribs, then are spaced from the walls until the actual overhanging areas, and they work incredibly great, and are fast

Notice the spacing I put in, which lets them be removed from the object much easier, and with less bonding-artifacts on the surface:

*Please note: That is not the inside of an object -- that's an exterior surface. It's part of a cover/hand-wrest for a mouse.

You can also see, at the bottom of this reprap wiki page I wrote years ago, I am creating them by hand for the same purpose (external supports): https://reprap.org/wiki/Example_DIY_Supports_2

(Being made by hand, the more-optimized tree-structures are much more difficult to make, but the tree structures are ideal, and wonderful).

For supports, instead of infill, I propose a few variables (options) for them to be practical::

Ribbed/fin supports ->

-> Bottom joint height (maximum height of fins to bond to the object wall)
-> Bottom joint distance (distance from wall, default .1mm, to allow fins to bond but be removable)
-> Rib non-bonding distance (distance from wall-to-rib for the non-joining parts)
-> Rib-top distance (Two options: Defaults to the Support Z and XY distance, or we can just use those, and not have two options here)
... not sure what else would be good here.

Describe alternatives you've considered

Making them by hand, forever, taking away my life while everyone else in the world wastes plastic and time and electricity.

Affected users and/or printers

All.

Additional information & file uploads

No response

[fvrmr]

Hi @jaggzh thank you for your feature request. I will bring this up for discussion. Keep you posted!

[Ghostkeeper]

Would be great to have a feature like this.

Implementation details follow: This could become somewhat complex with collision checking. Collision checking is a concrete result, but the underlying issue that makes it difficult is more subtle.

CuraEngine works by first creating zones to fill with certain structures (infill, skin, support, etc.) and then filling them with a pattern. These zones are used for a bunch of things. Collision checking is one of them (it may need to avoid support), but also to determine the order in which things are printed, which extruders get used on a layer, and in the case of support where to produce the Support Interface (which may have a different infill pattern, extruder, etc.)

The difficulty with this implementation is where it's going to say that the support is. Essentially you'd want to say that the support goes... everywhere, and let the Lightning pattern determine where to print the actual lines. But then the support interface is going to be very weird. And you'd get unnecessary priming when there is no actual support on a layer. But limiting the area where the support is generated (e.g. dropping it down vertically from the overhang) would also make the lightning lines hang in mid-air as they try to reach the sides of the support volume where there is no model to attach to.

We also need to think about how this works with X/Y distance. Lightning infill is made to attach to the side, while the X/Y distance exists to prevent support from attaching to the side. Maybe it should only attach to the side in places where the overhang is steep enough. And since for the most part it doesn't get any stability from the walls then, maybe you'd need to turn the lines into little loops to give them some width. But yeah, then you end up basically with tree support.

[jaggzh]

I think some changes to the algorithm are definitely needed for them to work as removable supports. (What was "priming" again?) With the zones, would lightning infill have access to data available to know where walls are (or are not)? Can the support generation specify in which direction the path is printed?

In the paper, they mention the bottom-most path of a support is closest to the wall, to ensure bonding. In my work I've always left many layers as bonding, above that the fin can generally be spaced to not touch until it reaches the area needing support. I've also found that the width of a fin (not path width, but.. xy length) affects how much leverage you have to remove it. Otherwise you end up with a fin breaking off, leaving its triangular tip behind.

One thing I've not worked on is having many "lightning branches" forming the many directions at the top support area. Limiting the overhang angle, of the fins themselves, at the top, might also be useful in this case, forcing a bit more vertical fins, with possibly a bit less savings. (Since another fin might need to be printed adjacent, whereas otherwise it would just be multiple small branches).

Regarding "steepness": If a path is printed in the direction of wall-side -> out, there's additional leniency in the angle at which a fin can be printed, since they'll slightly bridge (out into the air) a bit further each layer up, and that outer point doesn't need to be very clean. A user setting for the max overhang angle would be useful.

Then there's the issue of handling places where you just can't get to wall; the generator needs to handle this area as well (like reaching to the ground). Actually I don't know how the ribbed-infill paper handled this. Can lightning be done at the interface, then below that switch to another user-selected support type? Or we could just handle how lightning-to-bed interface is handled.

Alright, done rambling for now. I hope something in here is of value.

[fvrmr]

We have discussed this and made a ticket for our backlog. Devs see CURA-8877