Skip to content

Latest commit

 

History

History
56 lines (44 loc) · 3.26 KB

README.md

File metadata and controls

56 lines (44 loc) · 3.26 KB

WeekendSlicer

WeekendSlicer is a gcode generator aimed at 3D printing implicit surfaces. It is currently acting only as a proof of concept, with no promise of generating correct paths; if you attempt to use it, please inspect the generated code for dangerous paths prior to running it.

example.png

References and Motivation

  • Manipulation of Implicit Functions
    • This is an excellent introduction to the subject of implicit functions.
  • Fidget
    • Powerful library that WeekendSlicer relies on.
  • Interior SDFs
    • Motivation behind the algorithm WeekendSlicer uses. Eventually it would be nice to generate "correct" SDFs from surface representations; perhaps going from surface to volume mesh, then volume mesh to "correct" SDF using these techniques.

Algorithm Overview

WeekendSlicer uses a relatively simple approach to slice perimeters (which is currently all it is capable of):

  • Read the surface representation in. For each layer do as follows.
    • For each perimeter do as follows.
      • Remap the z-axis values in the representation to the layer mean.
      • Add extrusion_width * (perimeter_number + 1 / 2) to this new representation.
      • Intersect this with a rectangular prism with a surface with z = 0.
      • Mesh this new representation and extract the edge paths. The details of this extraction are not that important, this and the last step would not be needed if fidget had an equivalent to Mesh for 2D surfaces.
      • Add the edge paths to a list.
  • Convert the list of edge paths to gcode and write the file.

Q&A

  • Why is it called WeekendSlicer?

    • I initially wrote it over a long weekend.

  • Is this useful?

    • Not yet! It might become more useful if I continue to work on it - especially once it can slice objects not natively represented by functions. It also needs many other features implemented to be considered close to complete: infill (medium difficulty), top and bottom surface detection (medium difficulty), algorithm simplification/offloading (difficult), seam alignment (easy enough). It has a long, long way to go before useful.

  • Why is the code structured like that?

    • See the first question. I intend to improve this if I continue working on the project, but it is proof of concept quality code at the moment.

  • What the heck is going on in that path extraction algorithm??

    • Yeah, it's ugly and probably has bugs. At a high level, we make sure the mesh has a planar surface with "sharp" edges that is coplanar with z = 0. This enures that the outline of the shape is contained in the set of triangles with two vertices in this plane (up to some error) and one vertex out of the plane. We then simply encode these into a type that can be hashed in Rust and use this to order these in linear time. In fact, the whole extraction algorithm is linear, as awful as it looks.

  • How do I use this?

    • You really shouldn't yet, but if you insist on trying then the command should explain itself with the -h flag. Building the project is as easy as running nix build (if you use Nix).