The Perfect Voxel Engine
voxely.net
voxely.net
> So as you can see, conversion operators aren’t just for rearranging data; they’re more like black boxes. Input data of a specific format and let the engine figure out and execute the link to the desired output format. It’s such a simple concept that’s more general than volume conversion, and yet it’s managed to solve our problems.
Well, fair, but this has nothing to do with rendering voxels, or managing the n^3 problem of memory required for voxels.
All we get is the suggestion that spare trees aren’t ideal runtime structures, and a whole lot of talk about how it’s not ideal to structure your code around one specific implementation because it makes refactoring and trying new things hard.
Cool, I get it, good point… but I don’t think it’s particularly novel to have the idea of an engine built on a black box of data transformers.
…unless you’re prepared to go into the detail of what you’re transforming the data into that’s useful, which we got about 4 sentences of.
…
> We’ve observed the main problems with voxel engines being how our data is laid out and processed, and what happens when it’s not optimal for a given job.
…
> Now it’s time to apply these ideas to voxels. As I previously mentioned, the answer is simply to use whatever format is best for the job.
> But when working with volumes, it’s not that easy. Even with different formats, we can’t ever just store raw data for the entire world because of memory usage.
> Conversely, we can’t always work with compressed data because compression takes place after the raw data has been filled out.
…
> By building systems around formats that can be swapped out at run time or exchanged/changed in the future, your codebase is safe from painful refactors.
…
> The very thing we started out discussing and are going to close on. How do we take a dynamic voxel format with dynamic attributes and expect to throw it at the GPU?
> The solution here will have to wait until the *next post* where I take a deep dive into the rendering setup (I guess I accidentally lied on the last post). I’ll briefly…
I mean, I’ve obviously cherry picked quotes here, but you decide if I’m being unfair.
We enumerated a problem; it’s a well known problem.
Perhaps, there is a novel solution to the problem; there certainly seems to be the suggestion there is; maybe it’s not novel… but the solution is not shown, so who knows?
Does it need to be novel? Dunno, but it’s a bit rubbish to say you have an interesting solution to a problem, and your solution is “generic data processing at runtime” and give no other details.
In my opinion.
But I have sympathies for the author here. It’s sometimes really hard to verbalize conceptual ideas. You “feel” them, but any explanation sounds trivial. It’s likely there’s a bit more to it than your summary suggests.
Not sure what the author could have done better, I struggle with this myself.
It has destructible scenes, physics and even some gameplay. Much smaller & simpler scenes and not as good looking though. But pretty good for a 15 years old project!
Edit: found it—“voxel game StoneQuest microgeometry” https://www.youtube.com/watch?v=lXm5JWys55o
Now those are voxels I can get behind. Also vaguely think I've heard the name semi-recently.
The game is weird in the way that quite a bunch of people on HN should appreciate. I didn't give this much thought in the day, when I was young and used to 80s/90s full-on craziness, but now I realize it's genuinely hard to construct a world that is completely foreign while simultaneously also homely and warm and fuzzy.
(I used to do scientific visualization and have written voxel renderers...it just never occurred to me that someone would want to do that for general purpose graphics)
If voxels just mean the smallest rendering primitive is a cube instead of a triangle then I agree it seems just like an artistic preference.
It can be rendered or visualized many different ways including smooth curves or many other things. While blocky cubes are common that is not all they are or can do.
I need to do some reading.
you can certainly also do a gaussian with alpha if you dont mind drawing jello...are there other approaches you know of for direct rendering?
A Minecraft voxel is much more complicated than a pixel in 3d. It has textures, the shape/graphics changes depending on what angle you see it from and can even have animations.
I guess the term has evolved now but I find naming Minecraft as a voxel game mostly as a marketing gimmick. No one calls 8x8 block of a NES background tile a pixel
They might, if the point of the NES game was to arrange those blocks into personal artwork.
Nothing as spectacular as Red Faction. I had totally forgotten about this game. The second one didn't even make a big deal out of blowing walls up
Minecraft has "voxels" (they are rendered as polygons) that are 1 meter square in size. More granularity would add a lot to the games. There are even mods that try to add a more granular kind of voxel to the game, like "chisels & bits". That one specifically is very popular and used in most modpacks, so that might be a hint for a successful voxel game in the future.
Why the appeal now? Voxels are a simpler model for describing the world and adding granular detail, at least at first sight. Ultimately you still have to model bending, physics, animation, free rotation, etc. which is AFAIK more complicated than for polygon based 3D data. Essentially a voxel object still needs to have a secondary parametric representation to describe things like elasticity or connectivity, etc. (not sure how it's done), though I assume the techniques are not too far off from skeletal animation etc. in traditional engines (which also use such a simpler representation overlayed on / inside the mesh.
But I think that leads to the second appeal: Trying to squeeze out a few more polygons per second or a specific little effect on the fundamental technique level in traditional 3D engines is pretty hard but only gives you so much in return. I can understand how something you can approach with a fresh set of eyes, with fewer established working solutions, is appealing in itself. There's (seemingly) more to discover, more to invent.
2) The finite limitations "leave more to the imagination" - in the same way that low resolution pixel art might, vs a high resolution vector image.
3) A very minor factor, but worth noting: not only are voxels visually novel, but they are technologically novel - in order to make a competitive voxel engine, you typically are not using an off-the-shelf engine like Unreal or Unity (though you can, and there are many voxel pluggins for these engines). Thus programmers are drawn to them (IMO) - they are an easy way to visually show off your technical know-how, just as you might many other effects in the demo scene.
4) A false sense of nostalgia - voxel engines never were very widespread, and the closest thing in the early days tended to be height-map driven rather than volumetric (the earliest notable exception being Voxlap). But the "nostalgia" exists, just as it does with synthwave (most of which does not fully mirror any music of the 80s/90s).
5) Voxels are point-based volumetric representation and thus are much easier to use for procedural generation (vs describing a surface, which is much harder). Though voxels are often wrapped on the surface with polygons, this is trivial (vs, say, describing the polygonization of a metaball without using voxels).
They're good for giving mass to objects instead of just having a shape. Thus far that's mostly meant they're used for terrain which is destroyable.
It's main game mode featured racing on (hostile) surface of various planets, which utilizes a voxel engine, which gave it a very distinct look.
Almost immediately, it became clear that any sort of a larger world needs a lot of optimizations done to work properly, so there were quite a few algorithms to be grokked.
Personally, i found quite a few posts talking about things like meshing:
- https://0fps.net/2012/06/30/meshing-in-a-minecraft-game/
- https://blackflux.wordpress.com/2014/02/23/meshing-in-voxel-engines-part-1/
- https://blackflux.wordpress.com/2014/03/01/meshing-in-voxel-engines-part-2/
- https://blackflux.wordpress.com/2014/03/02/meshing-in-voxel-engines-part-3/
And also even a few about things like real time occlusion culling, which doesn't get talked about a lot: - https://procworld.blogspot.com/2015/08/voxel-occlusion.html
Nowadays, i'd advise that people look at the more established projects/engines out there if they just want to get something working, though it can also definitely be interesting to try getting something working all by yourself.Also, in regards to pretty interesting voxel engines out there, i do believe that Ken Silverman's Voxlap engine deserves a mention: http://advsys.net/ken/voxlap.htm
It was written around 20 years ago, yet remains an interesting project to this day - its performance is impressive, and IIRC it achieves this in a software rendering mode, something that's surprising even today. It was actually the basis for the Ace of Spades game, the modern (free) version of which is known as OpenSpades: http://openspades.yvt.jp/ (though i think that the project now uses a different renderer maybe, it's been a while).
The game did have some fun aspects to it, especially the zombie mode (every game needed a zombie mode for some reason). Bad management and bad technical choices destroyed the game. For example a mobile version was developed, no idea why anyone would think that would work...