Sinusoidal truss infill

[laukejas]

Description
Several closed-source, proprietary slicers have the option to generate a sinusoidal truss infill, typically used for parts printed vertically that have more or less consistent thickness. This infill is geometry-aware, meaning that it always tries to keep the same angle to the perimeter walls in the X/Y direction. In the Z direction, this infill shifts in a sinusoidal wave. Here are a few examples for reference:

Benefits

This infill is typically used for printing large and lightweight structures very quickly. When printed with a single perimeter, it allows printing with a constant toolhead and extruder speed and zero retractions, similar to Spiral Vase mode, which can be highly beneficial for lots of filament types, reduces the risk of clogs, failures or print defects, and results in a very weight-efficient structure.

Slicer integration

This infill could be included with the rest of the infill types, with some setting specific to it:

1. Truss angle - the target angle between the neighboring truss segment, default at 90°. Alternatively, this could be indirectly controlled with fill_density, as higher density would result in higher angles.
2. Sine wave amplitude and frequency - determines the shape of the truss shift in the Z direction.
3. Truss and sine wave offset - to allow the user to specify where the truss starts at the first layer, to allow lining up truss infill for parts that will be glued together.

Alternatively, if the requirements of this infill type are too inconsistent with other infill types, it could be treated as an Experimental Mode, or something similar to Spiral Vase (setting that adjusts multiple other settings to make it work).

Software implementation

The following is just a suggestion of how I'd do it. There might be a better way.

1. For each layer, slicer should run a thickness analysis in XY direction, and determine two opposing perimeters that are closer than the other two. In the following picture - the blue lines:

2. Pick an arbitrary point on one of the perimeters near the end, and determine a normal direction from that point (yellow):

3. Extend a ray from that point at an angle that is half the user-specified truss angle, until it hits the opposing perimeter (green):

4. Repeat steps 2 and 3 to bounce the rays back and forth between the perimeters, until the last ray no longer hits the lines of the main perimeter pair. At each reflection point, an average between the user-specified truss angle and the perimeter normal direction will have to be calculated, to avoid the truss from developing a sawtooth pattern.

5. Generate infill lines on the rays.

6. Move to the next layer, offsetting the ray deflection points in the X/Y direction to account for the change in part shape and the sine wave shape.

Final remarks

It is likely that this infill won't work for all parts universally, for example - parts that don't have obvious "thickness" to them, or it is extremely irregular. However, it should still work reasonably well for parts that have a reasonably consistent thickness, even if the opposing perimeters are not strictly offset from one another.

[supermerill]

imo, it's hard to create somthing that works.

I don't think your proposition works for loops, like in your second picture.

My guess:

• create the medial axis from voronoi algorithm (already integrated for thin walls and gapfill)
• extract only the main trunk (centerline)
• start from a centerline and generate the path from it, a bit like you said.

but here lie the problem: how do you make sure that the next layer is on top of the previous one? the shape can vary widely because two island merge or split...

[laukejas]

@supermerill Thank you for your comment. I inquired with the original author behind the algorithm used in one of the closed-source slicers that I mentioned, asking him to describe how it works. I don't understand it well enough to explain in my own words, so I'll just quote him. Please let me know if this helps. If not, I can try to get more information from him.

Q: Perhaps you would be willing to share a rough description of how the sine wave warren truss infill generator logic works?

A: Regarding the slicer and infill, the main thing is to treat sandwich perimeters as parametric surfaces where you can evaluate [[0 -> 1] [0 -> 1]] relative 2d coordinates.
Calling patch.getPoint([0,0]) will get you lower left point (absolute x,y,z coords) of the patch, while patch.getPoint([1,1]) will get you upper right corner of the patch.
Once you have this, it's actually easy to implement all kind of interesting infill/connection structures which naturally follow the contours of the patches (there could be even more then 2 patches, some infill types are applicable to any number of control surfaces).

I design all my structures as tensor product patches, where "longitudinal" parametric control curves (could be bezier, nurbs, or polyline-interpolation...) grow in Z direction and evaluation of all "longitudinal" curves at particular parameter (in the [0 -> 1] range) provides inputs for cross-sectional curve (could be again anything satisfying parametric curve interface).
Therefore it's very easy to iterate from 0 to 1 parameter in primary "longitudinal" control curves in order to obtain layer-data and again 0 to 1 in cross-sectional curve(s) to obtain perimeter polyline(s) for that particular layer.

Of course that's super simplified and there was huge amount of issues to solve, for example the need to normalize parametric curves in order to obtain uniform evaluation steps, etc.

[supermerill]

understood.
This way, it's easy for a loop.
For the half-loop, I think the voronoi can help to identify the edges to remove.

Still, I'm not sure how it ensure that the next layer is aligned with the previous one.
In the slicer, we use a grid to ensure a fixed reference. If we use the perimeter, there is no more a fixed reference.

the need to normalize parametric curves in order to obtain uniform evaluation steps, etc.

I guess this is the aswer, morphing the perimeter parametric coordinates to kind of align to a fixed grid.

[laukejas]

I was considering the same issue, and like I suggested in the original description, perhaps it would be necessary to take an average between the previous layer ray reflection point coordinates and the new coordinates suggested by the perimeter shape on the new layer. So basically use the previous layer as a fixed reference, with the shape of the perimeter of the new layer dictating the direction to which the infill must gradually deviate towards to try and return to the "ideal" reflection positions. How much the infill can be "pulled" towards the new ideal position on each layer would be limited by the extrusion line overlap with the previous layer (50% probably). If the change in perimeter shape is gradual enough, the infill should have no issue catching up with the ideal ray reflection positions. If the change is very sudden at any layer change, perhaps the slicer could give up on trying to align the new layer infill, and start over from ideal reflection positions again, although this would result in bridging. Or just throw an error.

I might be oversimplifying the idea. If you are interested in developing this feature, I could try and get the personal contact of the original author of this infill. Perhaps he would be willing to share more information.

[supermerill]

I don't have enough time for that right now. And to create it from scratch, it may takes a huge amount of time.
If someone is interested, Infill are pretty simple to add into the software, if there is no dependency for layer to layer. The layer sync can be added afterwards, in a second version.

On my side, for infill, I still have the solid one with "plugs" to do.

There is no patent on them?

[laukejas]

I had a call today with the developer of SpaceDelta, @janherich. He explained how his software works. It is something between a regular slicer and Full Control, the design is done inside that software rather than importing STLs (think OpenSCAD), so opposing perimeters are known by default. However, we discussed that if this can be solved for regular slicers and volumetric STLs, there shouldn't be any significant challenges in implementing this infill type.

There is no patent on this infill or the "slicer" itself, and @janherich is very open to the idea to providing whatever information is required (including detailed description of the algorithm and some pseudo code) to make this algorithm available in SuperSlicer or other FOSS slicers. He also has some other amazing features in his software that SuperSlicer could benefit from. If you are interested in taking a look at it, you can contact him at jan.herich@gmail.com.