I'm a little curious, is there a technical reason why voxel games are easier to build than non-voxel ones? The docs mention that all of the assets are community-contributed. Does making them voxel-based just drastically lower the skill theshold to make a contribution, vs. smoother ones in something like Blender? I guess I'm a little curious about the relative amounts of effort that would have been required to make this kind of game (procedurally-generated open world, I believe) using non-voxel assets and mechanics, since the existing set seems to be pretty fully-featured.
Great question! Core developer here, and I haven't thought about this too much.
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.
This is really interesting, thanks so much for the reply! It's awesome to get a little bit more insight into projects like this, especially because I've got a limited (but growing) insight into both playing games and building projects with game engines.
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?
Ya, it's certainly a art style that gets complimented by both the artists, and the developers that work on worldgen. There's a lot of grey edges as well; at our last release party we had an artist create an entire pre-made city, and load that in for players to explore at our release party. None of the city was proc-gen, but it was really great to see how the architecture was put together when it was crafted by a human, compared to how our different proc-gen cities/forts/encampments look a lot more like they're part of the landscape.
So basically
+ Cohesive world
+ Ease for artists
+ Doesn't need to look so real
> 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.
From what I understand about the Dreamcast and even the Sega Saturn, is that both were underutilized in a myriad of ways, but one of the, the dreamcast I think, had technically two gpu chips.
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.
Great game! Is there any resources where someone can learn more about procedural generation? Curious to know what places one can learn about "full erosion systems".
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!)
bringing the idea further... is it possible to move the game towards something like "noita" where each pixel in noita can interact in a ton of ways etc... except here it would be a voxel?
I don't think so with the current engine, however, we do have a pretty solid particle system that does allow for some cool visuals similar to Notia. But that said, I'm not sure what "Notia inspired" physics would look like in a 3d game... I guess a lot of blocks melting? Could be cool to experiment with :) I know there are voxel engines that are far more geared towareds this than we are, we try to store information about each voxel as compactly as possible for efficiency, and we use LoD at the macro level (mountains off in the distance) rather than the micro level (zoom in really close on a single vosel, more geometry becomes visible).
I do think adding a Noita-style cellular automaton would be fairly straightforward.
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).
If I put a 5 year old in front of a polygon based 3D modelling program they will have no idea what to do, and even if I teach them the tools they will have trouble. If I put a 5 year old in front of Minecraft they will eventually figure out how to build stuff. I hope this answers your question.
I've always imagined that voxels are the pixel art of the 3D world. Much easier to create from both an aesthetic and development point of view. Hard discrete edges that fall along the XYZ planes are much easier to program for (think collision detection etc).
It's easier to be consistent when everyone is on voxels. If you give all of the artists full freedom then it's a lot of work to make things match in one game.
On a non-voxel game it'd be very obvious that there were a bunch of different artists involved who were working somewhat independently.
As someone who has lead polygon games and voxel games, let me say if you are looking for community contributions, voxels are way to go. Decent looking poly assets need professionals, and professionals are expensive.
There's a benefit to direct manipulation of pixels/voxels within the game.
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.
Its easier to generate destructible worlds using voxels than chunking meshes in some other way. It brings on some other challenges and benefits as well.
Guessing here, but perhaps the computational complexity for rendering voxel assets is much more bounded, e.g. you can't make something with a super dense vertex count and complex shaders and other transforms and bog the game engine down.
Actually, completely the opposite is true. There's a reason that voxel games appeared after games with more traditional meshes.
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.
>and the density of polygons required after meshing is generally much higher.
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.
