findContoursAdaptiveMarchingSquares

Finds contours for shapeFunction over an adaptive quadtree, like findContoursAdaptive, but resolves each straddling leaf independently with plain marching squares instead of dual contouring -- there is no dual vertex, no faceProc-style stitching between cells, just every leaf's own crossingSegments gathered up directly.

The referenced article (https://www.mattkeeter.com/projects/contours/) motivates dual contouring with two problems this naive approach has: cracks where differently-sized cells meet, and bevelled corners. Only the second one actually shows up here: this file's buildQuadTree collapses a cell to QuadTree.isFull/QuadTree.isEmpty only when all four corners agree, so any straddling (QuadTree.isLeaf) cell is always driven all the way to maxDepth -- meaning two straddling leaves are never adjacent at different sizes, and there is nothing here for cracks to form between. (A more aggressive strategy that can leave a straddling region coarse -- e.g. an error-tolerance-based one -- would reintroduce exactly that crack problem, which is what makes dual contouring's cell-independent stitching valuable in general, even though this specific tree-building strategy sidesteps it.) Bevelling, on the other hand, is unavoidable here: a marching-squares crossing point is always found along one of the cell's four sides, so it can only approximate a sharp interior feature, never land on it -- unlike feature's least-squares placement, which can. Concretely, on a square with a sharp corner at depth 7, findContoursAdaptive lands within 2e-5 of the true corner; this function is off by about 0.09.

Parameters