I am writing after tinkering a bit with grasshopper for the generation of custom toolpath in the 3D printing field. For context, I print viscous materials (similar to clay) and the goal is to use Grasshopper as a custom slicer to tightly control printing trajectories and unlock new possibilities for infills, especially TPMS.
I have already managed to build a Grasshopper algorithm that slices an Axolotl TPMS surface in the shape of my object and writes GCode using the obtained curves. The challenge I face now is to correctly sort the infill curves and link them with segment perimeters to create a path as continuous as possible. I have tried to explain as clearly as possible what I am trying to obtain :
Also, in the step 1, the direction of the infill curve is unified (from bottom to top) and then odd ones are flipped.
I thought the easiest way to proceed would be to use end points to sort the curves and connect them this way but I didn’t manage to have it work as intended yet.
I was then wondering if there is a practical way of achieving step 3 with GH components otherwise I will start digging into Python scripting to implement the sorting
Using shatter on the surrounding cuve with the vertical curves should give you list of segments per curve
Cull the correct segments (every second)
Then join curves.
I could not test. You have to provide a file if you want us to do so.
Just internalise the curves on your image + code you have.
Hi Eef,
Thanks for your feedback ! Here is a simplified file of what I want to do (in this case with just a rectilinear pattern) : Slicing continuous path test.gh (574.7 KB)
I included 2 mesh examples : a cylinder, and a more complex organic mesh.
I first tried something like you suggested. But the problem is that the perimeter segments are then ordered clockwise along the original curve and not according to the infill curves. Therefore, in certain cases it visually seems to work (like in the cylinder case in the file) but in other cases, it creates some kin of loops instead of a continuous zigzag (like with the organic mesh). I believe the cylinder is more of a special case because the first and last infill line intersect the perimeter only in 1 point.
Also, because of the ordering, when I try to write the GCode based on the points, they are not in the right order. So I should find a way to create a single curve with all the segments on each line. I tried “join curves” but it doesn’t seem to work as intended.
Yes I feel like I will have to. The sorting I want to achieve seems too specific for the existing tools.
I wanted to ask for the community’s opinion before engaging in this task since I have seen on some posts that you frequently have wonderful solutions to these kind of problems !
I’ll start getting familiar with the scripting module while waiting for some answers and get into it if no solution pops up.
Hello Vincent. Impressive on what you already did.
Not easy to just jump into the structure (Including a cluster) you already made. For me too far to jump from the work you did to the question above as you explained with an image.
So I have three suggestions: One
Please isolate just one layer with a contour + your lines on the same plane. Like above. My idea would be to first create a pattern of the printer just going down the line, sideways, go up, sideways. In fact zigzagging. That way you are sure all these lines have the correct direction.
Then lay your contour on top of this. With curve | curve (or scatter) you can find exactly all intersecting points/segments.
You would have to check, but I think the intersecting points of the contourcurve will have the correct sorting order.
Next step is to work on connecting the segments of inside lines and segments of countourcurve.
I will be happy to think with you when there is an example this far. You will probably be able to do this very fast.
Two
Outside grasshopper, I would study to do this with a common slicer like orcaslicer or simular. The algorythm you are working on, is very basic there.
What kind of nozzle size + printwidth are you working with? I will be happy to give it a try there.
Example of a cube 250 x 250 x 250 cm3, printed with nozzle 10 mm + printwidth of 10mm.
Three
On Food4Rhino there is an older plugin (probably more) what has routines for printing + also for infills. Maybe have a look there, and see if you can use that in any way .
Eef,
Thank you for your answer. Yes sorry it’s a bit messy, that’s why I tried to simplify. Here is the same example with one slice isolated in which the zigzagging doesn’t work :
In this example, the infill curve should be correctly oriented (even ones are going from bottom to top and odd ones from top to bottom) but it doesn’t seem to change the order of the resulting perimeter segments. Let me know if you find a way !
For the external slicer option I use routinely PrusaSlicer and print with a 0.2 mm nozzle, and 0.3 mm print width. It works but our goal on this research is to optimize the pathing for our material and implement new infill types that are not available in Prusa (Diamond or Fischerkoch TPMS for example).
For the plugins, I am also investigating that. For now I found SaladSlicer but I found little documentation to use it properly. And the main issue is that such plugins are built for particular workflows and it’s difficult to feed them with pre-made trajectories. Moreover, from what I saw, they are usually built for architectural/artistic surface printing with clay, and as such do not seem optimized to print an infill… I would be happy to be wrong and find a plugin that does this exact job !
Interesting ! The result is close to what I expect, with some oddities I would say. Is it possible to feed it custom infill curves ? For example, if I slice a Gyroid, can I feed the planar curves obtained on each slice to this module ?
It’s a shame it’s a paid option but we might consider it if it does exactly the job
Not a solution yet but coming closer. Not much time now, but I use cull Pattern to kick out every second segment after shatter. NB: Now important information about contour is lost!. Consider making an inner contour at printwidth distance, so you will not have double printing lines!
It is possible to measure distance between Starting-or Enpoint (just one of both) of the parallel lines and measure distance to nearest end- or startpoint of contour segments. Use distance to sort correct segment.
I am not good enough at working with data list, but sure someone will jump in and solve this very fast (and I will learn too )
I tried to generalize a bit by double sorting the perimeter segments along the main directions of the infill curves. It’s kind of janky and I think this solution won’t work in a generalized case (for example for wavy infill lines, if they cross the perimeter multiple times, might be a problem). I still share it in case someone needs to solve the simplified version and is fine with the limits of this solution
I’ll probably get to coding for the generalized case
The thinking process brought me to the next suggestion. To work with best of two worlds.
On youtube there is https://www.youtube.com/@slant3d. He has nice ideas, suggestions and some essential methodical approaches. One of it to not let important decisions to the slicer, but have control within the CAD program you are using (that is exactly what you are doing).
But also to do not work what it not needed. Maybe you can combine it like this:
1.
Design the inlay you want as brep, give it any shape you want, with curls, angles, whatever you want. Use as much as possible thin walls on outside + inside (just 1 printwidth wide)
Insert this in the shape you want to use. Quick and dirty could be to use solide difference, scale it a bit down so it fits inside.
Send this to the slicer, using the settings you need. NO inlay, but let it slice the inlay you made. You will probably get a G-code what is very close to what you achieve on the grashopper coding way you are searching for.
The value proposition of Nautilus is exceptional. This plugin stands out as one of the premier options available, offering an extensive array of highly practical components. Furthermore, Laurent has repeatedly implemented additions based on user requests, like me when encountered challenges - demonstrating outstanding customer service. It’s a worthwhile purchase that won’t disappoint.
otherwise I will start digging into Python scripting to implement the sorting 
