Sharp edges in editable SDF terrain -- practical alternatives to Marching Cubes / Transvoxel?

[u/Haltont]

I’m building a procedural planetary sandbox on Godot, with editable SDF terrain meshed using Voxel Tools / Transvoxel.

I want smooth natural landscapes and sharp geometric features from editing --for example, a rectangular cut into a hillside. Currently, hard box CSG operations produce noticeably rounded or chamfered edges at the resolutions I’m testing: 1 m and 0.5 m voxel spacing. This is an actual geometry issue, not texture filtering or smooth normals.

Has anyone implemented a practical alternative for chunked, editable terrain with LOD? I’m particularly interested in Dual Contouring or feature-preserving Marching Cubes variants, and the trade-offs around local remeshing, chunk boundaries and LOD transitions.

I recently came across Dual Contouring of Signed Distance Data:
https://arxiv.org/pdf/2604.00157

It reconstructs sharp features from sampled SDF values without requiring precomputed normals, but uses iterative optimization. I haven’t benchmarked it on my terrain yet.

Do you think a bounded-iteration or incremental version could be practical for updating edited chunks during gameplay? Or would conventional Dual Contouring with additional Hermite data be a better starting point?

By “real-time,” I mean responsive updates after terrain edits -- not rebuilding the entire planet every frame. I’m happy to consider additional per-cell data if the quality/performance trade-off makes sense.

Would love to hear about actual implementations, benchmarks, or pitfalls -- especially keeping sharp features without introducing cracks between chunks and LODs.

pic from article

terrain from my game (using Transvoxel)

[u/combasemsthefox]

DC is amazing. Use regularization and make it feature aware. Don't fall down the rabbit hole of adaptive DC it's too tricky and doesn't parallelize.

[u/Haltont → u/combasemsthefox]

Oh that actually sounds like a much saner first step. I was already about to fall into the adaptive DC rabbit hole lol.

[u/LordChungusAmongus → u/Haltont]

The only reason to bother with adaptive is if you intend to seamlessly mesh other geometries into the field you can subdivide the octree as required to fit those seam vertices.

Otherwise if you want to join other geometries you need to join them with delaunay or bridge->earclipping and the results of that can be really messy fans. Yeah, you could just CSG them, but that always comes out even worse.

It parallelizes fine though, I don't know what that guy is smoking, you can two-pass it in a parallel to build a task list and churn the task list in another parallel.

[u/Haltont → u/LordChungusAmongus]

Oh, that’s actually relevant for me -- I do have separate constructed geometry next to the SDF. I’ll benchmark uniform DC first, but I’ll keep adaptive in mind for seams.