Skirts between differing LOD borders occasionally leave holes

[TokisanGames]

See more in action with different materials:
https://youtu.be/uNVG_49DGNo

@Zylann said:

These are supposed to be hidden by skirts most of the time, but they can still show up. Either because skirts are too short (but couldnt figure out a better sweetspot), or because adjacent octrees have slightly different outcomes in their subdivisions which makes them not line up as if they were one.

In #59 this was identified as an issue with marching square skirts.

This is different from #57 which appears to be rendering in between the removal and repairing of the terrain during edits.

[TokisanGames]

Nick Gildea referenced in #24 posted two blogs about stitching seams between chunks on his Dual Contouring terrain.

He says at the end of the first if you're using marching cubes you'll need something like Transvoxel. But since you use Octrees with DMC, maybe it's useful?

https://ngildea.blogspot.com/2014/09/dual-contouring-chunked-terrain.html

https://ngildea.blogspot.com/2015/07/fixing-seams-bug.html

[Zylann]

There is a huge caveat coming from Godot when it comes to handling seams: they either have to be part of the mesh, or be separate meshes.

In the first case, this requires to remesh A LOT more times than necessary, since any edit or LOD transition requires to rebuild and re-upload the entire mesh and its neighbors on each update.

In the second case, this basically triples the amount of meshes Godot has to render, so triples draw calls and slows down culling.

Last time I investigated this, seams could be swapped in and out by directly altering the rendering method (index buffers?), which ideally doesn't involve any remesh or reupload since seam configurations would already be embedded in the mesh. Other "efficient" methods also involve altering the rendering itself, which is not possible without forking VisualServer to add specific methods. No wonder voxel engines are often best built in completely custom engines^^"
This is why I've been settling on simpler methods like marching squares, or another one I have in mind which is to over-polygonize a little bit using a slightly higher isolevel.
There might be techniques involving shaders, but doing this may constrain the way to write shaders for this kind of terrain.

Note: I'm not really using octrees for mesh generation. There is one in DMC but it's not as effective as I thought.

Note 2: even if we get perfect seams, issue #60 remains

[Zylann]

Update: it would seem another voxel plugin does create extra meshes for the seams in Unity, which can do dynamic batching as they have the same material. My hopes are quite low regarding the performance impact of this method in Godot (because it doesn't do such batching) but I'm not opposed for someone to try it.

Also:

I need to add viewer pinning to the demo so we can see what this geometry actually looks like, that hole "doesn't look right".

[TokisanGames]

Most (all?) holes appear on borders between different LODs above 2.

In the top row, the hole appears only when LODs 3 and 2 are next to each other. When it's all L2 (4th pic) or all L3 (5th pic) they don't appear. I moved the camera back and forth and counted LOD shifts from 0.

In row 2, notice the overdraw does not show a hole for the top one.

In rows 2 & 3, the size of the meshes looks like where L3 and L2 connect, as above.

In row 4, this particularly large hole appears where L3 and L4 connect.

[Zylann]

I just found out VoxelStreamNoise is busted when it comes to LOD. The noise buffer optimization has a bug in it, which causes LOD data to not exactly line up with differing lods. With marching square skirts this was kinda rare to see but holes could occasionally be found. With Transvoxel it's now obvious because seams of that algorithm are supposed to be perfectly lined up, assuming blocks of different LOD share half of their values thanks to nearest-neighbor downscaling.
I took out the optimization, and now the generator is back to slow-ass, but the map is watertight. Noise buffering will need to be rewritten anyways.

Screenshots posted earlier show VoxelStreamImage, it's possible it has the same sort of problem but I haven't done the same test on it yet.

In other news it means I'm almost done converting VoxelLodTerrain to Transvoxel. Will need a bit of cleanup and fixing other bugs I uncovered along the way, such as this one.

[TokisanGames]

This one here #63 (comment) is VoxelStreamNoise.

[TokisanGames]

Transvoxel has fixed the holes in the mesh in this ticket. However, it has introduced a different type of hole as the highest LOD is disconnected from the rest.

[Zylann]

I can't see them:

(the black seams at the bottom are normals acting up)

[TokisanGames]

I saw it on VLT heightmap using distance 4096, LODs 8.

[Zylann]

Indeed. Close-up, we can see a working transition mesh on one side, and the other side totally missing one. The neighbor has a transition mask of 0, which is invalid.

[Zylann]

I think I fixed it with 051034f

[TokisanGames]

Yep, even extending out the terrain beyond the far clip I see no holes anywhere. Good job!