How to create a special infill for a given shape?

[Timothee-Leblond]

What are you trying to do?
I'm trying to use the normal version of FullControl to design specific shapes and their infills.

What have you done so far?

I know how to design infills, but I don't know how to create an infill in which the outline isn't square.

What do you still need to do?
I need explanation on how to implement the infill created in a shape (any kind).

What is your question
How to create a special infill for a given shape? (exemple of a circle or other)

[ES-Alexander]

Incidentally I've been thinking about this kind of thing sporadically through the past week, and it could be useful to get some input about what kind of use-cases you're considering.

Some Context

Note that I'm an occasional contributor to FullControl, but not a maintainer of it, so my thoughts and ideas are just that. They may get worked on in my spare time, but my opinions are not absolute decisions for the project's direction, and my ideas are not guaranteed to be part of the project roadmap.

I think it's important that FullControl doesn't try to turn itself into a standard slicer, but some normal slicer functionalities will also make sense within FullControl, so I think it makes sense to try to implement such slicer functionalities as subsets of more general ideas within FullControl. As a couple of examples:

1. a 2D shape fill doesn't have to end up horizontal or flat (e.g. it could be tilted, or projected onto some rounded shape / underlying geometry), and could end up with variable extrusion heights/thicknesses
2. source regions don't have to be polygonal (e.g. they could be defined mathematically/programmatically, and one region definition may include multiple separate shapes)
   • the main requirement is knowing whether an arbitrary point is inside or outside the boundary of the region
   • it is convenient (where possible) to
     1. know how far a point is from the boundary (ideally in a specified direction)
     2. know where a line segment intersects the boundary
     3. be able to generate a series of line segments along the boundary
3. Ideas for other unique situations we may wish to handle are welcome

Cut Fills

Your hand drawn shape fills thankfully fit within the simplest family, which is a fill that's cut by the boundary, rather than being generated from the boundary (e.g. concentric or line infills in common slicers). Achieving that in a performant way may be tricky (and is likely something I'll end up putting some time into at some point, since it's my kind of fun), but conceptually it's possible to cut any fill line/pattern by a shape by a process like the following:

1. generate the desired fill in a bounding shape you know how to
   • e.g. in a rectangle that fits outside your shape of interest
2. subsample each of the fill lines into segments that are smaller than the smallest feature
   • e.g. if you don't care about corners or holes/gaps smaller than 5mm then you could choose that as your smallest feature size
3. for each segment along the path, check whether
   1. one of its points is outside the boundary
      • in which case move the outside point to the segment's intersection with the boundary, and add it to the path
      • if the boundary is for a single convex shape then every second such segment is joined to the previous segment
   2. both of its points are inside the boundary, and the infill pattern is not straight lines
      • in which case keep those points in the path and move on
   3. otherwise (e.g. both of its points are inside the boundary, or both are inside but with straight infill lines)
      • remove the points from the path
4. if the boundary is non-convex or non-singular then it's necessary to join up points from the boundaries
   • one approach for this is searching for the nearest available boundary point and then ensuring that a line between the two points doesn't go outside the boundary
5. it may be desirable to split the connecting lines on the boundaries into multiple segments, which then get pushed out along the boundary, which can either be done while performing the cuts or as a step at the end

Generative Fills/Reshaping

Generative fills, and cases where a collection of objects have been reshaped to fit inside some volume can be much more complicated, and there isn't a generic way to create them because it depends on the generator function.

For the conformal lattice shown in your first image, I could imagine that being created from a set of seed points that get evenly spaced throughout the volume and sliced into a set number of layers, but it could also be created by slicing a rectangular volume and then reshaping the paths to fit into the desired U shape.

[Timothee-Leblond]

Hi Alexander,

Thank you for your help. Please note that I'm currently learning FullControl Python but as I'm not familiar with, It is taking time. This is why I'm looking for an alternative way to achieve this using the Excel version first.

As I'm printing complex biomaterials, I will not necessarily use this circular shape/infill. I took this exemple to illustrate my words and understand how I could achieve such a thing.

Even though your explanation is cristal clear, would you have some input on how to achieve that in FullControl? What feature should I use for exemple?

Thank you so much,

Tim

[ES-Alexander]

Even though your explanation is cristal clear, would you have some input on how to achieve that in FullControl? What feature should I use for exemple?

In the same way that the Excel version of FullControl makes use of various underlying Excel and VBA functionalities, the Python version makes use of the Python programming language. As far as I'm aware there's no existing feature in FullControl for infill generation in a shape yet, so doing so requires performing the relevant steps with general Python code.

I've just uploaded a gist of my current progress, but be aware it's very much a work-in-progress at this stage, and for now it's not nicely integrated with FullControl's path or visualisation tools (I'm just using the matplotlib Python library for some basic plotting so I can see what I'm creating). I'm also writing it with performance in mind, so it's making significant use of the numpy library for calculations, which can make it a little less intuitive to understand than pure Python might be.

See the comment at the bottom for a display of what that code can already do, and feel free to read through the existing code (even just looking at the class and function names, and the docstrings/comments where they exist) to get a sense of the direction(s) I'm trying to take it and what's implemented so far. As a brief summary,

• It's up to ~step 3 from the "cut fills" process I outlined above
  • I expect step 4 may be tricky to implement robustly, but it may not be necessary for the initial implementation
  • Step 5's complexity will depend on how well the boundary is defined in local regions for a given shape
    • e.g. circles and rectangles and the like will be straightforward, but
    • an area defined as a threshold of some wavy/spiky mathematical function could be tricky
• Only simple shapes are supported right now (circles and axis-aligned rectangles, and ellipses (mostly))
  • The idea is that people will be able to define their own shapes / functions as desired, but I'm trying to create a decent set of initial ones to help people who aren't already familiar with Python
  • 2D only for now, hopefully 3D later
• I've started work on boolean shape combinations, but haven't yet got the intercept calculations working consistently
• I'm hoping to add a generic "Polygon" shape (because it would be very convenient), but I haven't yet determined how hard the intercept calculations will be to implement efficiently
  • I'd prefer not to add an external dependency for that if possible, but the shapely library is at least an option if necessary

As it progresses I'll try to write up some information about what I've included and how to make use of it effectively, but this is a hobby project for me so I can't make guarantees on how much time I can put into it.

As I mentioned in my original comment, feel free to suggest features that would be useful/critical for your application, so I can keep them in mind and try to work them in :-)

[fullcontrol-xyz]

I love all these ideas. Someone else has also developed a shape-filling/reshaping strategies and I'll need to point them here. The CONVEX function in lab already effectively allow reshaping of lines, concentric, and perhaps other infill strategies if you use it with a bit of thought. I updated the lab notebook for CONVEX last night with an extra example of that.
Reshaping is undoubtedly my favourite approach here. It results in a beautiful path with no dodgy corners and accommodates travel-free printing. It's something FullControl can do relatively easily but it always going to be a problem for slicing and results. It's how FEA works for meshing in ideal circumstances and it just a really great approach. But it's certainly more complicated that cut-filling and both approaches have great value. Generative is also very appealing because it can be extremely easy for the designer to use without needing to make decisions about orientation, etc. So, I guess I want them all!

I think the first implementation should be simple for the designer to get to grips with and then more complex ones can be done after. The nice thing in terms of FullControl source code is that these will likely be functions and therefore each to just stick into fullcontrol lab without many of the challenges that existed for other major additions to fullcontrol capabilities by ES-Alexander and me. And they can be thrown into lab even if they're not easy to use... more-advanced designers can be told to use at their own risk and it won't affect the 'normal' user until we push it in their face.

In terms of Excel and python, I don't think this is worth pursuing in Excel. The effort required and the very likely limitations/compromises that will be required were exactly why the python version was created. If you really want to use Excel, you could do some good stuff in python and then export the points in a csv format that can be easily copy and pasted into Excel. But in that case, I would strongly push you towards the python version if you need automatically generated infill. The Excel version of FullControl is more appropriate for designed-infill where you know exactly where it needs to go because the outline is either simple or mathematically defined. But even then, I would personally put the effort in to switching to python since your really at the limits of what the Excel version was ever intended to do.

[ES-Alexander]

Someone else has also developed a shape-filling/reshaping strategies and I'll need to point them here.

I take it you're referring to @scamiv from #59?

---

FYI I've updated my gist to include Polygon and Ellipse implementations.

Current capabilities:

[fullcontrol-xyz]

I take it you're referring to @scamiv from #59?

Actually, it was someone emailing using a turtle graphics (at least partially).

FYI I've updated my gist to include Polygon and Ellipse implementations.

This is amazing stuff. I can see how well it fits into FullControl but also see it as quite a fundamentally different design approach to the current focus on directly designing lines. This really is designing areas. And obviously it's a tiny jump to design volumes, which naturally 'slice' into areas. I need to think more. But one thought is that this kind of design method could be presented as a clearly separate way to use FullControl. The user knowingly chooses to design lines are areas. And of course areas naturally translated into lines (points) once you do the infill stuff. One thing I wonder is how quickly will complexity escalate? E.g. If we solve the concavity challenges for the square wave infill strategy, does that instantly translate to other filling patterns? Or other filling patterns made of straight lines? Etc. I can see a risk of that not being true and then, does this become impractically complicated? I mean, slicers only offer a few infill patterns. If your method was easy to translate to other patterns, it would be a really quick and easy win for us to say "we can take any pattern your design and use it as infill for any outline you design"

I hope this isn't sounding negative! It's really amazing stuff. Big jumps in capability or workflows are always going to bring a healthy dose of excited apprehension!

I'll be thinking about this! It may compliment ongoing FullControl developments towards using AI natural language capabilities to design models... since primitive geometry is easy for a human to describe and LLM to put into code.

[ES-Alexander]

One thing I wonder is how quickly will complexity escalate? E.g. If we solve the concavity challenges for the square wave infill strategy, does that instantly translate to other filling patterns?

There's a pretty extensive comment of progression ideas under the gist - concavity (and holes) seem quite readily solvable by just treating the "outside" parts as travel moves (which I think is unavoidable for a general solution that makes use of area-based "cutting"). I've been very intentional to avoid anything that's reliant on specific path geometry, so any path that's a list of points should be cuttable (as long as long segments get sufficiently sub-sampled - see the max_feature_size stuff), which lends itself both to us providing some nice default options, but also people being able to easily test out their own infill pattern functions ("easily" here being for all cases where the underlying pattern doesn't rely on the area geometry - otherwise the pattern/path designing might still be somewhat complex) :-)

That said, I view the cutting side of things as something like a "necessary evil" option (because it's kind of messy / less "nice", but is undeniably useful for some applications). Like in your initial comments, I'm also (/more) interested in being able to either warp a continuous path into an area, or generate one to fill an area, which I'm currently planning to approach as an interpolation problem, as per the second last point in that ideas list. I'm excited for the potential there, because once the base interpolation grid/process is established it should be relatively straightforward to add some lateral deviation to the fill lines (e.g. to turn straight into sinusoidal, for example). I started some work on this but haven't had the time to get it to a testable state yet, so haven't added it to the gist.

I'm quite busy with work and life at the moment, but keen to get back to this when I can :-)

[fullcontrol-xyz]

Right perfect, we are thinking identically 🙏

Let's get this polished to a minimal, but very valuable version, where 'any infill path can be cut by any outline path' , then do the shape fitting one (which I think may be actually simpler if we put some limitations on what kinds shapes and paths are allowed based on our shape fitting algorithms).

How about supporting the outline being defined by FC points and then converted to your polygon area? The area primitives you demo are interesting, but kind of separate to space filling concepts in my mind.

We can automatically segment any lined longer than min_size to help the user.

For conformal shape fitting, I have done quite a bit of stuff on that before. I think the simplest implementation is radial expansion/contraction. For solid infills, it will be important to also adjust extrusion width proportionally if the user has designed a solid infill pattern. Not particularly difficult in FullControl and a get distinction over slicer capabilities. For sparse infills, it won't matter so much, although infill density will be constant if we vary extrusion width, which is nice.

And no worries with being busy. Sorry for being slow slow to reply to many of your posts!

[fullcontrol-xyz]

P.s. For the basic proof of concept, I think travel over concave sections is completely fine. I have previously written algorithms that automatically identified the nearest next point which naturally meant different sections of infill were printed in a grouped manner even if the overall 'pattern' was a large square wave. But(!) that involves a reasonable amount of thought and effect and isn't even getting close to slicers' capabilities. So I think a deliberately simple method is clear to show people it's possible and let them put more effort in as required. If we go more down the slicer-functionality route in the future, we can add those capabilities at that time

[fullcontrol-xyz]

@ES-Alexander, do you have an interest in academic journal publication? I'm planning a paper on multiaxis toolpath generation. You certainly have the skills to improve such a paper. All the effort would end up in FullControl. I don't think there's a messaging option in github hence this message being slightly strangely posted here. Perhaps email a.gleadall@lboro.ac.uk if you would potentially be able to support the work. Then I can explain what I'd be looking for from you (not too much effort). I'm not checking emails there frequently atm (on holiday for a week), so no rush