[3dprint] 3d infilling: faster, stronger, simpler

Sparsity: 80% empty (compared to volume of full cube)
Strenght: I applied 90 kg on each face and it remained perfectly rigid (cube is 40x40 mm).

We are working hard on the next release of IceSL.One thing I really wanted to improve are the infill patterns. The 'sine wave' patterns we are currently using look fancy, but they have a number of severe drawbacks ; one of them is resonance on less robust printers, and another is a slow print time.

I have been thinking about this for some time now. What I wanted was: 1) something rigid (obviously!) 2) something that prints quickly 3) something that prints without putting stress on the printer and 4) something easy and fast to compute.

These requirements are quite high.

Regarding rigidity, I dislike that most infill patterns are simple extrusions along z. What is really called for is a pattern forming 3D cells inside the volume for maximum rigidity (side note: I just found about slic3r 3d honeycomb while writing this post, these look great ; there may be more prior work as I haven't checked in details yet - please comment if you know some).

Printing fast essentially means going along diagonals in straight lines - something IceSL doesn't do well currently. Avoiding stress on the printer also means moving as much as possible along straight lines (no vibrations, constant speed, constant pressure in nozzle). Unfortunately anything fancy (such as 3d honeycomb) quickly leads to some turns and broken lines. Finding out something simple and fast to compute just makes it harder. 

The idea. More than just a specific infill, this is a general way to build simple and fast to print 3D infills. Let me warn you this is, indeed, very simple (once understood) -- but I am unaware of anything like that in the slicers I know.

The initial intuition was to consider the walls of a regular axis aligned 3D grid. Now, we do not want that, because the horizontal planes would create flat surfaces. So, one possibility is to rotate the entire grid so that the diagonal of the cubic cells align with the z (up) direction. Take one slice through this rotated grid. The intersection is a pattern made of straight lines -- so that seems promising. At first sight, this also seems tricky to compute: the lines have to follow a very specific pattern and meet exactly at the right locations to form the 3D cells.

Well, it turns out this is in fact trivial. What is a regular grid? It is defined as the intersection of three sets of equally spaced parallel planes; the three sets having non-coplanar normals. In 2D, for instance, draw two sets of parallel lines: this forms a regular subdivision. You can even define coordinates in this grid by numbering the spaces between the sets of lines (planes in 3D).

There is no need to worry about the exact position of the planes: when you draw two sets of parallel lines on paper they always form a proper grid (as long as the two sets are not parallel). What this means is that we can easily produce an infill generating closed 3D cells simply by printing three independent sets of parallel planes!

This gets even better. In a slice each set of planes becomes a set of parallel 2D lines (see top of the print in image). Whenever we go up by one slice the position of the lines have to shift: each line is the intersection of a slice and a slanted plane in 3D. This can clearly be seen on the sides of the print, in the image above. What this means is that you can produce an infill forming 3D cells simply by tracing three independent sets of parallel lines in each slice! It suffices to make sure the lines shift correctly from one slice to the next, which is absolutely trivial to do.

For the initial tests I chose 2D lines which are angled at 0, 45 and 135 degrees so that 2 lines over 3 print diagonally (speed). The lines shift from one slice to the next to produce a 45 degree angle in 3D. All of this is easily controllable, the angle and spacing may vary for each direction and even between planes of a same set. More than three sets can be used to form more complex subdivisions.

The first prototype was coded in less than 10 minutes (!). Count on it for the next release of IceSL!

(Edit: if you include similar infills in your slicer, please cite this blog post, in the spirit of the CC BY license. Enjoy!)