I think one benefit this gives us is on the artist contribution side. Being an art contributor on the project has a lot less overhead of being a formal "artist", since you can quite easily make fauna or creatures or just concept art. We've seen lots of this in our blog posts!
But also, in terms of terrain itself, I think it allows us to really crank up how wild and wacky our procedural generation is, and still have a great looking world (unlike something higher-fidelity like No Man's Sky). We do a lot of cool things under the hood; we have a full erosion system that creates the mountains out of the sea, a site system that places villages in places that make sense, and the ability to mash together shapes that then get "rasterized" into voxel houses. I don't know how much of this would be possible and still look alright if we weren't taking a voxel approach.
Currently Veloren has water and lava, but neither will flow (e.g. if water blocks are manually placed on top of a hill, they won't flow downhill, fortunately this is rare due to worldgen). A simple way to fix this would be to have an ECS system that uses CA-style rules (e.g. a water block with an adjacent-and-below air block swaps places with that air block), though naively doing this would be expensive (iterating over all loaded terrain chunks every tick). A possible optimization would be to detect such blocks, remove them from the main terrain grid, put them in a separate entity-with-terrain-collider (the same kind we use for airships), and only iterate the (sparsely populated) AABB of fluids-that-have-recently-moved. This is similar to what Noita does with keeping track of recently-updated terrain rectangles. Once this is in place, it can be straightforwardly extended with more fluid interactions (e.g. Minecraft-style water + lava = obsidian, more Noita-inspired gases rising).
Just to parrot back what (it sounds like) you're saying: using voxel-based assets in a game with community-contributed assets that extends itself using procedural generation is that the difficult of integration tends to be lower. This is because voxel shapes allow "artists" (which don't necessarily have to be highly-skilled) to build game-appropriate assets fairly easily, and for the generative process to more easily combine those elements into a cohesive world model than might be possible with polygon-based assets. Does that sound about right?
So basically + Cohesive world + Ease for artists + Doesn't need to look so real
I think this is the basic principle as to why Nintendo was able to get away with underpowered consoles for as long as they did. At least in comparison against other beefier consoles out during each releases duration.
So long as the aesthetics and quality are consistent, people are willing to accept a lot.
There are comments from some developers over the matter from a while back. I think one of them was Todd Howard, back from when 'Todd rays' still weren't a thing.
Erosion - https://veloren.net/devblog-43/ Erosion + rivers - https://veloren.net/devblog-36/ Towns - https://veloren.net/devblog-31/
There are lots of other blog posts that discuss these topics, I should really aggregate some of these sections in the future. Those links go into the most detail I think, future stuff is more about tweaks than the core systems (we've been putting out a blog post each week for 160+ weeks now!)
On a non-voxel game it'd be very obvious that there were a bunch of different artists involved who were working somewhat independently.
Imagine, if you would: build a 64x64 "flat" foundation of stone. Clicky-clicky-pokey-pokey to place/remove colored blocks. Post something somewhere to someone: "Hey, I have some fresh voxels for someone to do something with!" => scrape-world.php => asset.vxl => etc...
Basically, games with a built-in level-editor tend to be easier to contribute to. Minimally: the potential "editors" are already familiar with 90% of controls, viewpoints, and can see the asset "in-game" already (and they're probably already "in the game / editor" already, no context-switching to blender or autocad or something).
I'm 1000% sure that if minecraft added some sort of symmetry + polygon + joint/bone/connection-point tooling, you'd see an explosion of polygon assets available within the community.
The technical reason that voxel games are "easier to build" is that you can easily make a 1000x1000x1000 array of integers/chars, and get a 50-"voxel" radius from somewhere and start rendering it with raycasting. Can you render a square? Can you render 100 squares? Boom => voxel engine. Can you get/set a 3d-pixel (voxel)? Can you click "destroy/create" on a raycast target? Boom => voxel editor.
The fundamental complexity of voxel data structures is higher: O(n^3) for iteration, and the density of polygons required after meshing is generally much higher. The only real benefit from a complexity standpoint is that storage and access of specific voxels is much faster, but this often doesn't represent a payoff.
Voxels are great for a lot of things, but making a game like Veloren run quickly is much harder than you might initially realise. There's a reason that we're told at least every 3 years that a new company has come up with the 'engine of the future' using voxel tech only to have it vanish into obscurity as they try to turn it into something that's not a tech demo.
For Veloren, there is a big benefit: we get to create enormous procedural worlds. But actually controlling the complexity of that data and efficiently storing/accessing it is a non-trivial change as you'll see from the project's dev blog.
That seems a bit misleading. With uniform voxels the occlusion culling becomes much easier and you only render surface polygons.
On the other side you don't get hand made imposters so rendering far away mountains and such becomes a challenge. You dont want to render every voxel of a distant object if a voxel is smaller than a pixel.