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...
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.
We were far, far too early...
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
Slicing level 5 only took about 4GB RAM so maybe level 6 needs around 24? https://emergent.unpythonic.net/files/sandbox/flake5.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 a good idea. Seems like one of those ‘why hasn’t anyone thought of this’ kind of ideas.
Of course it only works for CSG, so it’s not a panacea for any file you want to print. But when it does apply it’s great.
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'.
How does it work if you have 3d rotations in your design?
Say I create a 3d shape and then make 30 copies rotated at different angles, like in gear or a bracelet?
Wouldn’t the slices end up getting rotated out of plane?
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.
Right... and also, as you increase the model complexity rendering correctness and speed take a dive to the point the preview render is unusable.
I've thought for a while that STL meshes in 3D printing workflows may be a detour in many circumstances.
CSG is one example, volumetric models (from CT/MRI scanners or simulations) are another.
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...
Unless you have 0.1mm detail, in which case it will just disappear completely.
I think the eventual idea here is to have your slicer support .scad files as well as .stl files.
Yes, but it looks like it would still be impossible for the slicer to slice different height layers with this.