Content: Slate Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate Marble
Background: Slate Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate Marble
Pattern: Blank Waves Notes Sharp Wood Rockface Leather Honey Vertical Triangles
Welcome to TerraFirmaCraft Forums

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

  • Announcements

    • Dries007

      ATTENTION Forum Database Breach   03/04/2019

      There has been a breach of our database. Please make sure you change your password (use a password manager, like Lastpass).
      If you used this password anywhere else, change that too! The passwords themselves are stored hashed, but may old accounts still had old, insecure (by today's standards) hashes from back when they where created. This means they can be "cracked" more easily. Other leaked information includes: email, IP, account name.
      I'm trying my best to find out more and keep everyone up to date. Discord (http://invite.gg/TerraFirmaCraft) is the best option for up to date news and questions. I'm sorry for this, but the damage has been done. All I can do is try to make sure it doesn't happen again.
    • Claycorp

      This forum is now READ ONLY!   01/20/2020

      As of this post and forever into the future this forum has been put into READ ONLY MODE. There will be no new posts! A replacement is coming SoonTM . If you wish to stay up-to-date on whats going on or post your content. Please use the Discord or Sub-Reddit until the new forums are running.

      Any questions or comments can be directed to Claycorp on either platform.
Balthizarlucien

Improving TFC Terrain Generation

31 posts in this topic

Improving TFC Terrain Generation

 

I personally, as most TFC players I am sure, love the way the terrain looks and feels as you wander through any world spawn but I get frustrated with chunk loading delays. After reviewing the source code and more specifically the terrain generation I noticed that the algorithms could use some work to improve the efficiency as well as the finer details of the terrain which don't quite match against nature. 

I happen to have been working on a procedural terrain generator that deals with all of these issues but it is being written in a different language for my own personal project so it is not directly applicable here. However, I figure I might describe the process I am using and Provide some Pseudocode so that Bioxx or whomever handles this aspect of TFC may be able to take some inspiration from it for either this incarnation of TFC or the currently under development TFC2. 

The best way to solve the terrain generation delay is to simply not have it happen in the first place. Sure, this is easier said than done I know but hear me out. The only way to avoid individual chunk generation delay is through a process of pre-generation. Instead of trying to generate the entire world, which would be nuts, simply generate the world 200x200 chunks at a time. I term this idea as a Super Chunk. This would increase generation time; but, it would be a significantly smaller amount of time than is spent trying to play whilst the game is already burdened with the task of terrain generation for each new chunk you load. Also, using a super-chunk would mean that while you are huddled in your hovel for the night or while you are staying within your already generated 10,240,000 block2 space and not generating new land the game can be generating the surrounding super-chunks with a passive, unobtrusive background function taking advantage of the downtimes in processing power.

Using a pre-generation method will allow for a load delay free exploration process but it is not the only way to increase efficiency as well as improve on the realistic appearance of the terrain. There are several other improvements which can be made to the way that the terrain generates by changing the specific algorithms used in the generation process itself. 

Ken Perlin created Perlin noise in 1983 because he was more than a little frustrated with the machinelike qualities found within computer graphics of the time and it was exceptionally effective for use within the film he had been working on at the time, Tron. This was a small and mostly obscure title I am sure no one has heard of, right? I can completely understand his feelings as I had similar feelings with them myself in the mid to late 90’s. Perlin noise has since become the benchmark for any form of procedural terrain or texture generation used within the industry since. 

Computational Theory Ahead! Warning!

This means Perlin noise scales with complexity to for dimensions. 

This seems fine for most applications because this function is still widely used within the industry even today. 

The pseudocode for this function is as follows:

 

// Function to linearly interpolate between a0 and a1

 // Weight w should be in the range [0.0, 1.0]

 function lerp(float a0, float a1, float w) {

  return (1.0 - w)*a0 + w*a1;

 }

 

 // Computes the dot product of the distance and gradient vectors.

 function dotGridGradient(int ix, int iy, float x, float y) {

 

  // Precomputed (or otherwise) gradient vectors at each grid point X,Y

  extern float Gradient[Y][X][2];

 

  // Compute the distance vector

  float dx = x - (double)ix;

  float dy = y - (double)iy;

 

  // Compute the dot-product

  return (dx*Gradient[iy][ix][0] + dy*Gradient[iy][ix][1]);

 }

 // Compute Perlin noise at coordinates x, y

 function perlin(float x, float y) {

 

  // Determine grid cell coordinates

  int x0 = (x > 0.0 ? (int)x : (int)x - 1);

  int x1 = x0 + 1;

  int y0 = (y > 0.0 ? (int)y : (int)y - 1);

  int y1 = y0 + 1;

 

  // Determine interpolation weights

  // Could also use higher order polynomial/s-curve here

  float sx = x - (double)x0;

  float sy = y - (double)y0;

 

  // Interpolate between grid point gradients

  float n0, n1, ix0, ix1, value;

  n0 = dotGridGradient(x0, y0, x, y);

  n1 = dotGridGradient(x1, y0, x, y);

  ix0 = lerp(n0, n1, sx);

  n0 = dotGridGradient(x0, y1, x, y);

  n1 = dotGridGradient(x1, y1, x, y);

  ix1 = lerp(n0, n1, sx);

  value = lerp(ix0, ix1, sy);

 

  return value;

 }

 

In 2001 Ken Perlin published a massive revision to this most classic system for noise generation that so pervades the industry. He called his new noise algorithm Simplex Noise because it made noise generation exceptionally more simple and significantly smaller computational overhead. For those who are not aware, Computational overhead is what causes computational delays in the first place. Now why isn’t tis used as the base for TFC’s Terrain generation? 

Computational Theory Ahead! Warning!

The computational cost of a simplex algorithm is significantly more efficient at for dimensions instead of the of classic noise. This means less pressure on the CPU or GPU for generating terrain and a much better looking product to boot due to the lack of Directional artifacts which are typically found in Perlin noise. (This would be those weird lines that I am sure we have all seen appear on the terrain and extend for a few chunks or more.)

The best article I have found comparing both Perlin's Classic and Simplex noise can be found here: http://webstaff.itn.liu.se/~stegu/simplexnoise/simplexnoise.pdf

Now that this explanation is out of the way let me explain the way in which my process works as I find the results to be quite breathtaking. When Minecraft (or TFC) generates terrain it calls on perlin noise in octaves to generate the terrain details in waves from the largest to the smallest pattern first. This is fine but as we know it is highly inefficient and in vanilla Minecraft it also yields poorly constructed or strange results. Also, because the terrain is using a 3d perlin noise function, you will always end up with those obnoxious flying islands because these are what is known as signature artifacts of the 3d noise process. 

To solve these issues we can simply change the algorithm it is using altogether and tailor it to a much more realistic system. Since we know that no landforms are ever going to appear flying we can deduce that we do not need to use a 3 dimensional  noise function. We can easily get away with a 2d noise function that creates our height data and yields none of those artifacts mentioned before. 

Because of the information we are now armed with we can also choose the correct noise function to improve efficiency and reduce the amount of processing required to obtain the same results. For this we simply choose the superior noise algorithm, Simplex Noise. Even simplex noise, implemented correctly, can get a bit repetitive and lack variety when it is repeated on ever increasingly smaller scales. on top of this, pure simplex noise is also unappealingly smooth, as is Perlin's classic noise at its base.

We need a way to rough up our noise field. No one likes overly smooth terrain. It looks far to fake and will yield terrible results in the end if we leave it be. For my own project I turned to a function which is perfectly suited for this specific task. It is called Fractional Brownian Motion. In science, Fractional Brownian Motion is a mathematical physics system which explains how small particles behave in relation to one another. 

An easy way to explain this is to imagine a dark room with a single ray of light. When you look into the ray of light you are able to see dust particles which, if left undisturbed by wind, seem to have a random pattern of motion. This random pattern is intact the result of the dust particles which we can see interacting with the molecules in the air which we are unable to see.

This can be simulated using a very simple algorithm:

//for each pixel, get the value

total = 0.0f;

frequency = 1.0f/(float)hgrid;

amplitude = gain;

             

for (i = 0; i < octaves; ++i)

{

        total += noise((float)x * frequency, (float)y * frequency) * amplitude;      

        frequency *= lacunarity;

        amplitude *= gain;

}

                     

//now that we have the value, put it in

map[x][y]=total;

This will turn the height map from this:

 

Posted Image

 

To this:

 

Posted Image

 

As you can see, there is a marked improvement in the height map as a result of the added motion function but it is still very raw and will not work well as a terrain map like this. As with the previous terrain generation used by the default Minecraft system we need to make some enhancements to the original height map before we add the motion so that we can create a much better overall terrain in general. 

The second major issue that makes the default Minecraft terrain slightly... Off. Instead of varying the algorithm used for the terrain generation the system simply calls the same function over again with a slightly reduced set of variables and passes over the terrain a second, third, fourth etc time until it's finished generating the terrain. This is fine as it does create the finer details required to make the terrain look less smooth and strange but the repeats are noticeable and to me this is unacceptable. Using a simple two stage for loop you can call the simplex noise and after it runs but before the loop finishes it calls a second noise function. But what function should be called and how much noise is enough? I think that this question needs some exploration but we can use some good old deduction to really dig into this and find a decent answer. 

So what truly determines the shape of the land, dirt or stone? Well, duh.. The stone obviously. The dirt is just the superficial skin covering the stone below. So is there a noise function that is designed to look like stone? Actually yes! The noise algorithm used for this is called Worley Noise.

Worley Noise was created in 1996 by Steven Worley to eliminate the need for artists from having to try and draw stone textures but since we are trying to generate a height map that is essentially the skeleton we will lay the skin on top of this fits the bill nicely. 

So to vary the noise and create a better base we simply need to cycle between Simplex and Worley noise using the same octave shifting as we would use on just the simplex noise. This will allow for the layering effect we need without worrying about the issues of visible repetition that currently haunts the terrain.

Minecraft runs what appears to be at least 8 cycles or "octaves" minimum but it's possible that it may cycle more. With our system we do not need quite so much to work with so we can do this with a nice even 4 octaves as that will be the same as 8 octaves of Minecraft's original noise generation except much better looking.

Now that the noise image has been generated and we have applied the Fractional Brownian Motion we have a data set that will work but it isn't complete yet by a long shot. Nature leaves her fingerprint on the earth and we should drive to achieve the same thing otherwise our terrain will just fall into the realm of sub par generation and our terrain will feel half done. 

Since we are shooting for realism in this terrain model we have been building we might as well speak bit on how rocks end up where they are. There is really only one question we need to answer whilst we determine what types of rock goes where in our world. where are we? the reason for this is simple. There are currently two major categories of crust we need to contend with as per geologists in the field. The first is Oceanic Crust. any of these expansive oceans we often find within TFC would be where we would need to generate what we will call Crust 1 Stone. the second major type of crust we need to know about is known as Continental Crust. This will appear in land masses which are larger than a set value (greater than 1000 blocks in diameter for example) and have what we will call Crust 2 Stone.

 

Crust 1

The Oceanic Crust is about 7-10Km thick and composed of mafic (magnesium and Iron rich) igneous rocks most commonly Basalt (pillow Lavas) and Gabbro. This is also laid out in layers instead of having been pushed around into a sort of noise. this makes the oceanic crust easy to simulate. No extra noise functions are required here. 

the layers are:

Basalt

Dacite / Andesite / Rhyolite vertical sheets (4-8 blocks wide alternating randomly)

Gabbro

 

Crust 2

As you can see from the image below, this is where we need to use some noise functions to make this work a bit better. For the noise model we can simply use the same simplex noise algorithm we used before but in 3 dimensions rather than 2. This will allow for a realistic blend of stone to appear underground as opposed to a layered appearance. One thing which needs some adjustment is simply an octave modified based on surface height. This will make the stone apear to bunch up as it approaches mountains just like you would expect in plate tectonics without all of the heavy overhead involved with modeling them.  

 

The stone which needs to be blended must be added into an existing base stone. knowing this and knowing granite is the most common stone found on earth we will use granite as our base medium but feed the other stone types in with each iteration of the noise function. below is the list of stone types with their percentages as per the earth’s own crust:

Granite 38%

Diorite 20%

Gabbro 15%

Slate 10%

Gneiss 6%

Schist 4%

Marble 3%

Phyllite 2%

Quartzite 2%

 

Posted Image

These figures are of course rough but will provide a fairly decent blend of rock in the ground in a pattern that is believable. now that the stone types are out of the way the dirt can be calculated for and laid out in the appropriate depths.

Real terrain is weathered. It's beaten and its worn down. Luckily these are very easy to mimic as well. There are two primary algorithms used to simulate erosion on height maps and they are implemented at varying strengths and implementations depending on the degree of erosion needed. We need to implement both types not only for the realism but also because we need to try and prevent any sort of processor delay we may experience whilst wandering our new landscape. I know it isn't much of a weight on the processor as we have already gotten the majority of the processing already done; but the gravity added by TFC is still something we can eliminate from new chunk loading so why not take care of it ahead of time as well?

The first erosion algorithm we need to implement will be thermal erosion. One would assume that this has something to do with heat but in fact it does not. It is a simulation of gravity which looks for cliff faces which are unrealistically smooth and wears them down. The way in which it does this is by looking for cliff faces which are greater than a predetermined angle (T) by comparing each block against its neighbor. to do this efficiently a rotated Von Neumann neighborhood should be used as it reduces a large portion of the processor load against the Moore Neighborhood but produces almost identical results in the end. If it finds such a cliff then it moves the soil in said cliff face one layer at a time down the cliff until the slope is less than T. 

 

In our 2 dimensional height map we have been building for our terrain we will predetermine that this angle should be 88° grade or steeper. This will prevent only the most shear of cliff faces from appearing but allow some of the more impressive cliffs to remain intact. This part of the erosion does not care what kind of stone is in the way so up until now we have not needed the data we have generated. the next segment however, does require this information to procede as does it require our surface soil layer and climate data otherwise we would not be able to properly apply the algorithm appropriately. For this we need to create our climate data, rock data etc. 

the only type of erosion that is left to apply is hydraulic. This type of erosion is very good at not only simulating water but wind as well because air is nothing more than a very thin fluid as it behaves almost exactly the same. Air motion is easily predictable because air will always move from cold locations to hot locations. The temperature system in TFC facilitates this by providing temperature data based on both elevation and latitude within the game. Using these facts we can easily generate a wind model like what is shown here http://earth.nullschool.net/#current/wind/surface/level/orthographic=202.50,11.03,446 that will be able to gently erode the terrain, carry sediments and deposit them in logical places. This type of erosion is typically gentle but it is widespread and highly directional which means that it will work to smooth out the roughness left behind from the original noise generation. 

This will lead to mountains with a smooth face on one side and a rough face on another. Wind is not the biggest fluid we need to contend with however. Erosion by water has carved some of the most spectacular things on our planet. Using the precipitation of each TFC zone we can accurately model the volume of water passing over the surface on a yearly basis and use this to carve out rivers, gullies, ravines etc as well as setup lakes, rivers, sedimentary beds and more. These beds will stick the right types of sedimentary stones near their associated igneous counterparts. 

included below is a hydraulic erosion program in a variation of C that I found online that may make a good reference point for you:

 

Hydraulic Erosion Filter

//recommended default values:

//iterations_ = 50

//threshold_ = 4096/heightmap size

var* TERRAIN_hydraulic_erosion_tmp=NULL;

///////////////////////////////

void TERRAIN_bmap_hydraulic_erosion_filter(BMAP* bmap_,var iterations_,var threshold_)

{

//get size

double size_x_=bmap_width(bmap_);

double size_y_=bmap_height(bmap_);

 

//create data

TERRAIN_hydraulic_erosion_tmp=(var*)sys_malloc(sizeof(var) * size_x_*size_y_);

 

//fill data with pixel color

int py; for(py=0;py<size_y_;py++)

{

int px; for(px=0;px<size_x_;px++)

{

COLOR color_;

var format=bmap_lock(bmap_,0);var alpha_;

var pixel=pixel_for_bmap(bmap_, px, py);

pixel_to_vec(color_,alpha_,format,pixel);

bmap_unlock(bmap_);

 

TERRAIN_hydraulic_erosion_tmp[px*size_x_+py]=color_.red;

}

}

 

int i; for(i=0;i<iterations_;i++)

{

int py; for(py=0;py<size_y_;py++)

{

int px; for(px=0;px<size_x_;px++)

{

var h_=TERRAIN_hydraulic_erosion_tmp[px*size_x_+py];

 

var d[4]; COLOR color_tmp_; var h[4];

 

h[0]=TERRAIN_hydraulic_erosion_tmp[clamp(px-1,0,size_x_-1)*size_x_+clamp(py,0,size_y_-1)];

h[1]=TERRAIN_hydraulic_erosion_tmp[clamp(px,0,size_x_-1)*size_x_+clamp(py-1,0,size_y_-1)];

h[2]=TERRAIN_hydraulic_erosion_tmp[clamp(px+1,0,size_x_-1)*size_x_+clamp(py,0,size_y_-1)];

h[3]=TERRAIN_hydraulic_erosion_tmp[clamp(px,0,size_x_-1)*size_x_+clamp(py+1,0,size_y_-1)];

 

var dtotal=0,dmax=0,l=0;

int j; for(j=0;j<4;j++)

{

d[j]=h_-h[j];

if(d[j]>dmax)

{

dmax=d[j];

l=j;

}

}

 

var hd;

if(dmax>0 && dmax<=threshold_)

{

hd=0.5*dmax;

h_=h_-hd;

h[l]=h[l]+hd;

}

 

TERRAIN_hydraulic_erosion_tmp[px*size_x_+py]=h_;

TERRAIN_hydraulic_erosion_tmp[clamp(px-1,0,size_x_-1)*size_x_+clamp(py,0,size_y_-1)]=h[0];

TERRAIN_hydraulic_erosion_tmp[clamp(px,0,size_x_-1)*size_x_+clamp(py-1,0,size_y_-1)]=h[1];

TERRAIN_hydraulic_erosion_tmp[clamp(px+1,0,size_x_-1)*size_x_+clamp(py,0,size_y_-1)]=h[2];

TERRAIN_hydraulic_erosion_tmp[clamp(px,0,size_x_-1)*size_x_+clamp(py+1,0,size_y_-1)]=h[3];

}

}

}

 

//fill pixels with array data

int py; for(py=0;py<size_y_;py++)

{

int px; for(px=0;px<size_x_;px++)

{

//set colors

COLOR bmp_color_;

bmp_color_.red=TERRAIN_hydraulic_erosion_tmp[px*size_x_+py];

bmp_color_.green=TERRAIN_hydraulic_erosion_tmp[px*size_x_+py];

bmp_color_.blue=TERRAIN_hydraulic_erosion_tmp[px*size_x_+py];

 

//add to heightmap

var format=bmap_lock(bmap_,0);

var pixel=pixel_for_vec(bmp_color_,100,format);

pixel_to_bmap(bmap_, px, py, pixel);

bmap_unlock(bmap_);

}

}

 

//free data

sys_free(TERRAIN_hydraulic_erosion_tmp);

}

 

Now that the erosion of the terrain is complete the world can be opened and used. although this took a very long time to explain, for this I am sorry, the world generation would actually take place significantly faster and may be only slightly longer for this system than your normal world gen.

If you made it through the entire post, Thank you! it took a long time and a lot of research to assemble and it took even longer to figure out how to explain it so I appreciate your diligence in reading it. 

Edited by Balthizarlucien
6

Share this post


Link to post
Share on other sites

I actually looked into this process for TFC2 a few weeks ago before I got my current system functioning. I definitely thank you for the working hydraulic erosion code though. It's actually kind of hard to find good code to learn from for erosion models.

That said, TFC1 won't be getting anymore overhauls. As for TFC2, I've settled on a system of preprocessing island maps. However I will be skipping erosion filters in favor of a more simplified terrain that can accommodate other features such as rivers and lakes of varying altitudes. If I wanted to have anything like a properly flowing river, the processing demands would be obscene without moving the algorithms to the GPU which is beyond the scope of this mod.

I will say that you're absolutely correct that the way in which MC currently handles terrain generation is ridiculous. Preprocessed sections are the future.

3

Share this post


Link to post
Share on other sites

I have advocated for finite worlds for a while now. Let me  choose the world size before hand, but generate the whole thing at world creation. That solve so many problems, and best of all will let us have real flowing water, with rivers, waterfalls and lakes at different heights. thank you Bioxx for taking this into consideration.

1

Share this post


Link to post
Share on other sites

If we make the world finite, is the any way to make the world loop back at its edges?

0

Share this post


Link to post
Share on other sites

I actually looked into this process for TFC2 a few weeks ago before I got my current system functioning. I definitely thank you for the working hydraulic erosion code though. It's actually kind of hard to find good code to learn from for erosion models.That said, TFC1 won't be getting anymore overhauls. As for TFC2, I've settled on a system of preprocessing island maps. However I will be skipping erosion filters in favor of a more simplified terrain that can accommodate other features such as rivers and lakes of varying altitudes. If I wanted to have anything like a properly flowing river, the processing demands would be obscene without moving the algorithms to the GPU which is beyond the scope of this mod.I will say that you're absolutely correct that the way in which MC currently handles terrain generation is ridiculous. Preprocessed sections are the future.

I figured that TFC1 was essentially done with large changes. It is good to hear that you have gotten a functional system working for TFC2 though. As for the hydraulic algorithm, not a problem at all Bioxx, I'm glad it was of interestSo from one programmer to another, are you using Simplex noise as your noise engine in TFC2 or did you settle on a different noise engine? The sad part about terrain handling in general when it comes to the sandbox genre is the fact that a majority of titles do in fact still rely on perlin noise and a vast majority also try to run from live load concepts which I think is worse than the use of perlin noise because perlin can be dealt with quite easily if you don't have to worry about live loading lol.Preprocessing sections and using cubic chunks are both far superior to the way Minecraft handles terrain right now but we work with what we've got ehh? Lol.Bioxx, I just had an idea if you wanted to consider it for climate modeling in TFC2.... You could rework that hydraulic erosion code and use it to model world temperature and precipitation a bit easier :) Instead of having it erode the physical blocks you could have it "erode" the precipitation and temperature values and "deposit" them naturally in areas which would see the weather carry warm air and rain with it. I have said this before but I will say it again... I am more than happy to act as a second (or third or fourth lol) set of eyes for code debugging or anything else you need. Just let me know :)
0

Share this post


Link to post
Share on other sites

I have advocated for finite worlds for a while now. Let me choose the world size before hand, but generate the whole thing at world creation. That solve so many problems, and best of all will let us have real flowing water, with rivers, waterfalls and lakes at different heights. thank you Bioxx for taking this into consideration.

Finite worlds aren't really what will fix it, nor are they specifically a limiting factor to the type of finite water model you are describing. As both Bioxx and I said, preprocessed segments akin to a "super chunk" would allow for what you are talking about but Bioxx made a good point regarding the way Minecraft in particular handles processing.In order to achieve what I personally would like to see and I'm sure Bioxx would like to see as well, the algorithms needed to run it really should be moved to the GPU instead of further taxing the already taxed CPU but Bioxx is also very correct in saying that this is outside of the scope of this mod.To achieve real progress with terrain gen and environmental modeling would essentially require a massive rewrite of most of this part of the Minecraft source and that just ain't happening lol. Although Minecraft in general needs a massive rewrite anyway lol it's code makes me shutter and gives me nightmares whenever I think about it!
0

Share this post


Link to post
Share on other sites

If we make the world finite, is the any way to make the world loop back at its edges?

Yes this is definitely doable but it really isn't a good idea having a finite world unless you somehow setup a realistically sized planet like map and loop it at that scale. If you did this sort of thing on a smaller scale you would run out of certain resources, have no way to encounter those animals and plants which don't spawn in your biome etc. If you are going to loop a map at planet size you might as well just not even bother looping it at all.
0

Share this post


Link to post
Share on other sites

You mentioned cubic cunks.  I imagine this would be compatible with your method terrain generation, which could allow for much greater altitudes than the pathetic max height of 256 blocks, no?  It would be nice to have mountains even a tenth of the scale of real ones in this game...In any case, this is flippin' awesome and educational!

1

Share this post


Link to post
Share on other sites

If we could have 1000 blocks total from bedrock to sky limit, I believe it would be enough.

1

Share this post


Link to post
Share on other sites

You mentioned cubic cunks. I imagine this would be compatible with your method terrain generation, which could allow for much greater altitudes than the pathetic max height of 256 blocks, no? It would be nice to have mountains even a tenth of the scale of real ones in this game...In any case, this is flippin' awesome and educational!

I am glad you enjoyed it :) in answer to your question, it would take exactly the same amount of time to generate the height data and apply the erosion. It might be better using this method than trying to use the normal 3d methods currently implemented because again the only place land would be where it belongs, on the ground lol
0

Share this post


Link to post
Share on other sites

Placing land on the ground? So radical.Have you heard of Realistic World Generation by ted80? It behaves somewhat-similarly (or appears to, at least form a user prospective). It also has a Github

I reviewed the source and unfortunately it doesn't appear to work at all like my plan does. It still uses 3d perlin Classic noise and has no erosion filters at all. What it has is a series of what appear to be multi block structures for terrain features like sand dunes. It is nice someone has taken the effort of trying to populate the terrain realistically but it is still stuck in the pre 2001 era of generation :(
0

Share this post


Link to post
Share on other sites

If we could have 1000 blocks total from bedrock to sky limit, I believe it would be enough.

If we were using truly cubic chunks height and depth would be as "infinite" as the rest of the world. Minecraft's current physical limit on its terrain generation is a world that is +-30,000,000 blocks in both the x and y (z?) axis. This means that it would be feasible to have the same division starting at ocean level and extending the equivelent distance up and down. The nice thing is that we do not have to. We can make a few assumptions regarding a decent world size to limit to by again using the information of earth.To present this I will do some conversions for you :)Humans have physical limits of survival as the infographic shown on http://m.livescience.com/34128-limits-human-survival.htmlTo summarize our limits in terms of height and depth is fairly easy.The crust heats by one degree Fahrenheit per 70 feet of depth. Assuming we are not talking about situations that would kill us in 10 minutes we can dig to a maximum depth of 733 blocks deep before we will begin suffering from the onset of heat stroke. We can climb without supplemental oxygen to to a maximum altitude of about 658 blocks. Knowing this we can set our limits slightly above and below these limits to values divisible to increments of 16 for the cubic chunk design.World size for cubic chunksMaximum depth: 736 blocks deep ( 46 cubic chunks)Maximum height: 3072 blocks high (192 cubic chunks) (edited due to calculation error... durr lol)This means the world will generate in super chunks that are 200 x 200 x 238 chunks per super chunk. This would still generate exceptionally fast with my system and result in a world in which steve can survive at the edges of.

Edited by Balthizarlucien
0

Share this post


Link to post
Share on other sites

Balthizarlucien, you should probably talk to Cuchaz and possibly suggest ideas (or directly contribute) that could improve the efficiency of cubic chunks

 

If TFC2 goes cubic chunks, it will probably be based on the Tall Worlds mod considering both Bioxx and dunkleosteus said re-writing the engine was too much work for cubic chunks

 

http://www.cuchazinteractive.com/tall-worlds/

 

http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/wip-mods/1446302-tall-worlds-mod-raising-the-world-height-cap

 

As a warning the Tall Worlds mod hasn't been optimized and currently has a gigantic memory leak, so you need at least 4 GB RAM  to test anything

Edited by Palisight
0

Share this post


Link to post
Share on other sites

[...]We can climb without supplemental oxygen to to a maximum altitude of about 658 blocks.[...]

658 blocks? that would be 658m or less than 2200ft - isn't that a bit low?conversion error? or am I misunderstanding it at all? Edited by CHeuberger
0

Share this post


Link to post
Share on other sites

658 blocks? that would be 658m or less than 2200ft - isn't that a bit low?conversion error? or am I misunderstanding it at all?

 

This was a conversion error, yes :( sorry I will edit the post accordingly.

0

Share this post


Link to post
Share on other sites

Hmmm something is still off about the maximum height you claim one can survive.  At least in that article, a height of 4,572 meters is the maximum altitude from sea level an average person can be at without passing out due to lack of atmospheric oxygen, with an absolute maximum of 7925 meters as the height anyone would die from suffocation.  Would that not translate to 4,572 blocks and 7925 blocks respectively?  That said, for what it is worth, I am a wimp and am at a town not too far above sea level, and I have been up to around 3000 meters above sea level without supplemental oxygen.  I could DEFINITELY feel the lower concentration of oxygen and was fatigued as hell by the time I reached the peak of the mountain I was on, but I think anyone with decent physical fitness could exist nicely at 3072 meters (the maximum height you mentioned).Maximum depth... your calculation seems ok, but I wonder...  Think about caves near the earth's surface; at least in the limestone caves I have been in, they are considerably cooler than room temperature if you go a little bit in them. even at the peak of summertime the temperature at the entrance can be around 15 to 16 degrees C.  That could bump up the maximum depth, no?So I would change the calculation for a super chunk to at least 200 x 200 x 348 to account for at least the increased maximum height.

Edited by Andeerz
0

Share this post


Link to post
Share on other sites

Hmmm something is still off about the maximum height you claim one can survive. At least in that article, a height of 4,572 meters is the maximum altitude from sea level an average person can be at without passing out due to lack of atmospheric oxygen, with an absolute maximum of 7925 meters as the height anyone would die from suffocation. Would that not translate to 4,572 blocks and 7925 blocks respectively? That said, for what it is worth, I am a wimp and am at a town not too far above sea level, and I have been up to around 3000 meters above sea level without supplemental oxygen. I could DEFINITELY feel the lower concentration of oxygen and was fatigued as hell by the time I reached the peak of the mountain I was on, but I think anyone with decent physical fitness could exist nicely at 3072 meters (the maximum height you mentioned).Maximum depth... your calculation seems ok, but I wonder... Think about caves near the earth's surface; at least in the limestone caves I have been in, they are considerably cooler than room temperature if you go a little bit in them. even at the peak of summertime the temperature at the entrance can be around 15 to 16 degrees C. That could bump up the maximum depth, no?So I would change the calculation for a super chunk to at least 200 x 200 x 348 to account for at least the increased maximum height.

According to nasa's study on LONG TERM survivability of humans under depreciated oxygen levels a human can live at 10,000 feet indefinitely. This was the figure I used so I know it is a bit off from the graph but I was assuming that it would be best to avoid trying to include acclimatization factors into the game as that would be a whole other ball of wax...I did take some assumptive liberty with these numbers for the simple fact of avoiding complicated code integration. You are right though in assuming humans are able to survive higher and lower altitudes than what I listed. I probably could simply find the highest constantly inhabited point on earth and use that as a reference too.The original point of the post though was less about the size of the land and rather about how to improve the overall process of generating it.So to deal with the height issue, the highest inhabited location on earth is 5100 meters above sea level which is 319 chunks. Edited by Balthizarlucien
0

Share this post


Link to post
Share on other sites

well, 3000m, aka 3000 block is still low... private pilots are allowed up to 4000m without oxygen, or up to 30 minutes above 3600m (Germany). And that does not mean that you will pass out above that, it is more that above that height they COULD suffer some issues, like decreased concentration.

On the other side, it is just a game, must not be exactly like real life [:-)

0

Share this post


Link to post
Share on other sites

Regardless, with cubic chunks, it wouldn't be much of an issue to make height of super chunks configurable.  :3  And, like what Balthazarlucien said, this thread is about how to improve the overall process of generating terrain.

0

Share this post


Link to post
Share on other sites

Honestly, If we had 1000 blocks above sea level and 500 below in my opinion is plenty of room for all the different landscapes. Yeah with more height we could have a more realistic thing, more based on earth. For game-play purposes, I really do not think is needed.

I am concern also with the file sizes, granted that in most places all that height would be just air, so it does not increase file size, but right now I have some servers with 10 GB world file size. It's a pain to back up. 

That's why I thought, OK right now we have 256 blocks total, so if we could just have 1024 total it would be such an improvement. Can you imagine?

Some big oceans would go as deep as 200 blocks and still have 56 blocks under it. You would be walking and see a 700 blocks tall Mountain.

The only situation where I can see having more Height would be beneficial is to better work the climate, so we could have a better analogy between real life altitude effects on the temperature and in game. 

BTW I know I said different numbers, I am just throwing them there. It's not a real suggestion. 

Edited by Djakuta
1

Share this post


Link to post
Share on other sites

I think worlds need to be pre-generated. My idea is...

 

1. Generate a 1024x heightmap by the means of a plate tectonic generator. Scale is 1:512. I don't know how, but I'm pretty convinced that the data on the movement of plates(fractures, ridges, faults, collisions etc.) can be used to generate rock types, volcanic activeness, etc.

2. Generate global weather map (temp, rain, drain, wind, etc.) for 12 months.

3. Pinpoint the player's spawn on land. This almost guarantees the player to have enough land resource for himself if it's an island.

4. Generate the region and neighbors' terrain, adjusting to weather and rock type. Generate the month's weather map, influenced by global weather and terrain. Populate the terrain.

5. Spawn the player.

6. Generate other region as the server idles.

 

I am aware that point 1, 2, and 4 will take a long time to process(and to code), but the resulting terrain will pay out, I think. But then, TFC is getting a rewrite, so why should we hold back? The small-scale generation stays the same, unfortunately, unless Balthizar's idea makes it too.

0

Share this post


Link to post
Share on other sites

I think worlds need to be pre-generated. My idea is...1. Generate a 1024x heightmap by the means of a plate tectonic generator. Scale is 1:512. I don't know how, but I'm pretty convinced that the data on the movement of plates(fractures, ridges, faults, collisions etc.) can be used to generate rock types, volcanic activeness, etc.2. Generate global weather map (temp, rain, drain, wind, etc.) for 12 months.3. Pinpoint the player's spawn on land. This almost guarantees the player to have enough land resource for himself if it's an island.4. Generate the region and neighbors' terrain, adjusting to weather and rock type. Generate the month's weather map, influenced by global weather and terrain. Populate the terrain.5. Spawn the player.6. Generate other region as the server idles.I am aware that point 1, 2, and 4 will take a long time to process(and to code), but the resulting terrain will pay out, I think. But then, TFC is getting a rewrite, so why should we hold back? The small-scale generation stays the same, unfortunately, unless Balthizar's idea makes it too.

Your concept is very ambitious. In order to have a plate tectonics system function properly there is no question you would need one hell of a beefy computer and a few hours of your time to waste whilst your map generates. You are right though, in such a system the terrain would be amazing.Let me explain why I think this would be exceptionally difficult to implement:To properly model plate tectonics you cannot just say "x is a plate and so is y. Where they collide you will get mountains" because honestly that would look terrible. Modeling plate tectonics has to consider a large number of variables:-Thermal convection currents from the planetary core to the surface.-Density of crust for any encroaching plates-Subduction melting rate-hydration of crust which contacts mantle- speed of each plate as well as direction- plate thickness-stone types formed based on specific conditions within volcanic regionsThis list is significantly longer but I am sure you get the point. It is going to generate absolutely stunning maps but it will take forever to generate initially and forget about including live updated tectonics because that along would crash the game because you are going to be well past the comfort point of the Java virtual machine. I agree that this type of terrain is doable as well. I could write the full terrain generator with all factors accounted for and the code cleaned and compacted in about 2-3 months by myself but it would be a behemoth project.One very important fact I learned whilst in college earning my bachelors degree fits this scenario perfectly: you do not need to make it really work. You just need to make the user think it works.In other words, trick the player into believing that your ai is very smart when in fact you used some very basic coding to make it act like it's smart.
0

Share this post


Link to post
Share on other sites

This whole topic reminds me of Dwarf Fortress, that world gen is super intense. (but its limited in size)

Edited by Dries007
1

Share this post


Link to post
Share on other sites