Updates:
- 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
Table of Contents
Introduction
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”:
More Slicers
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.
Vox3lSlicer: Voxels
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:
3 Slicers
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:
LabSlicer | Vox3lSlicer | VoxGLSlicer | |
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 + reliable | + fast slicing – fixed screenbuffer size – relative resolution |
All three slicers are very experimental and play a significant role for the next step – Universal Slicing.
Footnotes:
mesh.py
is 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:
Print3r
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.
References
- IotaSlicer, OpenGL Z-buffer slicing with multi-color, coded in C++
- OpenGL-STL-Slicer, OpenGL Z-buffer slicing coded in Python
- OpenVDB, Voxel library