Variable Thickness Slicing For 3D Printers

With proper tuning, any 3D printer can create exceptionally detailed physical replicas of digital files. The time it takes for a printer to print an object at very high detail is another matter entirely. The lower the layer height, the more layers must be printed, and the longer a print takes to print.

Thanks to [Steve Kranz] at Autodesk’s Integrated Additive Manufacturing Team, there’s now a solution to the problem of very long, very high-quality prints. It’s called VariSlice, and it slices 3D in a way that’s only high quality where it needs to be.

The basic idea behind VariSlice is to print vertical walls at a maximum layer height, while very shallow angles – the top of a sphere, for example – are printed at a very low layer height. That’s simple and obvious; you will never need to print a vertical wall at ten micron resolution, and fine details will always look terrible with a high layer height.

The trick, as in everything with 3D printing, is the implementation. In the Instructable for VariSlice, it appears that the algorithm considers the entire layer of an object at a time, taking the maximum slope over the entire perimeter and refining the layer height if it’s necessary. There’s no weird stair stepping, overlapping layers of different thicknesses, or interleaving here. It’s doing automatically what you’d normally have to do manually.

Nevertheless, the VariSlice algorithm is now one of Autodesk’s open source efforts, just like the Ember resin printer used in the example below. The application for this algorithm in filament-based printers is obvious, though. The speed increase for the same level of quality is variable, but the time it takes to print some very specific objects can be up to ten times faster. Whether or not this algorithm can be integrated into Cura or Slic3r is another matter entirely, but we can only hope so.

25 thoughts on “Variable Thickness Slicing For 3D Printers

      1. what this does is automate the decision making of what one would plug into the slic3r variable layer height function, a very nice feature to have so one doesn’t have to manually add that information to specific models.

        but essentially what the printer does physically (and most likely the gcode generated) would be mostly the same in both cases, now look a year into the future and at a specific varislice slicing suite and we might have something really interesting going on.

    1. Jose, you’re correct. That would be faster. We used the more naive approach because (1) it was super simple to code and (2) believe it or not, scanning through the triangles is one of the fastest parts of the workflow in the current state. Slicing the STL and some other post steps (not mentioned in the video, but described in the Instructable) take much longer. Right now scanning through all the triangles of a STL with ~100,000 facets takes only a couple of seconds.

  1. I hope they didn’t spend too much of their budget on those audio special effects⚾️????.
    This is awesome. It could have been done many different ways. The fact they chose this way is something the whole community will appreciate. It puts a friendly face on a company that hasn’t been as hacker friendly as it could have been. Very nice inclusion of the prior art related to this. Just because something has been considered before doesn’t mean it was done well before.

  2. So you slice the STL model at 5um resolution, then analyze the model (not the slices!) to determine which slices to use? Needlessly convoluted data flow, if you ask me.

    Either analyze the slices themselves (XOR with dilation/erosion, doesn’t resolve finer than 1 pixel; seems it should be just enough, but I haven’t done much with morphological operations on grayscale images) or analyze the model first and then slice only the layers you’ll actually use.

    1. I’m pretty sure they lied for the sake of explanation, but you can obviously go way faster than they show on the video.

      Scan all the triangles, and note their perfect wanted slicing thickness (by checking the slope wrt Z axis) and their Z span (Zmin,Zmax), then you merge all the spans by keeping the finest wanted slicing thickness. You can even map/reduce it because the merging operation is commutative.

      1. Maybe so, except I wasn’t referring to the video — I was going off the step-by-step instructions in the Instructable.

        Don’t get me wrong — the way it’s apparently done is totally a hack, and thus belongs on hackaday. Given that it is, for whatever reasons, better, easier, and/or faster to make the slicing decisions from the STL file, this approach makes perfect sense for a proof of concept — you don’t touch the slicer code, just add a separate script to rejigger the output.

        But once you’ve got it working (and reported to hackaday), the next step should be either to integrate the whole mess in the slicer, or better yet patch the slicer to support variable layer thickness, and convert your program to a preprocessor that provides the slicer with layer thickness information.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.