Unless you have theorized something to add to whatever has been done before (I doubt), I recommend you don't start yet another voxel project so vaguely and senselessly.
Discuss:
Why do you want to, anyway? Do you even know how to render anything decently credible, using traditional methods?
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?
If you plan to work with voxels, or already have (preferably), in which kind of way?
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
Sole Creator of Pigment - a procedural, block-base space trading sim.
PhD student working on medical imaging at the University of Southampton.
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.
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..)
“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”
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.
“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”
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.
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.
). 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).
