# Slicing directly from non-mesh data?

This is a bit of a weird question, and I imagine the answer might simply be "no." But here goes anyway:

I'm writing some code that generates shapes for 3D printing via "implicit surfaces," i.e. a mathematical function f(x,y,z) that is positive inside the shape and negative outside it. This works pretty well for designing the kind of shapes I want to print, but the problem is, turning the implicit surface into a good mesh is hard - there are some libraries that can do it, but they're kind of finnicky and you have to play with parameters a lot to get it to work well.

But I was thinking: the only reason I need a mesh in the first place is to send it to a slicer, which will ultimately throw away the mesh and turn it into gcode instead. My plan was to do

implicit function --> STL file --> gcode

but I'm wondering if there are any slicers that will let me skip the intermediate step and let me just do

implicit function --> gcode

instead. That is, my code would supply a 3D grid of voxels, containing the value of the function at each 3D point, and the slicer would create the gcode from that instead of from an STL file.

It seems that Shapeways have a nice and simple format called SVX that is exactly this, but as far as I can tell, this is only supported by Shapeways and not by any FDM slicing software.

Another option would be for my code to supply a sequence of 2D polygons, one for each layer of the printed model, so the sequence would be

implicit function --> big list of slices --> gcode

This would be both easier and more accurate than first converting it into a mesh, and I assume the slicer must generate this kind of representation anyway, before it calculates the path for the print head to take.

I suppose the question is, is there an existing CAD format that supports either of these options, that is also supported by existing slicer software? If so then I can just write my code to output in that format and it should just work.

• Have you looked at Mathematica? It will do parametric plots, and also exports STL files. Version 12 will run on the Raspberry Pi (including the latest version), and is available free of charge.
– Mick
Jul 9, 2019 at 10:04
• @Mick Mathematica is very much not free. You can get a short-term demo package for free, and in some cases can get it free while you are a student at a participating college, but never the full app. Jul 9, 2019 at 14:38
• @Nathaniel Couldn't you linear_extrude and then translate each slice to its appropriate height? Then render / export as usual.
– towe
Jul 10, 2019 at 6:30
• @towe that would work, but then there would be layer lines built in to the model! (Then again, if I make sure those are the same height as the layers in the actual print, it might not matter. I might play around with that some time, to see if I can get it to work.) Jul 10, 2019 at 16:41
• @DavidCary yes. In fact, the reason I want this is because I have my own implementation of an implicit CAD package, similar to ImplicitCAD except that it's Python instead of Haskell and has a somewhat different feature set, more suited to my needs. (Perhaps one day I will release it.) ImplicitCAD has the same problem as me: before its implicit functions can be printed it must first turn them into meshes, which hard to do well. ImplicitCAD uses a variation on the Marching Cubes algorithm, so its meshes are far from perfect. I'm hoping to find a way to skip that step. Nov 10, 2019 at 4:18

## No, not natively

To the current point, all slicers in frequent use do use some kind of 3D model with explicit surfaces to cut up into slices and then solve the path functions to create the G-code. The model can be in STL or OBJ or some other format, depending on the slicer, but at this point (November 2019), no slicing program I know about supports direct math as input.

## Probably make it yourself?

However, you have a way to design the models by solving a mathematical formula. You could probably use the program that solves the formulae to also act as a slicer of some sorts.

One software that might form a base could be Cura, which allows writing plugins, so there might be a way to have Cura automatically solve the surface formula and then plug that into the slicing without storing the intermediate data as an STL.

Slic3r might also work as a base since the whole source code is open. It would be a similar endeavor as modifying Cura.

• Thank you, that's helpful information. I wouldn't want to write a whole slicer myself - it would be no problem to solve the equation to cut the model into slices, but there's more to a slicer than that, e.g. calculating an optimal path, generating supports, fine tuning of temperature profiles, etc., which probably takes years of work to get right. Cura's API seems to be undocumented, so it's hard to tell whether I can do what I want by writing a plugin, but I'll look into it further. For Slic3r it seems I would have to modify the code base itself, but that might be easier than modifying Cura. Jul 9, 2019 at 11:01

This is a partial answer that I might make into a full answer if I follow it up later. (I'm posting in case someone else has the same question, in which case this might be helpful despite being incomplete.)

It seems that the 3mf format has a slice extension that does pretty much what I want - it allows the model to be specified as a series of polygons representing the slices, instead of a 3D mesh. So in principle I could simply output a 3mf file containing slice data, and load it into any slicer that supports this extension.

Unfortunately, this would mean learning what seems to be a rather complicated XML based file format, and I'm unsure which slicers currently support the slice extension. This seems to be quite a recent thing, and it might be a case of waiting until better support is available, in terms of Python libraries to write 3mf files as well as slicer support. (There are Python bindings for lib3mf, but their documentation currently consists of a single word, "TODO".)

There is also a requirement in the spec that any 3mf file containing slice data must also contain a mesh representation of the object. This is annoying because the whole point of this idea is to avoid generating a mesh. I suppose I could just output a bounding box or something instead.

This is my second self-answer. I'm posting it separately because it's a different technique. This one should work today, without any modification to the slicer.

I got a helpful hint from Cura developer BagelOrb in the Cura issue tracker:

Note that generating the mesh doesn't need to be as difficult as you might think. You don't need to connect the layers together, you only need to give your slices a height, so that Cura will slice each layer exactly where you want.

Just generate the 2D polygons and then extrude each line segment into two perfectly vertical triangles with the same height as your intended layer height - and BAM! you got what you want.

This is similar to a suggestion @towe made in the comments on this question, but the cool thing is you don't need to bother rendering the and bottom surface of each slice, because the slicer will just ignore them anyway. This is because, in BagelOrb's words,

The first thing CuraEngine does is slice the 3D model into polygons and the rest of the processing only uses these polygons. The 3D model is only used to calculate the areas of each layer and all other operations are operations on polygons.

Your mesh doesn't need to be manifold; only each slice needs to be a closed polygon.

The slicing stage within CuraEngine is a 2 step process:

• for each triangle generate the line segments for each layer with which it intersects
• for each layer stich all line segments together into polygons

Your model can look like this:

This is great because the top and bottom surfaces are very tricky to do correctly. It can be done in OpenSCAD using linear_extrude, but it turns out to be extremely time-consuming to union all the layers together. This way my code can just throw all the triangles into an STL file and it will slice correctly without any issue.

The other useful information in that thread is that Cura will slice the model in the middle of each layer. So that's where I should slice my own implicit surface model for maximum accuracy.

I did a quick proof of concept and it seems to work so far. I manually created an ASCII STL file containing the sides of a 1cm cube with no top or bottom surface. In "prepare" mode, Cura sees it as the hollow model that it is:

But when slicing it ignores the missing faces and adds top and bottom layers and infill, as expected:

I'll probably edit this answer again once I have the whole thing up and running.

• Open SCAD can export into STL or a different format respecting the origin. The exported files then can be imported in programs such as blender which also respect the origin. The accumulation of items then can be exported as one STL with multiple shells. Nov 11, 2019 at 8:50
• @Trish this is true of course, and I'd considered it. However, I'm super happy to have this method, where my code can just produce a printable STL file directly, without any additional steps. Nov 11, 2019 at 8:54
• Edit and show us the result in this answer when you print it
– FarO
Nov 11, 2019 at 14:59
• @FarO will do. (It might be a while because I'm travelling at the moment.) I did a quick proof of concept and added some screenshots to show that it does indeed ignore the missing faces. Nov 12, 2019 at 1:09
• HAve you tried setting top and bottom layers to 0 in conjunction with this? Aug 23, 2020 at 8:20