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!

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.