<h2>No, not natively</h2>
<p>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.</p>
<h2>Probably make it yourself?</h2>
<p>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.</p>
<p>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.</p>
<p>Slic3r might also work as a base since the whole source code is open. It would be a similar endeavor as modifying Cura.</p>

CC BY-SA 4.0
2019-07-09T11:01:35.710Z
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.
N. Virgo
CC BY-SA 4.0
2019-07-09T09:12:58.403Z
2019-11-11T08:53:36.413Z
2020-06-18T08:29:41.667Z
Trish
<p>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.)</p>

<p>It seems that the 3mf format has a <a href="https://github.com/3MFConsortium/spec_slice/blob/master/3MF%20Slice%20Extension.md" rel="nofollow noreferrer">slice extension</a> 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.</p>

<p>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".)</p>

<p>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.</p>

CC BY-SA 4.0
2019-11-10T00:59:02.293Z
2019-11-10T01:04:03.017Z
2019-11-10T01:04:03.017Z
N. Virgo
<p>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.</p>

<p>I got a helpful hint from Cura developer BagelOrb in the <a href="https://github.com/Ultimaker/CuraEngine/issues/310" rel="nofollow noreferrer">Cura issue tracker</a>:</p>

<blockquote>
  <p>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.</p>
  
  <p>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.</p>
</blockquote>

<p>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,</p>

<blockquote>
  <p>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.</p>
  
  <p>Your mesh doesn't need to be manifold; only each slice needs to be a closed polygon.</p>
  
  <p>The slicing stage within CuraEngine is a 2 step process:</p>
  
  <ul>
  <li>for each triangle generate the line segments for each layer with which it intersects</li>
  <li>for each layer stich all line segments together into polygons</li>
  </ul>
  
  <p>Your model can look like this:
  <a href="https://i.sstatic.net/qtAk2.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/qtAk2.png" alt="enter image description here"></a></p>
</blockquote>

<p>This is great because the top and bottom surfaces are very tricky to do correctly. It can be done in OpenSCAD using <code>linear_extrude</code>, but it turns out to be extremely time-consuming to <code>union</code> 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.</p>

<p>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.</p>

<p>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:</p>

<p><a href="https://i.sstatic.net/v7duH.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/v7duH.png" alt="enter image description here"></a></p>

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

<p><a href="https://i.sstatic.net/sV1jQ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/sV1jQ.png" alt="enter image description here"></a></p>

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

CC BY-SA 4.0
2019-11-11T08:50:48.540Z
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.
Trish
CC BY-SA 4.0
2019-11-11T08:54:23.843Z
@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.
N. Virgo
CC BY-SA 4.0
2019-11-11T14:59:25.613Z
Edit and show us the result in this answer when you print it
FarO
CC BY-SA 4.0
2019-11-12T01:09:46.047Z
@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.
N. Virgo
CC BY-SA 4.0
2020-08-23T08:20:04.820Z
HAve you tried setting top and bottom layers to 0 in conjunction with this?
Trish
CC BY-SA 4.0
2019-11-11T08:44:35.777Z
2019-11-12T01:08:53.890Z
2019-11-12T01:08:53.890Z
N. Virgo
<p>This is a bit of a weird question, and I imagine the answer might simply be "no." But here goes anyway:</p>

<p>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 <em>hard</em> - 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.</p>

<p>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</p>

<p><code>implicit function --&gt; STL file --&gt; gcode</code></p>

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

<p><code>implicit function --&gt; gcode</code></p>

<p>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.</p>

<p>It seems that Shapeways have a nice and simple format called <a href="https://abfab3d.com/svx-format/" rel="nofollow noreferrer">SVX</a> that is exactly this, but as far as I can tell, this is only supported by Shapeways and not by any FDM slicing software.</p>

<p>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</p>

<p><code>implicit function --&gt; big list of slices --&gt; gcode</code></p>

<p>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.</p>

<p>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.</p>

CC BY-SA 4.0
2019-07-09T10:04:17.373Z
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
CC BY-SA 4.0
2019-07-09T13:35:53.527Z
That last approach rung my OpenSCAD bells.
You should be able import each layer as a .dxf file in there, and have it render an .stl file from that. Maybe you can even implement the functions directly in OpenSCAD?
towe
CC BY-SA 4.0
2019-07-09T14:28:16.413Z
@towe I could import each layer, but then how to turn it into a mesh? If my shapes were convex I could just use `hull()`, but they're not generally. (I'm a huge fan of OpenSCAD, but it doesn't support implicit surfaces directly.)
N. Virgo
CC BY-SA 4.0
2019-07-09T14:38:58.473Z
@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.
Carl Witthoft
CC BY-SA 4.0
2019-07-10T06:30:25.823Z
@Nathaniel Couldn't you `linear_extrude` and then `translate` each slice to its appropriate height?
Then render / export as usual.
towe
CC BY-SA 4.0
2019-07-10T16:41:31.163Z
@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.)
N. Virgo
CC BY-SA 4.0
2019-11-10T03:48:41.250Z
Have you seen ImplicitCAD http://kalli1.faikvm.com/ImplicitCAD/Stable (via https://hackaday.com/2016/04/18/implicitcad-programmatic-cad-built-with-3d-printing-in-mind/ ) ?
David Cary
CC BY-SA 4.0
2019-11-10T04:18:35.827Z
@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.
N. Virgo
CC BY-SA 4.0
2019-11-10T04:24:30.030Z
(I am currently using a C++ library called CGAL to generate meshes, which is the same library OpenSCAD uses. It generates much better meshes than marching cubes and is fast, but unfortunately its implicit function meshing is a bit unstable - you have to play around with a lot of numerical parameters, and if you get them wrong it just randomly doesn't work, or produces a malformed mesh file, or occasionally just crashes. This makes it unsuited to a public release, which is one reason for wanting a better alternative.)
N. Virgo
<slicing><software>
Slicing directly from non-mesh data?
N. Virgo
# Slicing directly from non-mesh data?

(Asked by: username_0 on 2019-07-09)

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](https://abfab3d.com/svx-format/) 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.

**Tags:** slicing, software
> **Comments:**
> **username_1**: 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.  
> **username_2**: That last approach rung my OpenSCAD bells. You should be able import each layer as a .dxf file in there, and have it render an .stl file from that. Maybe you can even implement the functions directly in OpenSCAD?  
> **username_0**: @towe I could import each layer, but then how to turn it into a mesh? If my shapes were convex I could just use `hull()`, but they're not generally. (I'm a huge fan of OpenSCAD, but it doesn't support implicit surfaces directly.)  
> **username_3**: @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.  
> **username_2**: @Nathaniel Couldn't you `linear_extrude` and then `translate` each slice to its appropriate height? Then render / export as usual.  
> **username_0**: @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.)  
> **username_4**: Have you seen ImplicitCAD http://kalli1.faikvm.com/ImplicitCAD/Stable (via https://hackaday.com/2016/04/18/implicitcad-programmatic-cad-built-with-3d-printing-in-mind/ ) ?  
> **username_0**: @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.  
> **username_0**: (I am currently using a C++ library called CGAL to generate meshes, which is the same library OpenSCAD uses. It generates much better meshes than marching cubes and is fast, but unfortunately its implicit function meshing is a bit unstable - you have to play around with a lot of numerical parameters, and if you get them wrong it just randomly doesn't work, or produces a malformed mesh file, or occasionally just crashes. This makes it unsuited to a public release, which is one reason for wanting a better alternative.)  

---

## 3 answers

### Answer by username_5 on 2019-07-09. Score: 2

## 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.

> **Comments:**
> **username_0**: 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.  

---

### Answer by username_0 on 2019-11-10. Score: 1

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](https://github.com/3MFConsortium/spec_slice/blob/master/3MF%20Slice%20Extension.md) 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 by username_0 on 2019-11-11. Score: 1

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](https://github.com/Ultimaker/CuraEngine/issues/310):

> 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:
> [![enter image description here](https://i.sstatic.net/qtAk2.png)](https://i.sstatic.net/qtAk2.png)

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:

[![enter image description here](https://i.sstatic.net/v7duH.png)](https://i.sstatic.net/v7duH.png)

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

[![enter image description here](https://i.sstatic.net/sV1jQ.png)](https://i.sstatic.net/sV1jQ.png)

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

> **Comments:**
> **username_5**: 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.  
> **username_0**: @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.  
> **username_6**: Edit and show us the result in this answer when you print it  
> **username_0**: @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.  
> **username_5**: HAve you tried setting top and bottom layers to 0 in conjunction with this?  

---

