SuperVGA said:
What is lower res geometry if not LOD? Regardless of how it's achieved, it's LOD to lower detail in the distance, won't you agree?

Well, there are surely differing interpretations of that LOD term. I did not intend to present some personal one as the only truth or something - sorry for that.

But in context of Minecraft, there is low res geometry, yes, but there are not multiple levels of detail. That's why i say it has no LOD at all.

We have multiple options for LOD:

• None. Which is always the best option if we could afford the performance loss and eventual resulting aliasing.
• Discrete LOD. Which is most common, meaning to generate e.g. 5 different meshes at different detail and display depending on distance. That's very practical technically, but increases cost on asset creation and does not work for continuous terrain (where heightmaps are still state of the art).
• Continuous LOD, which is about things like progressive meshes. The holy grail, not really achieved yet, not even by UE5.

Grimmlok said:
simply merging smaller “cubes” into bigger and bigger one the more far away u go

Ok, that sounds like a plan. Atomontage does exactly this. It's much easier than doing the same with meshes, but personally i have not seen it yet in any Minecraft alike voxel game. (I may just don't know about examples.) Probably because of this problem:

Merging 8 voxels into one also means merging different materials and disconnected geometry. A House might join a nearby rock at some distance, so this only works well if resolution is high. Likely the solution becomes a hack, tuned to work with your specific game. And likely this means spending big effort, even if the closeups remain blocky and one might think it should not become a big problem.

Doable, probably Voxel Farm is the best example (has been used for the cancelled Everquest 2). But you know, it's made by one guy who works on this for many years and still there is no game out using it, AFAIK. If you want to go there, you work on technology, no longer on a game. That's probably not what you want, thus my response. But i do not really know about your goals.

So, why do you need big draw distance? Do you need dynamic, user editable world? Do you want cubes? Can you eventually turn your procedurally generated but static world into chunks of surface meshes and use the standard technology U engines offer? Result might still look like voxels as intended, and development could focus on the game, less on tech.

Grimmlok said:

@Gnollrunner

Ah ok so u kept working on it for several years now..
U think u could extract a early alpha or smthg to show it to me..?

@Grimmlok You know I'd rather put out a good video when I get the physics debugged completely and am walking on the surface (or at least sliding with stand in physics spheres in place of a character) . That should be sometime next month (crossing my fingers). I'm actually using the mesh collider I wrote years ago so I know it works, but I have to tweak it to work with the voxel stuff. Most of my stuff doesn't have a lot of shading yet because I've been mainly concentrating on the geometry. I'll probably steal some shading code from my old project too.

By a stroke of luck I found an 3D artist/animator yesterday so I put out this crude wire frame video to show him how the LOD/Chunking system works. It doesn't look great because it's wire frame and looking down on the surface, but at least you can see how the LOD is working as you pass over the surface of the planet. It's somewhat jerky because I'm dragging it by hand with the mouse, but you can see the LOD is pretty fast, especially for an old computer and only using the CPU. It uses a thread pool to do fractal calculations (mostly 3D simplex noise) and it builds what I call a “ghost tree” of voxels. This is a simplified voxel layout with no adjacency or mesh information. It only saves voxel vertex and edge function calculations. There is also a cache map to keep from calculating the same voxel corner more than once when building the ghost tree.

I do it this way because you can't actually know if there is data in a voxel until you query it's vertexes and edges, and I don't want to build complex voxels and throw most of them out when I find out they are empty. Some people use SDFs (Signed Distance Functions) to make this fast, but they are not so easy to construct and I didn't want to get into that rats nest. Once I know what needs to be built then I take the ghost tree and add it to the real voxel tree. The real tree has adjacency information so when when you apply your marching algorithm to actually make a mesh out of it, it's all in one piece. I never have to go up and down the tree to piece together the mesh. It's built as a mesh in one shot which makes it a lot faster because it avoids traversing so much memory to get to an adjacent cell which is normally a problem with trees.

There is nothing loaded off of disk at the moment. When I get to doing player modified terrain, I'll have to start storing stuff, but my main focus for now is to do a huge planet where you can see long distances, yet it doesn't really take any storage.

There are also some other details like how to handle the functions. First you want to be able to introduce functions to produce caves and fissures at only higher levels of resolution. The reason is, if you have a cave under the surface at a low resolution, a large scale voxel won't catch it and you end up with unwanted artifacts. For instance instead of a cave you shouldn't be able to see at range, you get a hole in the ground which you can see, and that only disappears when you get closer. This means corners of voxels can change from solid to non solid which is OK, but you have to do some special handling when there is an LOD transition because a voxel's vertex can be both solid and non solid at the same time.

I also want to store more than one dataset in a given voxel. For instance you might have terrain, but you also might want a lake or an ocean. Since the voxels themselves and not the mesh take up the most memory, it's better to reuse them as much as you can, in this case for both land and water. It's a huge waste to generate the same voxel tree just because you need water, lave or something else.

Fully 3D functions do not really make for good planets. For the basic terrain on a large scale you still want roughly height mapped terrain. It's only at a more detailed level that you want to add caves and overhangs. Since there is a still a height function aspect, you want to be able to cache that part because each voxel vertex in the same vertical column will check it and if you don't cache it your computations will go though the roof. That's simple for flat non-LOD voxels but when you wrap them around a sphere and add LOD you can't just use a 2D matrix. I solve this by building a “unit sphere” which is a variable LOD ico-mesh that corresponds to the the most detailed geometry above it. All voxel corners in a vertical column reference the same unit sphere vertex where function values can be cached, and referenced by any voxel vertex in it's column.

Finally the whole thing has a special reference counting system to keep ownership under control. The complexity is pretty crazy at this point, but it seems to be pretty fast and the memory is not too bad. Each voxel is actually quite large but by doing all this stuff it keeps the number of voxels to the minimum. There is also a bucketing heap to pack sibling voxels in memory together, so I use one child pointer instead of eight and then I have relative addressing heap pointers which cuts the pointer size from 8 bytes to 4.

You can look at my old video to see what it looks like zoomed out a bit.