From a2795beb56079d3ff46ce98ce30f4e14ded29402 Mon Sep 17 00:00:00 2001 From: NiLSPACE Date: Thu, 23 Jun 2016 21:43:40 +0200 Subject: added Grown visualizer to the Generator documentation --- docs/Generator.html | 36 +++++++++++++++++++++++++++++++++++- 1 file changed, 35 insertions(+), 1 deletion(-) (limited to 'docs/Generator.html') diff --git a/docs/Generator.html b/docs/Generator.html index 89dff3502..4d17826c1 100644 --- a/docs/Generator.html +++ b/docs/Generator.html @@ -1,6 +1,8 @@ -Generating terrain in Cuberite + Generating terrain in Cuberite + +

Generating terrain in Cuberite

@@ -429,9 +431,41 @@ using the same approach as in MultiStepMap - by using a thresholded 2D Perlin no +

Of further note is the existence of two sets of the IntGen classes, representing the individual operations. There are the cProtIntGen class descendants, which are used for prototyping the connections between the operations - it's easy to just chain several operations after each other and they automatically use the correct array dimensions. However, it is possible to further optimize the calculations by moving the array dimensions into template parameters (so that they are, in fact, constant from the code's point of view, and so highly optimizable). This is what the cIntGen class descendants do. Unfortunately, this optimization makes it difficult to change the operation chain - when a new operation is added or removed in the chain, the array sizes for the rest of the chain change and they all have to be updated manually. So the optimal strategy was to use the cProtIntGen classes to find out the best-looking combination of operations, and once the combination was found, to rewrite it using cIntGen classes for performance.

+
+ +Here is a visualizer where you can play with the algorithm that the Grown biome generator uses. Note that rendering the map takes way longer than the zoom/smooth operation. + + + + + + + + + + + + + + + + +
+ + +
+ +
+ +
+ +
+ +
-- cgit v1.2.3