Feature Request: Adaptive infill

[zdar]

It would be nice to have adaptive infill.

E.g. to have denser fill pattern closer to the walls and more "free" space inside. Something similar what is used for mesh generation for FEM (finite element methods).

This should be relatively easy for rectangular infill where spacing could be controlled by distance to nearest wall.

The advantage of this would be better usage of material.

[danielpublic]

Inspirational and a good read, especially for architects if nothing else, see Milos Dimcic PhD Thesis, ITKE, Stuttgart University, 2011; Structural Optimization of Grid Shells based on Genetic Algorithms (.pdf).

[RenaeMacLeod]

+1

[lordofhyphens]

The infill logic is all in Perl, have at it. This feels pretty low-priority to do automatically. If you wanted to set up some modifier meshes you could change the infill% that way as well.

[lordofhyphens]

Well, infill logic is now in C++.

Modifier meshes should be easier to use now though.

[NateTG]

I'm somewhat interested in implementing something like that. I was thinking a bit more basic - using a simple fractal tetrahedron/octahedron tesselation pattern like the one hidden inside this stl cube: http://www.pedantic.org/~nate/diamond.stl

Conceptually it's pretty simple: Voids that are entirely on the inside are left whole. Voids that are entirely on the outside are discarded, and voids that intersect the boundary are recursively broken up into smaller pieces until some limit is reached.

[bubnikv]

Cura has an adaptive cubic infill.

Makerbot just published a minimum infill. https://www.makerbot.com/media-center/2017/03/20/introducing-makerbot-minfill

Slic3r has an "infill where needed", but it needs some love to make it really useful.

[NateTG]

Slic3r has an "infill where needed", but it needs some love to make it really useful.

Ok, what's missing?

[NateTG]

I've mused on the 'infill where needed' problem, and realized that it's really the same problem as identifying where support should be... now I'm reading up on voronoi tesselations to see how hard it is to use that for optimizing support material.

[bubnikv]

Supports are a bit different feature as they need to be easy to remove, while the internal supports are the opposite, they are best merged with the object to make it more rigid.

On Mar 25, 2017 3:19 AM, "NateTG" notifications@github.com wrote:

I've mused on the 'infill where needed' problem, and realized that it's really the same problem as identifying where support should be... now I'm reading up on voronoi tesselations to see how hard it is to use that for optimizing support material.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/707#issuecomment-289181740, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5IwJY5ltT3pilleq82x6jq6qbh_Qtks5rpHmUgaJpZM4AKa-k .

[NateTG]

Well, I think I have a good idea of how to do fractal cubic (parallelepiped) infill now. It's basically the same as voxelizing the mesh.

[NateTG]

Adding a little bit of detail about one conceptual way to generate adaptive cube meshes:

If you voxelize the model into an octree structure, then the octree cell walls will form an "adaptive cube" mesh: large empty volumes will make bigger voids. For printability reasons, we can't use axis-aligned cubes, but simple linear transforms allow an axis-aligned voxelization to produce an octree composed of FDM friendly parallelepipeds instead.

[bubnikv]

This is very much a description of the cura's adaptive cubic infill. I have not played with it yet though.

On Apr 5, 2017 6:54 PM, "NateTG" notifications@github.com wrote:

Adding a little bit of detail about one conceptual way to generate adaptive cube meshes:

If you voxelize the model into an octree structure, then the octree cell walls will form an "adaptive cube" mesh: large empty volumes will make bigger voids. For printability reasons, we can't use axis-aligned cubes, but simple linear transforms allow an axis-aligned voxelization to produce an octree composed of FDM friendly parallelepipeds instead.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/707#issuecomment-291925656, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5IxhqHeB2NOEwDdh88u1ONhlkzzULks5rs8dQgaJpZM4AKa-k .

[NateTG]

A kind of random question for you: Is there a design reason that the Slic3r cubic infill seems to make 'wiggly tubes' instead of just making closed parallelepipeds?

[bubnikv]

Is there a design reason that the Slic3r cubic infill seems to make 'wiggly tubes' instead of just making closed parallelepipeds?

Sorry, but I don't understand your question. What are wiggly tubes?

On Wed, Apr 5, 2017 at 7:17 PM, NateTG notifications@github.com wrote:

A kind of random question for you: Is there a design reason that the Slic3r cubic infill seems to make 'wiggly tubes' instead of just making closed parallelepipeds?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/707#issuecomment-291932434, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I-bOBhMJFGpjUSh9McOjA_MUELjtks5rs8yrgaJpZM4AKa-k .

[NateTG]

Slic3r/xs/src/libslic3r/Fill/FillRectilinear.cpp

Line 498 is:

const coord_t x_shift = abs(( (coord_t)(scale_(this->z) + range) % (coord_t)(range * 2)) - range);

To me, it seems like it should be something like:

const coord_t x_shift = (coord_t)(scale_(this->z) + range) % (coord_t)(range*3);

instead.

[bubnikv]

I cannot comment on that, my original code is different: https://github.com/prusa3d/Slic3r/blob/master/xs/src/libslic3r/Fill/FillRectilinear2.cpp

On Thu, Apr 6, 2017 at 12:56 PM, NateTG notifications@github.com wrote:

Slic3r/xs/src/libslic3r/Fill/FillRectilinear.cpp

Line 498 is:

const coord_t x_shift = abs(( (coordt)(scale(this->z) + range) % (coord_t)(range * 2)) - range);

To me, it seems like it should be something like:

const coord_t x_shift = (coordt)(scale(this->z) + range) % (coord_t)(range*3);

Instead.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/707#issuecomment-292138949, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I9iU2Wt8MmnLAv735tQ_wZW7IteCks5rtMT2gaJpZM4AKa-k .

[NateTG]

Well, your version seems right to me, so I guess that's my answer. Thanks.