Slicing directly from non-mesh data?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.