Fun story: why I got into hacker news in the first place was that I had a 3D printing startup way back in the day. I wrote a C extension to our rails app to slice up geometry to determine pricing. In some ways, this was a precursor to both my Rails and Rust work.
This looks real cool, and the logic behind treating OpenSCAD files this way in a 3d printing workflow is impeccable.
I stumbled at first because all my scad files use language features not supported in hob3l. It might help to call more attention to the .scad → (openscad) → .csg → (hob3l) workflow.
Blew right past my notebook's 8GB RAM trying to slice a complex fractal model at 6 levels of recursion. This is a "favorite" model of mine because I've never gotten openscad to slice it right: https://emergent.unpythonic.net/files/sandbox/flake6.csg.gz
Author here. Thank you for providing the file, I will debug it. I must admit that I spent almost no time to think about memory management, and my test files are way smaller. I guess this will be a debugging session. :-)
For anyone familiar with reducing computational complexity in linear algebra, this is a direct corollary to reducing matrix multiplication to vector multiplication.
A reduction in problem dimension leads to an order of magnitude reduction in complexity.
Since you're going for 3d print level accuracy, and appear to be targeting PLA or ABS, I wonder if approximation of the Booleans by tessellation and then using a BSP tree wouldn't be even faster and use much less memory.
RLE is probably fine too. Easy to do set operations on RLE data structures without "decompressing" them too. Quite a bit simpler than BSP trees for most people I think :-).
What are the limitations? The blog mentions that transformations are pushed to the leaves of the tree. Is this always possible? Are there operations that can not be implemented using slices?
Author here. All the common stuff (that is based on 3D CSG without extensions) works fine, and most for 3D construction operators just produce a polyhedron with a simple algorithm (e.g., linear_extrude), so that's fine, too.
But some of the more advanced CGAL based operations for constructing 3D objects will not work in 2D, because they are inherently 3D and complex, e.g. 'hull', 'minkowski'.
Nope. All slicers work by intersecting a plane with a 3D volume. In this case a CSG tree. At the bare minimum you need a way to tell if an x,y,z point is inside the volume or outside. In the case of a rotated cube shape, the x,y,z vector is just rotated/transformed the other way (inversely) than the cube, and the test still works. Most slicers will have more sophisticated methods of intersecting a plane with a volume...
You can probably get the model to a place where the actual orientation / position of each component is completely resolved into the final world coordinate sit will have, then do the slicing after that but before any intersections / unions.
I love OpenSCAD, but can't understand why it's so slow rendering. The viewer does it's own perfect render fast enough to pan/zoom/rotate, but rendering to STL is painfully slow.
It would be great to be able to switch to a slicing mode for rendering.
It uses a different library for the final render and the OpenGL preview is often not perfect for complex geometry. The former is creating an actual watertight 3d model, the latter is just using z-order to simulate one.
So this basically slices the object up in layers before exporting? What if the layer height is different between the export and the slicer? What about variable layer heights?
Well, yes and no. If your slice at 0.1mm with Hob3l, then slic3r can still decide that it uses 0.2mm or 0.3mm or 0.4mm slices -- it would just skip a few slices from Hob3l. I don't think there is a problem with that. It will get weird if you use Hob3l with 0.2mm slices and then slic3r with 0.35mm slices -- this will cause Moire effects. It is not wrong, but may look interesting...
We were far, far too early...