Ok so I just complete two points that come to topic over and over again. Sure, you can create dynamic terrain in Unity as it supports dynamic mesh updates during runtime. I used it in a prototype to procedurally create grass meshes on the shape of terrain at where the player stayed. If he moved, the grass mesh needs to fit to the shapes of the terrain as well so I updated the mesh frequently.

Doing terrain is the same, you have a mesh that consists of points with different heights. This is your base terrain, you know have to do some texture management that is also possible during runtime to place whatever texture is used at that given point in your terrain. You then need to optimize your data by linking larger equal parts together to reduce the mesh size in memory

Second level is dynamic LOD. To do terrain LOD, you usually will split your terrain into a quad tree to determine the cells and cell deepness to display. Some old fashioned tutorials written in C did do this dynamically on camera position change, some other more modern games calculated just the lod chunks once and displayed one for another without recalculation.

Last but not least, it depends on the requirements you have how efficient it is to generate your terrain as it may never change after deployment. Holding meshes in memory means consuming rare VRAM and not-so-rare RAM. Assuming a common setup you have 8 GB RAM and 1 - 2 GB VRAM to consume while hard drives reach 1 TB sin a tandard setup for today. This means you have more time in generating your terrain cells than you have while simply loading them from hard drive. This may make a difference depending on the kind of movement; A walking simulator will have less chunk reloads as a fligth or driving simulator

On 5/8/2018 at 7:09 AM, Gnollrunner said:

Well in my case voxels stay roughly the same size relative to the camera.

Now I get it. By using screen space you will always have a constant amount of triangles on screen; smart.

So I assume you will then be looking into boolean functions, that way you can keep track of volume in very simple formulas. Like a BSP(Binary space partitioning) Mesh.

Very interested to see what happens.

Well here's basically what I do.... You start out with an icosahedron and you project the faces out to form 20 prisms. Each prism you can subdivide into 8 smaller prisms and so forth and inside each leaf node prism you can generate triangles via marching prisms. So it's an octree or rather 20 of them. Then for each octree there is an algorithm which decides which parts of the tree make up chunks based on the distance from the camera.  Basically it builds prism shaped chunks that contain prism shaped voxels such that from the camera any voxel with terrain data (determined by the fractal functions) will appear roughly the same size. Yes voxels on the side of a chunk closest to the camera will be a bit bigger and those on the side of a chunk farther from the camera will be a bit smaller but that's only within a chunk. On average they will stay the same so therefor the meshes that are built from them will have geometry roughly the same size relative to the camera.  That pretty much takes care of the LOD and that part isn't actually too hard. The hardest part is transitioning from a higher resolution chunk to a lower one because you have to build special voxels that aren't really covered by the basic marching algorithm.   Furthermore there are issues of knowing if data exists lower in the tree because you only want to build your octree down where there is data.  So there is some fancy caching and other stuff and it all gets rather complex. It's written in C++ with templates in many places, custom slab allocator heaps, and so forth since I need every ounce of speed from the CPU.  On the upside that leaves me the GPU for doing to graphics but I haven't really gotten so far with that yet. The only thing I did was implement simplex noise in HLSL.  I'm going to try to do most of the shading of the terrain with functions rather than straight texture maps.

Your game sounds a lot like https://wildmagegame.com/, it uses a very destructive terrain. Uses Unreal.

I still think the engine you should look into is the Unreal engine. Mostly because you know C++ and because you will need a lot of power to swap meshes around dynamically.

This video gives a good idea of how many polygons unreal can render: https://www.youtube.com/watch?v=oMIbV2rQO4k it is a trick of course. But one that could easily be used with voxels.

The other advantage is that after you made your terrain system you would still benefit from the massive amounts of extra tools and options Unreal has.

Actually as I'm doing further reading I'm starting to think I don't need a game engine.  What I need is a graphics engine, possibly something like irrlicht. The reason is I'm basically doing everything programmatically so a lot of what a normal game engine provides like level design and placement of trees and such is wasted on me.  I'm not really an artist.  I'm kind of an old geezer programmer. I've been programming for over 35 years, and I started out doing Fortran, C and 8086 assembly language.  My first graphics was done on a CGA card where you had to use Bresenham's algorithm just to draw a line, and the first RPG I played was table top D&D with little metal figures (so you can guess how old I am :-D). In any case, thank you guys for your input.  I really appreciate it!

14 hours ago, Gnollrunner said:

something like irrlicht.

Actually when you mentioned you don't need need complex collisions I did think of Irrlicht. However the the reason I didn't mention it was because it lacks many things needed to make a finished large scale game.

The good news is if you use something like Irrlicht and can't make the game you want, then transferring the code you already made to a engine won't be difficult.