I implemented a quick Marching Cubes for anyone who wants to play around with
OpenSCAD function literals its based on BorisTheBrave 256 MC tables.

get it at
https://github.com/TLC123/OpenSCAD_stuff/blob/master/MarchingCubes.scad

I have played around and dual contouring and sharp features is possible but
far to slow in userland andmos cases defeats the purpose.

or  https://www.thingiverse.com/thing:4675583
or
https://openscadsnippetpad.blogspot.com/2020/12/marching-cubes-for-openscad-function.html
http://forum.openscad.org/file/t1678/MC.png

--
Sent from: http://forum.openscad.org/

Yep that is pretty much my results.
Sharp features and adaptive resolution is top on my wish list,
Second is: An adaptive resolution intelligent subdivision that /taste/ the
curvature to tease out all topology. (think finding a hairline hole feature
through a huge cube ). finding features thousands of times smaller than
bounding cell without sampling everything at that resolution

I tried a lot that does work but is scary complex to write.
In most versions i stored the entire mesh in list and tried to massage it to
behaviour.
In DC i generated all faces as axis aligned. then a pass were i glued up all
common vertices. Then a pass to globally fit the boxy mesh to the zero
boundary. Then pass that to relax(should have used delauny here but to much
pain). Then  break all edges whose midpoint din no lie on the boundary and
fit them to the boundary with a corner function and verify that they was on
the boundary or else fit to it without the corner function.
even wrote a half edge engine. But you can imagine what it takes to flip a
single edge in a huge mesh with no native slicing functions.
in the end i derived  sharp edge by splitting candidate edges of triangels
in isolation. Wasteful but it worked brilliant on monotonic sharp edges but
broke when two overlapped or cornered wrong. My conclusion was if the
distance function is moderately fast fancy data stores is neat but slower
that sampling multiple times.

This was before function literals when i used a interpreter for my scene
graph language.

So when literals came around in experimental i needed a stable platform to
figure them out.
function returning function really breaks my brain.

This time i choose a economic octree decent with early bailouts. Every
polyhedron stays in the cell it was born. This means that The distance field
needs to be continuous and pretty well behaved.
Every cell is evaluated in isolation so there is 8X waste on shared corners.
There is no gluing up in post(other than what Cgal does). Neighbors will
match upp because they operate on the exact same data.
Sharp edges probably could be worked out locally within each cell in
isolation but need experiments.

This implementation is kind of as ugly as MC is and the main drawback is its
horrendously expensive when small features are hundreds time smaller than
the bounding box. I made it to be a small include and useful for most.

Marching Cubes is the baseline and everyone is called upon to improve.
Hey maybe even suggest polygonization of distans fields as a native
primitive?

--
Sent from: http://forum.openscad.org/

My main insight from working these problems
is that any closed mesh can be refined, re-meshed and fitted to the
function.
But it can't easily change topology. There fore one must start right with a
mesh of
the same topology / genus as the distance function

My unsolved residue:
Question is how to find and represent the topology of a distance function.
(3d straight skeleton ? simplified to a connectivity graph?)
if that is at all possible. Once you know the topology.
Perhaps generating a generic flow mesh with the proper number of holes at a
rough position.
And hopefully from there its all downhill computation.

--
Sent from: http://forum.openscad.org/