I have a lot of respect for Johns work, but this post is mostly fluff.
> 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.
About half-way in, the author even admits that the article is a bit long-winded and not really getting to the point. Unfortunately, it then still doesn’t get to any point.
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.
> We’ve done a lot of talking about what the problems are and not a whole lot of proactive thinking to address them.
…
> 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.
For reference, this is John Lin who posts semi-frequent devlogs[0] of his voxel engine progress - an engine that is, in my opinion, one of the best voxel engines in existence rivaled only by Dennis Gustafsson's "Teardown" voxel engine.
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!
Is it the one that started with ‘Why don't games simulate every blade of grass? Here I've single-handedly made an engine for that.’ I remember seeing that some a couple years ago, but IIRC it was going for more life-like look than this vid.
I'm not familiar with modern stuff like Teardown, but the best voxels I've seen are in Vangers from 1998: https://www.youtube.com/watch?v=P9R7QJ5Sh1o (specifically the outside spaces).
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.
why the love for voxels? it seems like you get a much smoother model for the same representational cost with triangles on the surface.
(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)
I have no idea why from the perspective of a developer, but as a devoted fan of minecraft I can say it does look like the evolution of the genre.
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.
As the article implies I suspect it's the ease with which they can be decomposed. Before Red Faction I don't recall many games with destroy anything capabilities. Yet there were some experiments to do just that with voxel engines. Ken Silverman being the one I'm most familiar with, though besides some weapon models I don't think much of that made it into commercial games.
Most destruction in Battlefield games is pre-baked. For smaller stuff, the artists only specify how as segment of wall is supposed to break up. For larger stuff, like toppling skyscrapers, it's entirely a canned animation.
My own interest comes from nostalgia mostly. Many old games looked better using a voxel engine than contemporary polygon based ones. Though, of course I later realized in fact there weren't any real voxel engines in the sense of what I wanted them to be. I think Voxlap really was the first time we saw one.
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.
Without knowing the technical terms or details, I think of voxels as the things in Minecraft. A voxel game world, to me, is one where I could destroy or place any random voxel I want anywhere in the game world and have the game world smoothly and faithfully incorporate my decision.
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.
While voxels are often represented in cubes like minecraft, they don't have to be. A voxel is just a data point in 3d space.
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 think Minecraft changed the definition a little. Before Minecraft, a voxel was just a 3d pixel. Imagine drawing a single pixel using on paint, a voxel engine does that in a 3d space.
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
1) aesthetic is more novel than polygons, which are currently much more widespread (note: novel does not necessarily equate to "better" looking).
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).
Novalogic games used it for terrain rendering back in the day and got nicer visuals than their contemporaries (compare Comanche with LHX Attack Chopper, for example) as a result: https://en.wikipedia.org/wiki/Voxel_Space
Made me remember Vangers [1], an insane trippy game from 1998. Originally in Russian, it featured a very different world with a very deformed imagery and language. I don't know how this feeling survived the translation into English.
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.
My first exposure to working with voxels was in jMonkeyEngine (https://jmonkeyengine.org/) with a few plugins, when i wanted to display the sort of representation of a world that you see in games like Minecraft (the closest i had previously done was using particle systems for visualizing point cloud data).
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:
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).
Hey I was a developer on Ace of Spades when it was taken over by Jagex. Fun fact: it was written in python, which meant the hackers had an easy time reversing the net code, meaning cheating basically ruined the game.
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...
> 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.