[sjkelly]

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 :)

[fogleman]

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.

[bhouston]

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.

[user-the-name]

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

[andybak]

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.

[user-the-name]

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

[tdotuos]

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

[andybak]

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"?