support level-set material type

[stevengj]

If the user could supply a (differentiable) level-set function φ(x) (such that it uses material A for φ<0 and material B for φ>0), instead of the current material function, that would provide enough information to do efficient subpixel smoothing even for user-defined functions.

In particular, suppose we are in 3d and are evaluating the material of a voxel. We evaluate φ at the 8 corners of the voxel (possibly caching function evaluations from neighboring voxels). If they are all the same sign, it is material A or B. If they differ in sign, then we can do subpixel smoothing as follows:

1. Using the 8 points, fit φ(x) to an affine function α+aᵀx. This is an 8x4 least-squares problem.

2. Now we know the normal direction (a) and the intersection plane α+aᵀx=0, we can compute the fill-fractions of A and B. One approach is to just position a block to coincide with this plane and call our existing routine. Another is to use formulas like the ones here to find the intersection of a planar half-space with the voxel.

Note that the user could interpolate a level-set function from a sufficiently high-resolution image by something like fast marching.

Note also that we could eventually incorporate this into our topology optimization routine — once we have sufficiently binarized the structure and the topology has stopped changing, we could switch to a level-set representation. This would probably require us to completely change how we compute the gradients, however.

[stevengj]

(This would be in src/meepgeom.cpp — it would be be a new material type just like MATERIAL_FUNCTION, but would switch over to a different subpixel-averaging routine.)

[smartalecH]

Doesn't the prism object already support subpixel smoothing? If so, it might be easier to do the discrete shape optimization over various prism object vertex points, rather than a level-set.

For most practical applications, the design needs to eventually be projected onto some sort of polygonal basis anyway. Several libraries (e.g. shapely) can even do erosions and dilations on the polygons needed for continued robust optimization.

I could see this being an issue for applications that optimize in all 3 dimensions (e.g. 3D printing). In that case, a level-set would be ideal.

[stevengj]

One basic drawback of optimizing over vertex locations is that, if an object expands too much in some region, you may need to increase the number of vertices.

[thchr]

Marching cubes could be an appealing way to do steps 1 and 2 as well, i.e use the marching cubes tables instead of solving a least squares problem (presumably, some of the more complicated face-configurations would difficult to really treat meaningfully though).