In a month I picked up UE4 and made my voxel system:
There is nothing magical in a dumb voxel system.
Creating a similar procedural world with the scale of populus would take me about 6hrs in blender bge…
I actually did a quick and dumb minecraft system in a day, with plain object(cube) placement for terrain. It ran fine…
Seccond the way populus did it, isn’t the way a 3d polygon engine would do it.
Have you used 2d engines?
From what I learned in pygame, was that you draw most of what you see only once, then only update on each frame the tiny changes ( the area of 64 by 64 pixels) on the screen where the terrain changed or the character moved. If there was no change it was effectively a still picture, with background logic tics happening. A glorified paint program in a sense. That is why it worked on **** computers.
Then again a voxel system should be a part of an state of the art engine, because why should everyone need to reinvent the wheel?
Maybe the problem is that it is not meant to be. A stock system would result in boring games. Anyone who would want to spice things up would need to make enough changes to the point where there is little of the old code left.
That is why there is the procedural mesh component. It is flexible enough to be smooth or blocky, massive and responsive.
There are plenty of games that have reached higher technical fidelity than populus.
My suggestion now is to split your terrain problem into its core problems.
Is draw call batching something you need, or is plain object placement enough?
Try spawning a grid of cubes with height from a sine wave.
Do you know how to translate input ,to world position ,to voxel removal placement?
Try to log/print camera looking direction vector. Think, whether you need to raycast, or you can handle the ray purely logically.
Is low data look up overhead important, or does a dictionary( map ) suffice?
If pointers and flatened 3d arrays are not your thing, maybe a simple “map( (x,y,z) ) = voxel or not” lookup is easier.
Hopefully, I was not too annoying.