From 5fb06e21903ff55852bbfe25034aecce52be7f82 Mon Sep 17 00:00:00 2001 From: madmaxoft Date: Wed, 4 Jun 2014 23:04:17 +0200 Subject: docs/Generator: Added the TerrainHeight section. --- docs/Generator.html | 54 +++++++++++++++++++++++++++++++++++++++++++ docs/img/biomalheights.jpg | Bin 0 -> 77747 bytes docs/img/biomeheights.jpg | Bin 0 -> 16432 bytes docs/img/biomeheightsavg.jpg | Bin 0 -> 14946 bytes 4 files changed, 54 insertions(+) create mode 100644 docs/img/biomalheights.jpg create mode 100644 docs/img/biomeheights.jpg create mode 100644 docs/img/biomeheightsavg.jpg (limited to 'docs') diff --git a/docs/Generator.html b/docs/Generator.html index f6e7f1cd9..282e4c412 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -19,6 +19,7 @@ with specific implementation notes regarding MCServer.

  • Terrain height
  • Terrain composition
  • Finishers
    • +
  • Making it all faster

    • @@ -304,16 +305,69 @@ using the same approach as in MultiStepMap - by using a thresholded 2D Perlin no

    Terrain height

     +

    As with biomes, the easiest way to generate terrain height is not generating at all - assigning a constant +height value to all columns. This is again useful either for internal tests, and for worlds like MineCraft's +Flat world.

    + +

    For a somewhat more realistic landscape, we will employ the good old 2D Perlin noise. We can use it +directly as a heightmap - each value we get from the noise is stretched into the desired range (usually from +40 to 120 blocks for regular MineCraft worlds) and used as the height value. However, this doesn't play too +well with the biomes we've just generated. If the biome says "ocean" and the Perlin noise says "mountain", +the end result will be unpleasant.

    + +

    So we want a height generator that is biome-aware. The easiest way of doing this is to have a separate +generator for each biome. Simply use the biome map to select which generator to use, then ask the appropriate +generator for the height value. Again, this doesn't work too well - imagine an ExtremeHills biome right next +to an Ocean biome. If no extra care is taken, the border between these two will be a high wall. The following +image shows a 2D representation (for simplification purposes) of the problem:

    + + +

    This requires some further processing. What we need is for the terrain height to be dependent not only on +the immediate biome for that column, but also on the close surroundings of the column. This is exactly the +kind of task that averaging is designed for. If we take the area of 9x9 biomes centered around the queried +column, generate height for each of the biomes therein, sum them up and divide by 81 (the number of biomes +summed), we will be effectively making a 9-long running average over the terrain, and all the borders will +suddenly become smooth. The following image shows the situation from the previous paragraph after applying +the averaging process:

    + + +

    The approach used in MCServer's Biomal generator is based on this idea, with two slight modifications. +Instead of using a separate generator for each biome, one generator is used with a different set of input +parameters for each biomes. These input parameters modify the overall amplitude and frequency of the Perlin +noise that the generator produces, thus modifying the final terrain with regards to biomes. Additionally, the +averaging process is weighted - columns closer to the queried column get a more powerful weight in the sum +than the columns further away. The following image shows the output of MCServer's Biomal terrain height +generator (each block type represents a different biome - ocean in the front (stone), plains and ice plains +behind it (lapis, whitewool), extreme hills back right (soulsand), desert hills back left (mossy +cobble)):

    + + +

    One key observation about this whole approach is that in order for it to work, the biomes must be +available for columns outside the currently generated chunk, otherwise the columns at the chunk's edge would +not be able to properly average their height. This requirement can be fulfilled only by biome generators that +adhere to the second Expected property - that re-generating will produce +the same data. If the biome generator returned different data for the same chunk each time it was invoked, it +would become impossible to apply the averaging.

    + +

    (TODO: height with variations (N/A in MCS yet)

    Terrain composition

     +

    (TODO)

    Finishers

     +

    (TODO)

    + + +
    + +

    Making it all faster

     +

    (TODO)

    diff --git a/docs/img/biomalheights.jpg b/docs/img/biomalheights.jpg new file mode 100644 index 000000000..a01faef87 Binary files /dev/null and b/docs/img/biomalheights.jpg differ diff --git a/docs/img/biomeheights.jpg b/docs/img/biomeheights.jpg new file mode 100644 index 000000000..9dda27b0e Binary files /dev/null and b/docs/img/biomeheights.jpg differ diff --git a/docs/img/biomeheightsavg.jpg b/docs/img/biomeheightsavg.jpg new file mode 100644 index 000000000..c8217cafc Binary files /dev/null and b/docs/img/biomeheightsavg.jpg differ -- cgit v1.2.3 From 413d90420d9061a33301a9f4c4dd43e3dbf5a393 Mon Sep 17 00:00:00 2001 From: worktycho Date: Thu, 5 Jun 2014 11:59:06 +0100 Subject: Start of GPU section. --- docs/Generator.html | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'docs') diff --git a/docs/Generator.html b/docs/Generator.html index 282e4c412..304220eb2 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -20,6 +20,7 @@ with specific implementation notes regarding MCServer.

  • Terrain composition
  • Finishers
  • Making it all faster
    • +
  • Excuting a GPU

    • @@ -369,5 +370,9 @@ would become impossible to apply the averaging.

    Making it all faster

    (TODO)

    +

    Executing on a GPU

     +

    Much of the terain genertion consists of doing the same thing for every single column or block in a chunk. This +sort of computation is much faster on a GPU as GPUs are massively parallel. High end GPUs can execute up to 30,000 +threads simultaneously, which would allow them to generate every block in three chunks in parallel.

    -- cgit v1.2.3 From c5343172c118ba59e3181777fbbfd99497d78d6d Mon Sep 17 00:00:00 2001 From: Tiger Wang Date: Thu, 5 Jun 2014 12:01:02 +0100 Subject: Typographical error --- docs/Generator.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/Generator.html b/docs/Generator.html index 304220eb2..860144338 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -20,7 +20,7 @@ with specific implementation notes regarding MCServer.

  • Terrain composition
  • Finishers
  • Making it all faster
    • -
  • Excuting a GPU
    • +
  • Executing a GPU

    • -- cgit v1.2.3 From 523d29b84567888b0e8876ddb1b08d73dae10597 Mon Sep 17 00:00:00 2001 From: madmaxoft Date: Thu, 5 Jun 2014 21:25:18 +0200 Subject: docs/Generator: Added basic terrain composition. --- docs/Generator.html | 32 +++++++++++++++++++++++++++++++- docs/img/perlincompositor1.jpg | Bin 0 -> 15457 bytes docs/img/perlincompositor2.jpg | Bin 0 -> 29005 bytes docs/img/perlincompositor3.jpg | Bin 0 -> 21119 bytes 4 files changed, 31 insertions(+), 1 deletion(-) create mode 100644 docs/img/perlincompositor1.jpg create mode 100644 docs/img/perlincompositor2.jpg create mode 100644 docs/img/perlincompositor3.jpg (limited to 'docs') diff --git a/docs/Generator.html b/docs/Generator.html index 860144338..4647a2165 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -341,7 +341,7 @@ than the columns further away. The following image shows the output of MCServer' generator (each block type represents a different biome - ocean in the front (stone), plains and ice plains behind it (lapis, whitewool), extreme hills back right (soulsand), desert hills back left (mossy cobble)):

    - +

    One key observation about this whole approach is that in order for it to work, the biomes must be available for columns outside the currently generated chunk, otherwise the columns at the chunk's edge would @@ -356,6 +356,36 @@ would become impossible to apply the averaging.

    Terrain composition

     +

    As with the other generators, the composition generator category has its easy and debugging items, too. +There's the "special" composition of "all the blocks are the same type", which fills the entire column, from +the bottom to the height, with a single blocktype. This generator is useful when testing the generators in +the other categories, to speed up the generation by leaving out unnecessary calculations. Another special +compositor is a similar one, that fills all blocks with the same type, but the type varies for each biome. +This way it's easy to see the generated biomes and possibly the heights for those biomes, as shown in the +previous section on the height averaging screenshot.

    + +

    For a natural look, we need to put together a more complicated algorithm. The standard set forth in +MineCraft is that the top of the world is covered in grass, then there are a few blocks of dirt and finally +stone. This basic layout is then varied for different biomes - deserts have sand and sandstone instead of the +grass and dirt layer. Mushroom biomes have mycelium in place of the grass. This per-biome dependency is +trivial to implement - when compositing, simply use the appropriate layout for the column's biome.

    + +

    The next change concerns oceans. The generated heightmap doesn't include any waterlevel indication +whatsoever. So it's up to the terrain compositor to actually decide where to place water. We do this by +configuration - simply have a value in the config file specifying the sealevel height. The compositor then +has to add water above any column which has a height lower than that. Additionally, the water needs to +override per-biome layout selection - we don't want grass blocks to generate under water when the terrain +height in the plains biome drops below the sealevel accidentally.

    + +

    The final feature in the compositor is the decision between multiple composition layouts within a single +biome. A megataiga biome contains patches of non-grass dirt and podzol blocks, and the ocean floor can be +made of dirt, gravel, sand or clay. A simple 2D Perlin noise can be used to select the layout to use for a +specific column - simply threshold the noise's value by as many thresholds as there are layout variations, +and use the layout corresponding to the threshold:

    + + + +

    (TODO)

    diff --git a/docs/img/perlincompositor1.jpg b/docs/img/perlincompositor1.jpg new file mode 100644 index 000000000..0d8f93cd9 Binary files /dev/null and b/docs/img/perlincompositor1.jpg differ diff --git a/docs/img/perlincompositor2.jpg b/docs/img/perlincompositor2.jpg new file mode 100644 index 000000000..11fc5b51d Binary files /dev/null and b/docs/img/perlincompositor2.jpg differ diff --git a/docs/img/perlincompositor3.jpg b/docs/img/perlincompositor3.jpg new file mode 100644 index 000000000..46a2583ba Binary files /dev/null and b/docs/img/perlincompositor3.jpg differ -- cgit v1.2.3 From 34c06d8c39470322962dd2a8df0b81d87b2c7663 Mon Sep 17 00:00:00 2001 From: worktycho Date: Fri, 6 Jun 2014 10:29:10 +0100 Subject: typo --- docs/Generator.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/Generator.html b/docs/Generator.html index 4647a2165..758afa229 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -20,7 +20,7 @@ with specific implementation notes regarding MCServer.

  • Terrain composition
  • Finishers
  • Making it all faster
    • -
  • Executing a GPU
    • +
  • Executing on a GPU

    • -- cgit v1.2.3 From 2ed2f20a314e6c16244b61a228ab81242547ccfd Mon Sep 17 00:00:00 2001 From: worktycho Date: Fri, 6 Jun 2014 11:38:29 +0100 Subject: Fixed numbers --- docs/Generator.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/Generator.html b/docs/Generator.html index 758afa229..16aaf68c8 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -403,6 +403,7 @@ and use the layout corresponding to the threshold:

    Executing on a GPU

    Much of the terain genertion consists of doing the same thing for every single column or block in a chunk. This sort of computation is much faster on a GPU as GPUs are massively parallel. High end GPUs can execute up to 30,000 -threads simultaneously, which would allow them to generate every block in three chunks in parallel.

    +threads simultaneously, which would allow them to generate every block in half a chunk in parallel or every column +in over 100 chunks in parallel.

    -- cgit v1.2.3 From 702571024ca6893e62ffc4f36ff78873b55ff61c Mon Sep 17 00:00:00 2001 From: worktycho Date: Fri, 6 Jun 2014 14:02:54 +0100 Subject: Expanded GPU section --- docs/Generator.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/Generator.html b/docs/Generator.html index 16aaf68c8..5def63e3b 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -404,6 +404,7 @@ and use the layout corresponding to the threshold:

    Much of the terain genertion consists of doing the same thing for every single column or block in a chunk. This sort of computation is much faster on a GPU as GPUs are massively parallel. High end GPUs can execute up to 30,000 threads simultaneously, which would allow them to generate every block in half a chunk in parallel or every column -in over 100 chunks in parallel.

    +in over 100 chunks in parallel. A naive comparison suggests a 800MHz a GPU with 15,000 threads can execute parallel +code 250 times faster than a 3GHz CPU with 128 bit SIMD. Obviously we want to harness that power.

    -- cgit v1.2.3 From 8c8c3ba5c4dbdf85f10df6ba1ee3dd3f6b8438d0 Mon Sep 17 00:00:00 2001 From: worktycho Date: Fri, 6 Jun 2014 14:37:11 +0100 Subject: Grammar --- docs/Generator.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/Generator.html b/docs/Generator.html index 5def63e3b..17690cd5c 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -404,7 +404,7 @@ and use the layout corresponding to the threshold:

    Much of the terain genertion consists of doing the same thing for every single column or block in a chunk. This sort of computation is much faster on a GPU as GPUs are massively parallel. High end GPUs can execute up to 30,000 threads simultaneously, which would allow them to generate every block in half a chunk in parallel or every column -in over 100 chunks in parallel. A naive comparison suggests a 800MHz a GPU with 15,000 threads can execute parallel +in over 100 chunks in parallel. A naive comparison suggests that a 800MHz GPU with 15,000 threads can execute parallel code 250 times faster than a 3GHz CPU with 128 bit SIMD. Obviously we want to harness that power.

    -- cgit v1.2.3 From 87603eb28064556e97d4630a2c03d4937c4e5f22 Mon Sep 17 00:00:00 2001 From: Mattes D Date: Fri, 6 Jun 2014 19:45:17 +0200 Subject: Fixed a typo. --- docs/Generator.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/Generator.html b/docs/Generator.html index 17690cd5c..e43838507 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -401,7 +401,7 @@ and use the layout corresponding to the threshold:

    (TODO)

    Executing on a GPU

     -

    Much of the terain genertion consists of doing the same thing for every single column or block in a chunk. This +

    Much of the terain generation consists of doing the same thing for every single column or block in a chunk. This sort of computation is much faster on a GPU as GPUs are massively parallel. High end GPUs can execute up to 30,000 threads simultaneously, which would allow them to generate every block in half a chunk in parallel or every column in over 100 chunks in parallel. A naive comparison suggests that a 800MHz GPU with 15,000 threads can execute parallel -- cgit v1.2.3 From 0544b96f8041e5dd31b4da84b52d23883d0853f0 Mon Sep 17 00:00:00 2001 From: madmaxoft Date: Sat, 7 Jun 2014 13:59:10 +0200 Subject: docs/Generator: Added the easy Finishers. --- docs/Generator.html | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 117 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/Generator.html b/docs/Generator.html index e43838507..3a7c57697 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -386,14 +386,129 @@ and use the layout corresponding to the threshold:

    +

    Nether composition

    +

    So far we've been discussing only the Overworld generator. But MineCraft contains more than that. The +Nether has a completely different look and feel, and quite different processes are required to generate that. +Recall that MineCraft's Nether is 128 blocks high, with bedrock both at the top and the bottom. Between these +two, the terrain looks more like a cavern than a surface. Not surprisingly, the Nether doesn't need a +complicated height generator, it can use the flat height. However, the terrain composition must take an +altogether different approach.

    + +

    The very first idea is to use the Perlin noise, but generate it in 3D, rather than 2D. Then, for each +block, evaluate the noise value, if below 0, make it air, if not, make it netherrack. + +

    To make it so that the bedrock at the top and at the bottom is never revealed, we can add a value +increasing the more the Y coord gets towards the bottom or the top. This way the thresholding then guarantees +that there will be no air anywhere near the bedrock.

    +

    (TODO)

    Finishers

     -

    (TODO)

    - +

    Finishers are a vast category of various additions to the terrain generator. They range from very easy +ones, such as generating snow on top of the terrain in cold biomes, through medium ones, such as growing +patches of flowers, complicated ones, such as placing trees and generating caves, all the way to very +complicated ones such as villages and nether fortresses. There is no formal distinction between all these +"categories", the only thing they have in common is that they take a chunk of blocks and modify it in some +way.

    + +

    Snow

    +

    Snow is probably the easiest of the finishers. It generates a block of snow on top of each block that is +on top of the terrain and is not marked as non-snowable. It checks the chunk's heightmap to determine the top +block, then checks whether the block supports snow on its top. Rails, levers and grass don't support snow, +for example.

    + +

    Ice

    +

    Another example of an easy finisher. This scans through the world and turn each water block on the surface +into an ice block if the biome is cold. This means that any water block that is under any kind of other +block, such as under a tree's leaves, will still stay water. Thus an additional improvement could be made by +scanning down from the surface block through blocks that we deem as non-surface, such as leaves, torches, +ladders, fences etc. Note that MCServer currently implements only the easy solution.

    + +

    Bottom lava

    +

    Most worlds in MineCraft have lava lakes at their bottom. Generating these is pretty straightforward: Use +the user-configured depth and replace all the air blocks below this depth with lava blocks. Note however, +that this makes this generator dependent on the order in which the finishers are applied. If the mineshafts +generate before bottom lava, the mineshafts that are below the lava level will get filled with lava. On the +other hand, if bottom lava is generated before the mineshafts, it is possible for a mineshaft to "drill +through" a lake of lava. MCServer doesn't try to solve this and instead lets the admin choose whichever they +prefer.

    + +

    Specific foliage

    +

    There are generators for specific kinds of foliage. The dead bushes in the desert biome and lilypads in +the swamp biome both share the same generating pattern. They are both specific to a single biome and they +both require a specific block underneath them in order to generate. Their implementation is simple: pick +several random columns in the chunk. If the column is of the correct biome and has the correct top block, +add the foliage block on top.

    + +

    In order to generate the same set of coordinates when the chunk is re-generated, we use the Perlin noise's +basis functions (the ones providing the random values for Perlin cell vertices). These basically work as a +hash function for the coorinates - the same input coordinates generate the same output value. We use the +chunk's coordinates as two of the coords, and the iteration number as the third coordinate, to generate a +random number. We then check the biome and the top block at those coordinates, if they allow, we generate the +foliage block on top.

    + +

    Another example of specific foliage is the tall grass in the plains biome. There are quite a lot of these +tall grass blocks, it would be inefficient to generate them using the random-coords approach described above. +Instead, we will use a 2D Perlin noise again, with a threshold defining where to put the grass and where +not.

    + +

    Small foliage

    +

    For the flowers, grass, mushrooms in caves etc. we want to use a slightly different algorithm. These +foliage blocks are customarily generated in small "clumps" - there are several blocks of the same type near +together. To generate these, we first select random coords, using the coord hash functions, for a center of a +clump. Then we select the type of block to generate. Finally, we loop over adding a random (coord hash) +number to the clump center coords to get the block where to generate the foliage block:

    + + +

    In order to make the clump more "round" and "centered", we want the offsets to be closer to the clump +center more often. This is done using a thing called Gaussian function distribution. Instead of having each +random number generate with the same probability, we want higher probability for the numbers around zero, +like this:

    + + +

    Instead of doing complicated calculations to match this shape exactly, we will use a much easier shape. +By adding together two random numbers in the same range, we get the probability distribution that has a +"roof" shape, enough for our needs:

    + + +

    (For the curious, there is a proof that adding together infinitely many uniform-distributed random number +produces random numbers with the Gaussian distribution.)

    + +

    This scheme can be used to produce clumps of flowers, when we select the 2D coords of the clump center on +the top surface of the terrain. We simply generate the 2D coords of the foliage blocks and use the terrain +height to find the third coord. If we want to generate clumps of mushrooms in the caves, however, we need to +generate the clump center coords in 3D and either use 3 offsets for the mushrooms, or use 2 offsets plus +searching for the closest opening Y-wise in the terrain.

    + +

    Springs

    +

    Water and lava springs are essential for making the underground quite a lot more interesting. They are +rather easy to generate, but a bit more difficult to get right. Generating simply means that a few random +locations (obtained by our familiar coord hashing) are checked and if the block type in there is stone. Then +we see all the horizontal neighbors of the block, plus the block underneath. If all of them except one are +stone, and the one left is air, our block is suitable for turning into a spring. If there were more air +neighbors, the spring would look somewhat unnatural; if there were no air neighbors, the spring won't flow +anywhere, so it would be rather useless.

    + +

    The difficult part about springs is the amount of them to generate. There should be a few springs on the +surface, perhaps a bit more in the mountaineous biomes. There should be quite a few more springs underground, +but there should definitely be more water springs than lava springs in the upper levels of the terrain, while +there should be more lava springs and almost no water springs near the bottom. To accomodate this, the +MCServer team has made a tool that scanned through MineCraft's terrain and counted the amount of both types +of springs in relation to their height. Two curves have been found for the distribution of each type of the +spring:

    + + +

    MCServer uses an approximation of the above curves to choose the height at which to generate the +spring.

    + +
    -- cgit v1.2.3 From 9ccdceaadf7aaf62d64d8d3406c46e71ef069210 Mon Sep 17 00:00:00 2001 From: Mattes D Date: Sat, 7 Jun 2014 16:41:18 +0200 Subject: docs/Generator: fixed grass confusion. --- docs/Generator.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/Generator.html b/docs/Generator.html index 3a7c57697..0fbc2f436 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -417,8 +417,8 @@ way.

    Snow

    Snow is probably the easiest of the finishers. It generates a block of snow on top of each block that is on top of the terrain and is not marked as non-snowable. It checks the chunk's heightmap to determine the top -block, then checks whether the block supports snow on its top. Rails, levers and grass don't support snow, -for example.

    +block, then checks whether the block supports snow on its top. Rails, levers and tall grass don't support +snow, for example.

    Ice

    Another example of an easy finisher. This scans through the world and turn each water block on the surface -- cgit v1.2.3 From 8cfe6c973c21a10d6e2371917058f241e2679945 Mon Sep 17 00:00:00 2001 From: madmaxoft Date: Mon, 9 Jun 2014 01:42:03 +0200 Subject: docs/Generator: Added SmallFoliage illlustrations. --- docs/Generator.html | 4 ++++ docs/img/gaussprobability.jpg | Bin 0 -> 12994 bytes docs/img/roofprobability.jpg | Bin 0 -> 16679 bytes docs/img/smallfoliageclumps.jpg | Bin 0 -> 15867 bytes 4 files changed, 4 insertions(+) create mode 100644 docs/img/gaussprobability.jpg create mode 100644 docs/img/roofprobability.jpg create mode 100644 docs/img/smallfoliageclumps.jpg (limited to 'docs') diff --git a/docs/Generator.html b/docs/Generator.html index 0fbc2f436..7b70033cb 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -483,6 +483,10 @@ height to find the third coord. If we want to generate clumps of mushrooms in th generate the clump center coords in 3D and either use 3 offsets for the mushrooms, or use 2 offsets plus searching for the closest opening Y-wise in the terrain.

    +

    Note that the clumps generated by this scheme may overlap several chunks. Therefore it's crucial to +actually check the surrounding chunks if their clumps overlap into the currently generated chunk, and apply +those as well, otherwise there will be visible cuts in the foliage along the chunks borders.

    +

    Springs

    Water and lava springs are essential for making the underground quite a lot more interesting. They are rather easy to generate, but a bit more difficult to get right. Generating simply means that a few random diff --git a/docs/img/gaussprobability.jpg b/docs/img/gaussprobability.jpg new file mode 100644 index 000000000..77da24748 Binary files /dev/null and b/docs/img/gaussprobability.jpg differ diff --git a/docs/img/roofprobability.jpg b/docs/img/roofprobability.jpg new file mode 100644 index 000000000..e7a155113 Binary files /dev/null and b/docs/img/roofprobability.jpg differ diff --git a/docs/img/smallfoliageclumps.jpg b/docs/img/smallfoliageclumps.jpg new file mode 100644 index 000000000..4cc6cbc00 Binary files /dev/null and b/docs/img/smallfoliageclumps.jpg differ -- cgit v1.2.3 From 3a3c42276e0c22d6a199a97bee7c9c5ec5c1a98e Mon Sep 17 00:00:00 2001 From: madmaxoft Date: Mon, 9 Jun 2014 21:18:20 +0200 Subject: docs/Generator: Fixed typo. --- docs/Generator.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/Generator.html b/docs/Generator.html index 7b70033cb..90a92c553 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -474,7 +474,7 @@ By adding together two random numbers in the same range, we get the probability "roof" shape, enough for our needs:

    -

    (For the curious, there is a proof that adding together infinitely many uniform-distributed random number +

    (For the curious, there is a proof that adding together infinitely many uniform-distributed random numbers produces random numbers with the Gaussian distribution.)

    This scheme can be used to produce clumps of flowers, when we select the 2D coords of the clump center on -- cgit v1.2.3