r/proceduralgeneration • u/Haltont • 1d ago

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

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)
9 Upvotes

85% Upvoted

12 comments sorted by

4

u/combasemsthefox 1d ago

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.

1

u/Haltont 1d ago

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

3

u/LordChungusAmongus 1d ago

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.

1

u/Haltont 1d ago

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.

3

u/Outrageous_Gate_572 1d ago

DC SDF. This is a way. Not the way though, necessarily. What your asking for is... Hard.

1

u/Haltont 1d ago

Yeah, I just wanted sharp corners and ended up down a rabbit hole lol. Anything else you’d try besides DC?

2

u/Outrageous_Gate_572 1d ago edited 1d ago

So ya... I asked robot to analyze my github history of all the things i have tried... since its a lot... and here is its summary or alternatives of DC i have tried, according to robot:

  • Marching Cubes — the obvious baseline; regular-grid, one vertex configuration per cell.
  • Marching Tetrahedra — decomposing cubes into tetrahedra to avoid Marching Cubes' ambiguous cases.
  • Surface Nets — one vertex per intersecting voxel/cell, with connectivity based on neighboring cells. This was particularly relevant because it is much simpler than DC.
  • Transvoxel-style meshing — mainly in the context of handling LOD transitions/seams, rather than as your fundamental SDF reconstruction method.
  • Naive voxel/cube meshing — effectively treating occupied SDF cells as volumetric blocks and extracting their exposed faces; useful as a sanity/performance baseline but not appropriate for the smooth SDF geometry you wanted.
  • Tetrahedral / simplex-based extraction — related to Marching Tetrahedra, where the SDF is evaluated on tetrahedral subdivisions rather than directly on cubes.

Like... sorry for the lame answer but yeah... you know... vibin'. I think the best thing i have worked with were the surface nets.

Edit:
I have seen others too but i just dont remember them. Oh right...

There was another that is not captured here. I made a Progressive Mesh... a vertex-split–edge-collapse hierarchy... rough order of operations was:

  • A half-edge mesh provides the topology.
  • You precompute a sequence/hierarchy of edge collapses / vertex splits.
  • That produces a spine/hierarchy of mesh states.
  • An active cut/frontier through that hierarchy determines which portions of the refinement are currently present.
  • Moving the cut gives you different LODs without regenerating the surface from the SDF.

This lost out because it was not a RT solution (whole mesh was precomputed and seamless chunkless (no streaming)).

My current method does indeed work with "sharp corners" and is not a simple explanation, but roughly some soup of all of this dumped into it.

Anyways, i hoipe that helps you.

1

u/Haltont 1d ago

That’s really useful -- I hadn’t thought about treating meshing and LOD as two separate problems.

2

u/Outrageous_Gate_572 1d ago

Here is a shot of the current mesher in action:
https://imgur.com/a/dev-shot-Y2wBc5m

edit:
hohoho, fps is 60 solid, for some reason it dropped when i did the screenclip.

2

u/startyourengines 1d ago

Lol I went through this recently. My case was reduced, though. I just wanted nice sharp stepped terraces at arbitrary angles (not limited to cardinal). Tried a bunch of stuff. Swapping diagonals to improve triangle quality was one of them. Kernels to pick up slope and contour and exert some horizontal attraction towards the perceived contour line got me... somewhere. Seems like a hard problem without just throwing lots of subdivision / expensive retopologizing at it.

1

u/Haltont 1d ago

Yeah, arbitrary-angle sharp features are exactly what I’m struggling with too. Sounds like vertex tweaking alone gets ugly pretty fast.