Hi!

I'm creating a voxel-based terrain engine which will be able to represent sharp features (for artificial objects like buildings).

Streaming and Level Of Detail are essential for large-scale terrain visualization, but they introduce a non-trivial(?) problem: cracks between patches with varying levels of detail.

Is there any standard, industrial-strength solution for stitching voxel chunks with different resolution?

Transvoxel is suited only for smooth terrains, and Google tells me that Dual contouring is my best bet.

So far the best resources on this subject are this guy's blog:

http://ngildea.blogspot.ru/

and Jonathan Blow's generic BSP-based stitcher which seems to be fiendishly hard to implement:

http://number-none.com/product/Unified%20Rendering%20LOD,%20Part%205/index.html

Where do you get the LODs form the (arbitrary) mesh objects from? For some time now I try to produce (programmers-) art in blender and it is such a hostile environment for anything else than meshes. So come back to stitching when you can autoLOD a mesh. Or why you put the seams of the patches through buildings? Vehicles (mobiles meshes) at least do not share vertices with terrain.

I haven't implemented arbitrary meshes yet (they can be easily converted to a signed octree or a BSP tree serving as distance field).

Currently, I'm creating volumetric models from signed distance fields for testing purposes.

Models are represented as signed octrees and allow basic LoD by collapsing all nodes up to a certain level.

Though, at extreme levels of simplification the topology is destroyed (the mesh "opens up" and turns "inside out"). LoDs should be much better with Manifold Dual Contouring (2007) (based on Dual Marching Cubes (Nielson, 2004) which can place up to 4 vertices in a cell thereby guaranteeing 2-manifold quad meshes, but in "Adaptive surface extraction from anisotropic volumetric data: contouring on generalized octrees" they pointed out a non-manifold edge configuration).

I've implemented basic mesh simplification based on half-edge collapses (Stan Melax's algo, dihedral angles), but my iterative version was too slow for practical use.

My game concept is inspired by VoxelFarm, and I want to move on to large worlds where people can build anything (and you need LoDs for buldings).

As far as I know, in VoxelFarm both terrains and buildings are using the same representation.

My current goal is to implement a large procedural terrain which you boolean.

I have a basic chunk system with LoDs (no multiple materials yet), and I was just asking whether there is a good method for stitching chunks.

Oh sounds very advanced. I was just trying to say KISS. Speaking of Voxels, I cannot see any LOD in Pocket MineCraft, but it runs smoothly. Since we got fast hardware, LOD became the last aspect to optimize.

Stitching together chunks of regular grids is trivial. Move between chunks (back and forth), advance that side of the seam where the next point is most close. That would even work with bends in the seams.

The most interesting aspect for me is to inverse the problem. Draw the complicated buildings first (like i a space sim) and then fill the terrain.

LOD on arbitrary geometry is kind of nonsense for me because it touches the BDRF.

Sorry, I didn't understand why the problem should be inversed, drawing the complicated buildings first and then filling the terrain.

Did you mean I should connect terrain to buildings?

btw, I almost solved the seams problem yesterday using octrees.

All cracks are filled correctly, but the seam generator produces overlapping polygons (which causes Z-fighting).

Here's an ugly picture showing a grid consisting of 16x16x2 chunks (resolution of each chunk = 16^3) with some Simplex noise clipped by a box and a few shapes added on top:

I haven't implemented LoD selection yet, only experimented with changing LoDs on a single chunk.

the only overlapping polygons should be the "walls" of each bottom-level octree node, right? Have you tried clipping these based on the mesh for neighboring nodes?

yeah, I've run into the same problem as he did:

http://ngildea.blogspot.ru/2015/07/fixing-seams-bug.html

basically, the seam nodes gathered from the chunk's neighbors

generate polygons which coincide with the neighbor's polygons.

i.e. octree nodes collected from a neighboring chunk generate polys between themselves.

when later the neighbor's mesh is built, it will also generate the polys in the same positions.

maybe, there's a better algorithm for generating seams?

because all 7 neighbors (connected to the chunk via a seam) must be re-meshed whenever the chunk's LoD changes.