3d infills: faster, stronger, simpler

[sylefeb]

Hi Everyone,

Got the idea tonight, and I wanted to share this with you. Short story, here are the new infills:

Yup, they are forming closed 3d cells. They are super-strong and ridiculously fast to print.

Long story: read here.

This will be in the next release :-)

[Loïc Fejoz]

Wonderfull!
It remind me this article: http://www.london-institute.org/people/farr/fractals.shtml
It is a little like if they use "round" tubes, you are using squared ones (and only two directions)...

For a FDM printer, your solution have indeed greater advantages!

One question: are infill patterns computed on the CPU or the GPU? How extendible IceSL is on that point?

Regards,

Loïc

[sylefeb]

Interesting link!

The infill patterns are currently computed on the CPU (essentially because tracing lines is easier + fast there). This is currently not exposed for customization -- would be interesting to do but it is not completely clear what would be a good interface to allow customization. In essence the pattern is a set of lines (curves) in each slice that is intersected with the regions to infill... maybe some callback asking for this set of lines given the bounding box of the slice? (then the intersection would be done automatically).

[Loïc Fejoz]

Thanks for the answer.

I was thinking on how to "branch", ie increase the number of regions near top (greater Z), so as to have smaller bridges, aka more supports for covers.

To start with, the signature of the function you have implemented might be a first trial for callback...
In the large, I wonder how it can be generalized to also handle 3D paths that are external or on surface of the shapes (you remember my other pattern to start printing, or for engraving/decorating/writing).

[sylefeb]

Quick update with the octree version :-) The subdivision degree can be controlled on a per cell basis according to any criteria (e.g. local thickness, stress, etc.)

[Loïc Fejoz]

Nice Job!

Really need something to stress test that.

[Maze Mietner]

Hi

that's a smart infill, really. I have just one question: Why did you implement it with 3 lines?

To me it seems much simpler to use four lines, angled 90°. Then, as you've written, the lines shift from one slice to the next to produce a 45 degree angle in 3D.
You'll end up with cubic boxes as well, all diagonal. You have one more line to print, but it's diagonal so the time penalty isn't big.

The octree is cool, but maybe complicated to set control criteria? I prefer having a small support grid at the shells (bottom, sides, top), providing strong support to the shell. And for the middle of a large part a big grid is perfect, there's no need for small support structures at all. The octree would be perfect for this, I think.

Maze

[sylefeb]

Hi Maze,

I think three lines -- or better, three sets of parallel planes in space -- is actually the minimum to get fully enclosed 'grid like' cells. If we use more sets of planes it will create other cellular patterns  but requires more time to print (might not be trivially true: there is a tradeoff between infill density and number of lines). If we use less (e.g. two) then it will create a structure having only 'extruded' cells, like the standard vertical infill but slanted at a different angle. It would be easier to explain with drawings :-) Do you see what I mean?

The octree right now is based on vertical distance, getting denser closer to tops/bottoms. Unfortunately the implementation is not very good and this needs more work; right now it is essentially a proof of concept. But I could not resist adding it to the release ;-)

Sylvain

[Maze Mietner]

Hi Sylvain

the reason I asked for four sets of parallel lines 90° lines is just because it might be the easier solution. And if you factor in the infill density this is faster to print than three lines. I didn't do the math because it's non-trival, but I'd put it this way: Only if you print the same amout of lines you'll end up with the same amount of infill. Let's say you need 100 lines per layer. You can print them all diagonally (four lines at 90°), or 66 lines digonally and 33 lines parallel to the X-axis (the current infill with 3 lines). As long as the print speed is not limited by the filament feed rate you're faster with four lines.

Actually it's also possible to go with two sets of parallel lines only: If you twist at least set of lines around the z-axis this will create cells. However twisting is not practical in most (all?) cases, as the cell size increase with the distance from the rotation axis, and the angle of rotation per layer is limited by the lenght of the lines as the layers must overlap for 3d printing. I can't see any practical use for this.

Maze

[sylefeb]

Hi Maze,

Actually I just understood what you are suggesting! Yes, you could have four sets of parallel planes that would result only in two different lines in the slices (eg. 45 and -45 degrees) in every slice, with a varying spacing between those lines. I like the idea, I'll give it a shot (disclaimer: the TODO list is a bit long :-) )
I went for three as it was the minimal requirements, but you are correct that four with only two different type of lines will likely print faster!

Twisting: interesting idea. I agree this is likely to lead to issues with necessary overlaps.

Sylvain

[Maze Mietner]

This code will visualize the infill with four sets of lines. It might crash the application if your gfx card isn't fast.
Actually I wanted to go with a height of .1 but this does crash the script for me.

line = translate(0,0,0.25)*box(20,0.5,0.5)
--line = translate(0,0,0.05)*box(20,0.5,0.1)
--emit(line)

wall = line
--for i = 0, 10, 0.1 do
for i = 0, 10, 0.4 do
    wall = union (
        wall,
        translate(0,i,i)*line
    )
end
--emit(wall)

walls = translate(0,-20,0)*wall
for i = 0, 30, 5 do
    walls = union (
        walls,
        translate(0,i-20,0)*wall
    )
end
--emit(walls)

merge = union {
    rotate(0,0,45)*walls,
    rotate(0,0,45+90)*walls,
    rotate(0,0,45+90+90)*walls,
    rotate(0,0,45+90+90+90)*walls
}


boundingbox = translate(0,0,5)* box(10,10,10)

fill = intersection(
    merge,
    boundingbox
)


emit(fill)

[Maze Mietner]

[sylefeb]

Great thanks ; this was my understanding as well. Good idea!

My only (small) concern is that on some layers two planes will meet at the same location: two lines will exactly overlap -- this should be avoided, but this is only a small complication.