- 2022/02/20: finally published
- 2022/02/08: ready to publish finally with some delay
- 2022/01/28: not yet published, removed Universal Slicing details for future blog-post, added more photos and illustrations
- 2022/01/16: starting write-up
Aside of the technical detailed filled blog-posts I like to start to post about the larger context of my inner motivations doing XYZdims.com – this is the first post “XYZdims State 2022/02”:
Recent in-house developments having more slicers to experiment with, in regards of slicing techniques as well lay the ground for more complex slicing and mapping/transformation operations to support arbitrary non-planar slicing (coming soon).
LabSlicer: The Mother
As I was working with Slicer4RTN and wrappers like Cura-CLI-Wrapper and Kiri:Moto Slicer (CLI wrapper), and adopting Mandoline fork – I realized I need to have my own slicer, so in November 2021 I started from scratch, as I thought I need to know every detail and so I exposed each step or stage:
- mesh: load mesh, vertices & faces
- slice: slice layers into sets of polygons
- route: route the layer polygons with walls, infills etc
- gcode: convert routes to G-code
A “lab(oratory) slicer” or simply LabSlicer was born – I defined each stage: API and file-format it takes in and spits out.
After a couple of weeks I had slicing into polygons, and routing of walls, basic infills, skirts, brims and eventually intermediary top & bottom layers resolved, and I was able to generate printable gcode:
Meanwhile LabSlicer as of version 0.1.5 has matured to print complex models reliably but rather performs slow compared to Slic3r or Cura.
As of 2022/02 I’m even use LabSlicer and its relatives (featured below) for productive 3D prints.
Aside of LabSlicer I began to develop Vox3lSlicer which utilizes internally the OpenVDB voxel library, in order to slice planar and in the future non-planar as well, and also permit to slice voxel-based models efficiently.
A few tests with OpenSCAD Logo model (~20mm height) with various amount voxel samples, from low resolution to high resolution:
and with defined voxel sizes:
As LabSlicer matured and LabSlicerCore library came to life, Vox3lSlicer (2011/11) utilizes the stage route and gcode of LabSlicerCore to actually produce printable G-code.
Testing the retraction code and settings of Vox3lSlicer, rotating the model in order to avoid support structure altogether:
VoxGLSlicer: OpenGL Slicing
As I was looking for other slicing procedures I came across OpenGL-ST-Slicer, which utilizes a clever OpenGL setup with GLSL (Shader Language) to render a mesh to a framebuffer with the volume information, and so slicing is done solely in the GPU almost instantly – I extended this approach and glued it together with LabSlicerCore and I was able to produce also printable G-code – VoxGLSlicer was born (2022/01).
Due the limitation of the internal framebuffer width & height the resolution of the slicing changes with the size of the model aka “relative resolution”:
|model width [mm]||pixel size [mm] @ 2560 pixels|
|20||0.008 or 8 μm|
|50||0.019 or 19 μm|
|100||0.039 or 39 μm|
|200||0.078 or 78 μm|
|500||0.19 or 195 μm|
|1000||0.39 or 390 μm|
and just for illustration about “pixel size” related to a ~20mm model:
After a few weeks coding (2021/11-2022/01), I was able to raise 3 slicers, each with their unique slicing approaches to create printable G-code, by having a common API and use symbiotic advantage of each other:
|mesh||mesh.py1) multi-format mesh importer||openvdb STL importer||mesh.py1) multi-format mesh importer|
|slice||slicing mesh to polygons (vectorizing)||slice voxels into polygons (vectorizing)||screenbuffer into polygons (vectorizing)|
|route||route polygons to routes||LabSlicerCore’s route||LabSlicerCore’s route|
|gcode||convert routes to G-code||LabSlicerCore’s gcode||LabSlicerCore’s gcode|
|+ traditional slicer with polygons|
+ all stages fully implemented
– slow slicing2)
|+ fast slicing|
+ flexible resolution
|+ fast slicing|
– fixed screenbuffer size
– relative resolution
All three slicers are very experimental and play a significant role for the next step – Universal Slicing.
mesh.pyis loading/saving 3d meshs/models and some simple manipulations tuned toward my use cases
- mesh slicing not yet optimized
So any optimizing of routing (wall, infill, intermediary top/bottom layers etc) and gcode optimizing all three slicers benefit from.
YAGV & Nautilus Thumbnailer Supporting ArcWelder
After the implementing G2/G3 emulation for gcode2png as part of the G-code thumbnailer, I also added it to G-code viewer yagv fork of mine:
And just for sake of giving a bit of context, adding ArcWelderLib in the pipeline of Print3r via the configuration:
# first declare new post-processor named "arcwelder": post_arcwelder = ArcWelder %i %o # optionally, define it to be active (all the time): post = arcwelder
or optionally enable it on the command-line:
% print3r print cube.stl --post=arcwelder
That’s it for now.
- IotaSlicer, OpenGL Z-buffer slicing with multi-color, coded in C++
- OpenGL-STL-Slicer, OpenGL Z-buffer slicing coded in Python
- OpenVDB, Voxel library