That's pretty cool. I see you are using marching cubes. How are you handling sharp geometry (I'm assuming previews use a finite difference for normals)?

Also I see you are at formlabs. I'm sure you know of Matt Keeter's libfive :)

Yes, I'm well aware of libfive!

I'm not doing anything special for sharp geometry. For now you just need to use sufficient resolution until it looks "good enough." Normals are just based on the triangle normals.

Take the spatial derivative for the normals? Runga-kutta methods work wonders for that: https://en.m.wikipedia.org/wiki/Runge–Kutta_methods That works well if they are true signed distance.

Since you have a distance, you could fairly easily implement dual contouring, I think?

Or Surface Nets. Nice compromise of speed and quality. Marching cubes needs a lot of resolution and it's imperfections are especially ugly my eyes.

Maybe mesh resolution isn't a problem for 3D printing. But if 3D printing is the main goal why bother with a mesh? Just go straight to voxels that can be fed directly to the printer.

The printer does not use voxels, it uses G-codes, which are tool paths for the print head.

True for FDM, but for SLA you have the potential rendering a direct slice of the SDF.

OK. But a voxel representation has to be a closer match than a mesh. I guess overhang, solidity etc still need to be calculated and dealt with. Which is non-trivial.

Is it that "mesh to G-code" libraries are more mature than "voxel to G-code"?

This is great. Thank you for making it! The api layout tells me you are a nice person.

Love the library! I did not know about signed distance functions, and I am just amazed of the complex shapes that can be made from simple primitives.

Thank you!

If you want to go even deeper than that: https://www.youtube.com/watch?v=8--5LwHRhjk

What a beautiful library and api! I don't 3D print, but I'll be studying your code as a master-class in how python should be done.

out of curiosity, why did you not want to use OpenSCAD?

OpenSCAD is pretty rigorous regarding defining relative geometry. Like shifting origin and sketch on plane rotated 30° around X. It leads to unnecessary math to place objects.

It can be a bit cumbersome sometimes, but the only thing that really slows me down is the rendering performance. As soon as the detail level exceeds a certain range it basically becomes a bottleneck the size of a singularity.

Just the last few days I spent hours creating an external preprocessor for a project so I can feed as little data as necessary into OpenSCAD. Luckily it kind of worked and got me from "process gets killed after 70 minutes" down to "finished rendering in 5 minutes".

Still it's my favorite CAD software because the coding paradigm just feels so much more intuitive and simple than what FreeCAD and others do.

I'm definitely going to try out this project, though; it looks very promising as well.

(to the channel), I am sure you know about it, but this [1] technique for making a big design a tree of smaller designs works ok.

I feel like OpenSCAD is like 2 standard deviations away from perfection. Functions vs Modules and how clunky composition and application of operators over the object tree. It almost needs to be Datalog. Right now, it is a notch under SQL.

[1] https://old.reddit.com/r/openscad/comments/lbq58y/my_approac...

The problem in my case was that I wanted to combine a pattern with my objects that I precomputed using an external program because it contained a lot of curved surfaces. As I already knew OpenSCAD basically becomes unusable if you try to use a png image as heightmap I decided to instead generate a .scad file containing an array with precomputed coordinates, and then used that to build and extrude 2d polygons.

This kind of works for the 3d preview, but the stl renderer was not happy regardless. It was basically the worst case for OpenSCAD. But still, the fact I could just auto-generate a text file and use it directly for building models is fantastic. With tools like FreeCAD I wouldn't even know where to start, here it was basically a case of "it just works" and with a few more minutes it can be combined with a bash script for batch rendering.

Isn't this par for the course for constructive methods though? I agree that some things that are easy in a classic constraint-based CAD package are a huge burden in OpenSCAD. However, I don't see how signed distance fields would change that.

So elegant. Nice job!