Don't start yet another voxel project

For pet projects, voxels can make a lot of sense. They allow you to build a world by simply editing a few noise functions and move on, no hastily-made tools that need to be rebuilt a year later, no mucking around in Blender. For the programmers trying to learn how to make a game with the aim of getting a team together once they have the basic skills, this is ideal. They can leverage procedural content generation to provide them with nice-looking (usually) visuals, without their needing to show of their terrible 3d modelling / design skills. it's also inherently and intuitively deformable and requires that the developer pick up some very useful knowledge on compression, multi-threading, GPU computing and optimization. All of these skills transfer to a more mature project with a real team, as well as typically encompassing the standard skill-set required to code a game.

There's also the allure of games like Minecraft and ID's new tech they're toying with. People are seeing voxel tech more and more and it's intuitively linked to their understanding of matter. They figure it's easier to work with, overall than building the shell of a thing.

My first pet-project was a Minecraft-like infinite terrain generator (actually more infinite than minecraft, as minecraft uses a height limit) using 3D perlin and perfect cubes at 1/4 the size of minecraft's cubes. It ran fairly well on my admittedly high-end machine, even with all the fancy shaders I could muster. I theorize that for marching cubes I had more than enough resolution to produce a realistic terrain with enough detail. You see, these days terrain is still fairly low-poly. Due to normal mapping and tessellation you can get away with a fairly low-res voxel base (perhaps 1 voxel per metre). I got bored before messing around with marching cubes, though so I can't be certain on the performance

I dont know, i agree with Nick, we started one and honestly we have been able to learn a lot about how the game design works. ( not say we wouldn’t if we had static terrain ).... but the idea of having infinite blocks and chunk spawning actually really helped us to define a very robust and capable engine. Right now we are 6 months in and can have over 10,000,000 blocks with no lag on a medium machine. This is using DX10/DX11 shaders and tools. Our lighting system is dynamic and the generation of randomized terrain really helps us to better understand how things work.

Secondly, its not like minecraft did it all. In fact, minecraft is still missing a lot of core functions that make a game, a game. With those elements still left untouched a person could very much make another good voxel based game. Wolly and his project is a prime example. Think of minecraft not as a game and any voxel game after that a clone; rather think of voxel based games as a genre and we are simply coding games within that realm.

Ultimately, i think voxel based gaming is just the start. I like to imagine it like...8 bit art back in the day. They were pixel by pixel, and eventually we learned how to render thousands of pixels at once. When further development and pushing of the edges we could turn voxels into atoms, and from there we could make a world very similar to our own. Call me a dreamer, but it is a foreseeable future.

I dont think voxels should be used unless you want to represent a volume, meshes are just better for surfaces.

For any of us non artists voxels/cubes are nice in that they are sort of the equivalent to pixel art in 2D which means you can create something kinda consistent looking in 3D without being a 3D artists...

I think the main attraction with voxels (setting the Minecraft hype apart for now) is the simplicity of generating procedural content with them rather than with triangles. This means programmers from all over the world no longer have to painstakingly hire artists to design high quality terrain meshes and textures, or they don't have to show off their programmer art skills, but they can just generate it themselves to produce something decent (if dull). Of course there is an immense difference between a basic perlin noise texture and a realistic marble surface but it's a start. For voxels this is easy - just use some scalar field (density function using perlin noise for instance) and use that to decide whether a voxel is "solid" or "air", in the simplest case. It's well-documented and quite intuitive once you understand it.

Obviously it's difficult to generate a highly structured object procedurally, like a sculpture or something, but remember not everyone is trying to make a game. Many people are just, literally, playing with voxels, trying various things not because they want to make the next Minecraft but because they are just curious and want to explore the possibilities voxels offer them. Others just want to make cool, abstract-looking things, which are actually more suited to procedural generation (3D fractals anybody?).

Unless at an extremely fine and consuming resolution, aren't voxels too homogenous to bear much arbitrary definition? Do you concretely understand how much memory voxel data might consume, given theoretical circumstances? If you are experienced with voxels, how much memory consumption have you been able to mitigate (not theoretically!), and by which techniques?[/quote]
Obviously if you are going to render raw voxels, no level of resolution will fix the blocky look. But if you interpolate voxels (e.g. marching cubes) you can get away with a surprisingly low-resolution mesh thanks to normal/parallax mapping. An interesting advantage is that you can adjust the resolution to the available computing resources, providing natural scaling as processing power increases. You can't do that with precomputed terrain. You can also use adaptive sampling which will subdivide voxels further in high frequency areas to make sure the surface remains smooth enough to be convincing (but this is easier said than done).

If you plan to work with voxels, or already have (preferably), in which kind of way?[/quote]
Voxels are nice for applications which consider a continuous volume in space (like fluid simulators as you suggested) and as such can be nicely approximated with grid subdivision a.k.a. voxels. This is - to me - the most interesting use of voxels. But then again in these situations you don't really think of them as voxels, but rather as cells, as the word "voxel" is very tightly associated to rendering in popular culture thanks to various games claiming to be "voxel-enabled" etc... After all, a voxel is just a fancy name for a 3D volumetric point, and from there it is used in various ways (e.g. sampling interval for fluid simulations, scalar field sampling point for voxel rendering, etc..)

@Bacterius

I think the main attraction with voxels (setting the Minecraft hype apart for now) is the simplicity of generating procedural content with them rather than with triangles[/quote]

No. There's always simplicity in procedurally affecting content, where the nature of its containment always has particular advantages. Both triangle mesh and voxel based substances have exclusive advantages. Skeletal animation is an equivalent for triangle meshes, just as the simplicity you've noted in voxels. But with voxels, the basis of content has always (in practice) been generated by atomic functions (random noise functions etc). Later in the pipeline, after the basis of content is generated, reiterated operations can be applied to enhance the existing content (which certainly is a procedural process, but not procedural generation). Voxels only have a single, static basis of content (the homogeneous volume), which manifests them to be problematic for the purposes of procedural generation, contrasted to polygons. "Procedural generation" isn't generic for "generation," and neither is "generation" generic for "procedural."

Obviously it's difficult to generate a highly structured object procedurally, like a sculpture or something[/quote]

Yes it would be difficult. I can imagine using triangles to make something such as a seashell, a pillar, a simple water fountain, a pot, or a rock that doesn't look like a blob (like with voxels ). But if you actually wanted to craft a procedure for generating a human statue (I'm assuming a human statue), you could either go by a roughly user defined procedure (i.e. replicating the steps an artist uses to model a human), or you would require an insanely sophisticated mechanism for encapsulating the nature of a human's shape, to an extent. We can begin to imagine how this would work, and how it might determine the final surface's triangulation (if using triangles), but its not worth discussing here (lets stay on topic).

This means programmers from all over the world no longer have to painstakingly hire artists to design high quality terrain meshes and textures[/quote]

The original Marching Cubes algorithm had a patent (but it has expired), and there's an ever growing crap load of new patents regarding voxel techniques. Users still need high quality textures, unless they generate them (But voxels aren't for that anyway). I don't think very many (non-voxel) algorithms which can apply to generating terrain meshes (e.g. height-map) have been patented. And since when was voxel terrain higher quality than any other generative technique? I've marked "low-resolution" in bold:

Obviously if you are going to render raw voxels, no level of resolution will fix the blocky look. But if you interpolate voxels (e.g. marching cubes) you can get away with a surprisingly low-resolution mesh thanks to normal/parallax mapping.[/quote]

As far as I can tell, normal/parallax mapping hardly relates to interpolating voxels. This interpolation can often, also, be too blobby.

You can't do that with precomputed terrain.[/quote]

Plenty of games don't use either "precomputed" terrain or voxel terrain. Take BF3 for example.

As far as I can tell, normal/parallax mapping hardly relates to interpolating voxels. This interpolation can often, also, be too blobby.

No but the idea is that interpolation dramatically increases the topological richness of the generated terrain compared to simply using cubes. Sure it will be still be blobby to some extent, as all interpolations are, but that's what normal mapping is there to hide by introducing additional, cheap detail. This means you can use a very coarse voxel grid, and still make it look good. The terrain vertex density for current games is absurdly low thanks to the ability of normal/parallax mapping to make a planar surface have depth.

Plenty of games don't use either "precomputed" terrain or voxel terrain. Take BF3 for example.[/quote]
Clearly the terrain is precomputed to some extent, to fit the requirements of the game (e.g. a flat space here and there to place a building). Obviously the finer details can be procedurally generated via any method to simplify the artist's work but ultimately there is still an artist behind each map. Of course games can use both, or neither techniques to generate and render their terrain, there is no law stating the opposite.

First you do hello world when you enter programming as a beginner, and then you do a chess program when you transition to intermediate level programming. This is how it was for me in college and voxel projects are analogous to chess programs in my eyes. It's probably the easiest project that you can take on that covers such a broad range of topics while also having a decent amount of complexity. I also firmly believe that everyone interested in game programming should do one when they get the basics of 3D down. If I were teaching a game programming class there definitely would be a voxel project in the syllabus.

http://publications....attlefield3.pdf

Clearly the terrain is precomputed to some extent, to fit the requirements of the game (e.g. a flat space here and there to place a building). Obviously the finer details can be procedurally generated via any method to simplify the artist's work but ultimately there is still an artist behind each map.[/quote]

Is it just me, or are you . . .

First you do hello world when you enter programming as a beginner, and then you do a chess program when you transition to intermediate level programming. This is how it was for me in college and voxel projects are analogous to chess programs in my eyes. It's probably the easiest project that you can take on that covers such a broad range of topics while also having a decent amount of complexity. I also firmly believe that everyone interested in game programming should do one when they get the basics of 3D down. If I were teaching a game programming class there definitely would be a voxel project in the syllabus.[/quote]

A decent game programmer should know how to import/export a variety of assets, including common formats, and custom/specialized data (maps, saving the game's state etc). A voxel project seems like a good reason to avoid that, and other essentials. Perhaps they can do that "to get the basics of 3d down," because I don't know how it could be considered much more. I mean, as a student project... like what you've made: http://blog.neumont....en/infinecraft/

That essentially is the bare "basics of 3D." I can't see much learning value in such a project. If the students were constructing much more sophisticated voxel projects, well, that would be a little too specific. It would be a good reason to neglect many other common skills used in real game programming. Even if dynamic/interpolated voxel terrain systems make a strong debut in a few future titles (I wouldn't doubt it), its likely they would remain too limiting, by a number of aspects, to be adopted by much of the full industry. It would be like a "parallax mapping" project. There are a few cases where it works well and adds some value, but in the most common implementations, it looks like shit.

Voxels are nice since their a bit like the 2d tiles of old and can help you create a 3d environment without having to get into 3d art.

Voxels are nice since their a bit like the 2d tiles of old and can help you create a 3d environment without having to get into 3d art.[/quote]

For any of us non artists voxels/cubes are nice in that they are sort of the equivalent to pixel art in 2D which means you can create something kinda consistent looking in 3D without being a 3D artists...[/quote]

At the cost of being blamed for cloning Minecraft by arrogant critics. Yes, they're very easy, and too easy, at that. Could somebody respond, in depth, to this: "Why do

you

want to, anyway?" Do you want to use them for a game? Of course, I'm not suggesting that its a waste of your time if you don't use them for a game, but could someone give me any more reason besides "Although the programming can be equally challenging, depending on my ambitions, I don't have to deal with traditional game development. I can just develop an easy pet project."

I would appreciate much more elaboration regarding your personal reasons. What do you plan to with your voxel project? What will it be like?

At the cost of being blamed for cloning Minecraft by arrogant critics. Yes, they're very easy, and too easy, at that. Could somebody respond, in depth, to this: "Why do you want to, anyway?" Do you want to use them for a game? Of course, I'm not suggesting that its a waste of your time if you don't use them for a game, but could someone give me any more reason besides "Although the programming can be equally challenging, depending on my ambitions, I don't have to deal with traditional game development. I can just develop an easy pet project."

I would appreciate much more elaboration regarding your personal reasons. What do you plan to with your voxel project? What will it be like?

Well, do you really need anymore reasoning than that? I worked on that voxel project for an introduction to 3D programming course and I learned about matrix transformation, noise functions, and a lot about shaders (among other things). I think that because "voxel projects" are so easy it makes them perfect to just explore tons of different methods and techniques without having to get your feet too wet. These things are so easy to get up and running that you can focus on the more fun and exciting stuff, like game play programming.

For me, I work on mine every few months just to explore and learn about different techniques that I've read or seen around. Instead of spending a lot of time making a 3d scene and getting it working, I could just load up my voxel terrain and implement whatever I'm interested in on top of it and voila, I've learned how to do deferred rendering and am much more motivated to do something cool with it, like add ambient occlusion or bloom and what have you. I think that this is why they are so popular, you can just get the basic skeleton done, and then it's like making a mod afterwards (at least for me).

Thank you M6dEEp!

A couple of days playing around... why wouldn't you?

http://publications....attlefield3.pdf

Clearly the terrain is precomputed to some extent, to fit the requirements of the game (e.g. a flat space here and there to place a building). Obviously the finer details can be procedurally generated via any method to simplify the artist's work but ultimately there is still an artist behind each map.

Is it just me, or are you . . .
[/quote]
What are you saying? Do I need to specifically state that in this context when I said "precomputed", I meant "not purely procedurally generated" a.k.a. "authored by an artist to some extent" (ref. FrostEd)?

I would appreciate much more elaboration regarding your personal reasons. What do you plan to with your voxel project? What will it be like?

See M6dEEps post . My "job" is in scientific computing and I just like to toy with game related stuff. With that background I don't really have problems with the complexity of 3d itself, but to make anything 3d you generally need some sort of "content". And since I'm not really interested in learning 3d modeling I need other means to create that "content" as a result anything I do in 3d tends to have a fairly abstract look to it. So it will only be spheres, splines, cubes etc.
I think there is nothing worse than writing a "3d engine" and then showing it off with a bunch of free assets collected around the internet. Even if the assets are high quality by themselves it will look inconsistent and patched together and totally distracts from the technical merit the project might have. So I prefer to use something like cubes or splines. Also depending on what you do exactly something as "simple" as a minecraftesque engine can be pretty challenging... you have to stream data to the gpu, generate chunks asynchronously etc. you are potentially constantly moving hundreds of MB of data and have to do so in a way that doesn't make it stutter or requires to display a loading screen. So for someone like me it's just a nice technical playground with kinda visible results.

I don't specifically write a game with the voxel/cube experiments I have done so far. But even if I did, it would not be minecraft (I actually don't find the "gameplay" of digging and building random stuff without real purpose that interesting ).

I have been doing 3D graphics programming as a hobby for around 10 years, though I haven't done anything with voxels. My work involves electromagnetic theory and modeling and I have used also finite-difference schemes to model propagation of optical electromagnetic waves. This "voxel" approach is useful, because the fixed cell size, depending on material properties, can lead to implicit time stepping, where only a diagonal matrix needs to be "inverted" at each step. In more geometrically general finite-element methods, matrices are not diagonal (even though they may be sparse) and this has significant computational cost. Although it is possible to locally refine the spatial representation of the fields in finite-difference schemes, it becomes really cumbersome. The same goes for attempting to represent curved material interfaces by either refining the starcasing or somehow "bending" the cells. So although the voxel approach seems at first glance simple and fast, it gets really tedious and ugly when you try to improve it to a level that would really cover the cases that you are interested in. The content creation approach works similarly here as in 3D graphics: it's really easy, in principle, to define a shape by just marking some cells as dielectric, metal, vacuum etc. Creating corresponding shapes with a 3D modeling software by using some n-simplices is more involved.

So a while ago I saw a video for a 4D puzzle game (Miegakure). I thought it was really neat, but it got me thinking... What would an actual 4D renderer look like? What's the best way to represent the fourth dimension? I thought about using 4D tetrahedral models, rendered with a shader to select the current 3D "slice", but that seemed too unwieldy. The most straight forward way, in my mind, was to take the "ray-casting 3D voxels" concept and just add a fourth dimension.

My program uses a 4D sparse voxel octree (I call it a hypertree) which acts exactly the way you'd expect: each dimension splits into two, which means that a node has up to 16 four dimension children volumes. I copied the ray casting algorithm from the Laine and Karras SVO paper (minus the contours), and added in an extra dimension to everything. To visualize the fourth dimension (W), I leave Z as up and down, but rotate the viewer's other three dimensions so that W replaces X or Y. Mathematically it works quite nicely, and doesn't look too bad.

One of the biggest issues that I had with it is that a 4D hypertree can get very big very quickly. Since every node can have 16 children, if I were to store all the leaf nodes I'd only be able to work with relatively shallow trees (e.g. at 4 bytes per node, seven levels is 1 GB). Since it's a sparse tree I don't store all this, but the potential is there. I also came up with two other solutions to this size problem. The first is to have portal nodes, which store a transformation matrix to teleport viewing rays, or object positions, from that node to some other node (and orientation). So even if the entire world is only 128 leaf nodes on a side, you can make larger environments by hijacking other (unused) dimensions seamlessly. The portal transformation does incur a performance hit though for every ray-portal intersection.

My second solution to the size problem is to not store unique geometry at the bottom of the tree. Using a palette of premade leaf node "tiles", you can give the environment more detail without having to store it all uniquely. Or at least that's how it would work... I haven't actually implemented this yet. I got the idea from watching that Unlimited Detail video, which looks like it uses a similar idea with 3D tiles nodes.

My other issue with a 4D renderer is that generating interesting content is difficult to do without an editor. I stopped working on it about the time I realized that I'd need to make an editor to get the full potential out of it as a concept. I'll probably pick it up again one of these days though.

So that's my experience with "voxels". If anyone wants me to go into more detail about anything I can, but I don't want to post the program right now.

I don't specifically write a game with the voxel/cube experiments I have done so far. But even if I did, it would not be minecraft (I actually don't find the "gameplay" of digging and building random stuff without real purpose that interesting ).

I personally have trouble calling it a game. It is more of a tech demo with various game play mechanics that people thought would be cool and then cobbled them together. A game is supposed to have a goal, which one can argue is the whole "survival and exploration" aspect, but in reality boredom ensues and you realize the game is only fun when you are really drunk and are playing with all of your really drunk friends.

I think that further validates my reasoning behind why people make these just to explore technical boundaries etc. That is almost what Minecraft seems like when you think about it.