JTippets, thanks for that answer. It goes a bit beyond what I'm trying to make sense of right now, however I appreciate the details.
I do not have a well rounded mathematical education. This I cannot change. I have to work with what I have, in order to achieve my goal, there's simply no other way. I cannot go back to university in order to do what I"m trying to do... I have to learn on my own with what i"ve got.
I've only got about a year and a half of college education myself, so it's not really a matter of formal education. You're on the right track by asking questions.
Having said that, I understand generally what you are saying, and it's making sense to me in a general sense. Once I get past the current problem I am having, I believe that playing with these functions in some type of pre-made terrain generator, may assist me in figuring out what types of noise functions can produce various end results.
Yes, seeing it in action would certainly help.
The part where you talk about the Sky/Ground and how we are talking simply about values of density between -1 and 1 then in terms of starting with a normal 2D heighmap makes sense to me.
Although even that, is tripping me up right now. I know that the volume data is a Matrix of values [x,y,z] The marching cubes algorithm takes this data, and then uses it to generate the mesh.
If the volume data was all 1's or all -1's should this produce a CUBE then for that region of "space"? and a volume data matrix of all values of zero, would be blank space?
Well, it depends actually. If you just consider the values filling the volume data chunk in isolation then, yes, filling with a single value might produce a cube. Or it might produce nothing at all. It all depends on what you assume cells outside the volume to be. If you assume them to be 1, and you fill the chunk with 1, then no mesh will be produced. If you assume them to be 1 and fill the volume with 0, then you will generate a cube.
When dealing with voxel values in isolation like this, you have to pay particular attention to those out-of-bounds cells. Either you need to somehow track the cells that lie in neighboring regions, or you need to generate your voxel values deterministically using a function (such as Perlin noise) so that you can determine the value of an out-of-bounds neighbor cell by evaluating the function. This is the key if you want chunks to seamlessly connect with their neighbors; if all chunks are generated from the same continuous function then they should seamlessly connect. Otherwise you have to do a lot of weird stuff to wire them all up and get them to fit.
If you remove the noise entirely, shouldn't you be able to lets say fill the matrix with half 1's and half 0's and get Half a cube?
Yes. In fact, this is exactly what the linear gradient + select function will do if you orient the gradient along the line segment (0,-1,0)->(0,1,0) and use a threshold of 0, then map a volume of the function from (-1,-1,-1) to (1,1,1) into your voxel buffer. The 0 threshold will split the (-1,1) Y domain in half, placing the ground threshold in the center of the voxel chunk.
I want to make sure I understand the volume data and what it's meant to represent, just to make sure I didn't have a faulty premise on what the volume data is suppose to represent.
The volume data represents density. A value of 0 means 0 density (ie, nothing) while a value of 1 means full density (ie, solid). In this application we use either-or; instead of having a range of densities, we have either solid or open. This is why the select function is necessary. It converts the linear gradient (which has gradually increasing densities as Y increases) to a solid/open function defined at a threshold.
To map the data, you simply iterate across your voxel chunk and for each voxel you calculate the coordinates to feed to your generator function, evaluate the function at that point and assign the return value to the voxel.
Applications that make use of different terrain types (such as mentioned in the follow up to my initial article) will veer away from the simple solid/open abstraction and assign different values of the density function that evaluate to greater than 0 to different types of terrain. In this case, it's a matter of evaluating the gradient function (without the select function), then comparing the output value by hand to certain arbitrarily chosen thresholds to determine open, sand, dirt, stone, iron, etc... Of course, this aspect of it can get relatively complex since for things such as iron veins you typically have to introduce "branches" to your generation function. It can get kind of complex.