If we're going to tackle voxels, we need to talk about them a bit first. This series will initially focus on cubic voxels, so think of them in terms of Minecraft blocks (which were inspired by Infiniminer).
In the beginning...
I am going to go ahead and tackle making a tutorial about generating cubic voxels. I am going to use this initial post to explain what voxels are, and kind of give some ideas of what considerations are likely to come into play in the coming tutorial. I will also share a bunch of resources for those of you that would rather walk your own path and dive head long into voxels. Over the years I have researched the topic quite extensively so I will share that information at the end of this post as well.
Also... I have DONE this before... several times. Here are some screenshots from some of my adventures. :) NOTE: Many of the images show ramps and what I called multi-voxels. We won't likely get into those unless this tutorial generates quite a bit of interest. I won't say NEVER though, it could happen. The stairs in the bottom image are built from multi-voxels as well. (essentially being able to define any size and textured voxel cubes within the confines of a single voxel cell.) The ramps are accomplished by pulling the vertices of the edge you need to slope down downwards.
The voxel world in most of these images is built with a 64x64x1 chunk size as I intended to zoom down through layers. The water in the images is using the technique I intend for transparent cubes number two discussed below.
What is a voxel?
A voxel in the simplest terms is a volumetric pixel. A pixel is the individual dot on your screen that can take on the trait of colors of various intensities. That is it's only changeable quality.
A voxel system takes an area and breaks it into a grid. This can be 2 or 3 dimensional and still be a voxel. Essentially, what we are doing is breaking an area into our own type of pixels.
However, since we control what appears inside of these pixels we could simply do color like a normal pixel yet there is not reason to do just that. We can already accomplish that with pixels.
So why would we use voxels? Voxels are us essentially defining our own grid. We determine what type of information is displayed inside of that grid location. I usually call these a CELL like a cell on a spreadsheet.
In fact you could visualize an array as being a voxel if you were going to display it's contents. What if I were to say I had a voxel grid 3x3 where every cell could be an uppercase letter of the alphabet. That would define my voxels.
|A|B|C|
|D|E|F|
|G|H|I|
You could take that further and also allow those letters to have a color. That would be a two dimensional voxel. it need not be simply letters it could be shapes or anything of that nature. In reality, tile systems for rogue likes and other games could be considered to be using a voxel system. People don't typically think of it that way, but in reality a tile system using fixed sized tiles is actually a voxel as well. The shapes and types of tiles for each cell are simply the representations allowed for those voxels (like a pixels color).
Source: www.youtube.com - example of 2D Voxels
Minecraft takes this and predominantly uses 3D blocks. Notch was inspired by Infiniminer when he took that approach.
Source: alternativeto.net - Infiniminer - existed before Minecraft.
Basically the basic Minecraft block (there are more complex versions) would be a 3D cube with the information about that cube being what texture, and what light intensity to apply to the texture. That is the equivalent of a pixel in Minecraft terms.
This can be much more complex though. You can go for the Marching Cubes, or the Marching Tetrahedron algorithms and define most shapes using voxels. This is actually a popular approach for some terrain.
Source: users.polytech.unice.fr - Marching Cubes algorithm cell possibilities.
Source: gamedev.stackexchange.com - marching cubes with normal vector set for smoothing.
What we are going to do...
We are going to initially focus just on cubes. Depending upon how popular the tutorials are I may decide to go beyond cubes after that.
We are going to have three types of cubes:
1: Solid cubes - cannot see through
Source: vizpainter.com
2: Transparent cubes - using a transparent texture where edges matter always
Source: stackoverflow.com
3: Transparent cubes - using transparent textures where we do not show inner edges when joining up to a cube of the same type.
Source: www.realflowforum.com
We are going to build the texture atlas for the cubes on the fly at runtime. This will make it easy to retexture at will, without needing to painstakingly rebuild the atlas. This will make it easy for us to extend and change our approach to textures at a later time if we want.
Support destroying and creating cubes.
Support a chunking system.
Eventually use perlin or other noise functions to generate maps.
Cubes will support all sides having a different texture if desired.
Cube rotation in terms of facing direction in 90 degree increments.
We will use Unity lighting, and collision which CAN impact performance. Optimizing and using extra threads is much more complex and will only be approached if the interest warrants doing such.
If the interest remains strong we'll work on implementing an infinite map (or at least as infinite as Minecraft and others). The infinite aspect will be limited by constraints within floating point math.
We will likely use simplex noise rather than perlin, as simplex was also created by Ken Perlin and was created to be a little faster and solve some issues with perlin noise.
Layout
Every cube will be built of 24 vertices. Four per side. We will refer to sides in the order of Front, Right, Back, Left, Top, Bottom.
Source: www.ctralie.com
Source: I actually made this one and used it for my cheat sheet last time I was making voxels
There are actually only 8 unique vertices in a cube, but the way that meshes are built you end up naming them several times and it totals to 24. There are exceptions to this, but they will not be relevant to this project.
This is important to know because we do not want our meshes to go over 65,000 vertices as that can cause some issues with the 3D objects. We need to keep track of that when determining our chunk size.
What is a Chunk?
A chunk is a group of voxel cells. To increase performance it is better to build multiple voxels into a single mesh rather than do a single mesh for each voxel. The performance is greatly improved.
Source: bytebash.com
We therefore need to use some math to decide how big our voxels are going to be. We also can decide the shape.
32x32x1 x 24 vertices (worst case scenario) = 24576 vertices.
32x32x2 x 24 vertices= 49152 vertices.
33x33x2 x 24 vertices= 52272 vertices. (NOTE: Some people recommend sticking with powers of 2 sizes so you can take advantage of bit shifting and other mathematical optimizations... in which case this one would not be ideal. However, it does have a neat side effect of it having an absolute center block which power of 2 chunks do not.)
16x16x8 x 24 vertices = 49152 vertices
17x17x9 x 24 vertices = 62424 vertices
I likely would try out that bottom one in this case because I like the idea of there being a center to the mass.
NOTE: This does not take into consideration optimizations we will do.
When possible we will not be building non-visible sides. The only one that might always show all sides is the transparent version 1. If you built a chunk completely out of such cubes then all vertices could theoretically exist. We therefore should plan for that case. You can make a more complex setup that can use tricks to exceed the 65000 vertice limit but that is beyond the scope of this tutorial series. That would essentially spawn off additional meshes each time the 65000 vertice barrier limit was approached.
So you are interested in voxels?
If you like the idea of voxels (and so do I) there is a ton of really good information on the internet related to voxels. It is not all Unity related, and a lot of it is theoretical and language agnostic. If you like the subject here are a bunch of my resources I have collected over the years on this subject.
UNITY FORUMS: After Playing minecraft... - a thread spanning 5 years and growing. Some commercial success stories were born in this thread. It started as people using Unity wanting to make Minecraft like things in Unity. It documents their experiences, and their techniques. It is truly massive, but if you are truly passionate about this topic it is worth reading this one from start to finish. This is especially true if you are using Unity.
Here are a few images from that thread that spans 5 years...
Many of the older images are missing from the forums and Unity has updated their forums and many images that used to show as embedded now show only as attachments. :(
Unity voxel block tutorial - AlexStv - might be one of the people from the After Playing Minecraft... thread.
Build Minecraft in Unity Part 1 - I have not looked at this tutorial... only listing it for completeness. I don't know how good it is.
.. part 2 of the build minecraft tutorial - though he does use a primitive I have not seen before called a quad... that might be interesting.
.. part 3 of the build minecraft tutorial
.. part 4 of the build minecraft tutorial - I would expect this to be pretty poor performance wise as all cubes are individual objects instead of combined meshes, which usually has a big performance hit.
Understanding Perlin Noise
Simplex Noise in Unity C# tutorial
Marching Cubes Wikipedia Page
Marching Tetrahedra - mainly existed due to the patent of the cubes algorithm which is now expired.
Polygonising a scalar field - Marching Cubes implementation by Paul Bourke - 1994
Matt's Webcorner - Marching Cubes - nice page on marching cubes.
Gamedev.net article on Generating Worlds like Minecraft
Let's Make a Voxel Engine
Accidental Noise Library
Polygonal Map Generation for Games from Red Blob Games - stanford.edu
Marching Squares - Unity Marching Squares - 2D voxels.
Making Worlds
CoreDev Unity Voxel Engine Development Blog
Block Engine Demystified - Block story was born in the After Playing Minecraft... thread. However, this is a cool tutorial covering how they implemented it.
.. part 2 ... block story... cool optimization tricks
.. part 3 ... block story... multiples of 16 chunk size
.. part 4 ... block story
Here is a youtube video of Minecraft vs Block Story
Block Story was born in that After Playing Minecraft thread... It should be noted most if not ALL of those monsters and such in Block Story are for sale on the Unity Asset store. I know because, I own a lot of them. :)
Voxel Resources & Engines for Unity
.. part 6 ... block story
.. part 7 ... block story ... terrain generation
.. part 7 ... block story
The Marching Cubes Algorithm
Original Marching Cubes Patent - the patent for marching cubes which is now expired and free to use.
Generating Faces for Marching Cubes - Reddit thread. If you are going for marching cubes this is something I bookmarked.
There is more than that... a lot more... just the tip of a very large iceberg...
On the commercial side of things check out the videos and articles in this blog. procworld.blogspot.com
Closing
If you like this tutorial and want to support the continuation of this series please up vote for the topic. I will continue working on this series as long as the interest remains to warrant it. Tutorials of this nature take a lot of time and effort, so I do want to make sure I am working on things that are of interest with my time if possible.
Steem On!
Aw man, nice. I really want to implement similar in Unreal. Like a quadsphere with voronoi based voxels - and some erosion/deformation tweaks. (Mainly for modelling scientifically accurate exoplanets) - generating meshes in Unreal Macros and C++ isn't exactly intuitive though.
Keep it up!
Utilization of this info is beyond my abilities, but I want to support these tutorials and any collaborative projects that result! ReSteem'd & Followed.
I'm interested in doing something. Can invite you to #thegame if you're interested too. :)
Not sure what that is. Always interested in checking out new things, though.