details of the implementation).
Back to LiveLand applet
An idea to write my own version of the Fractal Landscapes
Generator first occured to me soon after I've read an article
"3D Fractal Landscapes", written by John Shemitz.
There was three printed editions of the article. The
first edition was published in the "Visual
Developer" magazine, April/May 1996. The third one was
published in the book : Don Taylor, Jim Mishel, John Penman,
Terence Goggin, John Shemitz, "High performance Delphi 3
Programming", Coriolis Group Books, 1997 - Chapter 8.
Besides, the Internet version of the article is available at
the following address: http://www.midnightbeach.com/jon/pubs/3D_Fractal_Landscapes.html.
It is possible to download from here both full source and
executable code of the FL3 program. (Fractal Landscapes
version 3, author - John Shemitz).
There are many really good ideas in the article. First of all,
the author offered simple method for generating some kind of
pseudonormal distribution and it works good, really good. The
fracturing and projecting methods are very good too. And, after
all, there is really working program FL3, generating random
Fractal Landscapes. And it is really substantial reason to be
grateful to its author John Shemitz.
The main idea of the random fractal landscapes was very
attractive, but, learning thoroughly the source code of the FL3
program, I've found that it needs for global improvement. The FL3
program is written in Delphi Object Pascal, but its author didn't
apply Object - Oriented Programming technique at all, and
therefore the program's code is rather tangled. Besides, there
were many chunks of dead code, remaining from the early versions
of the program. The algorithm itself is quite time-consuming, and
abundance of some redundant calculations slows down the speed of
the program a lot.
There is also some another kind of problems about the FL3. The
quality of drawing in the "rendered mode", i.e. drawing
the most realistic pictures with the shadowed surfaces, is very
bad. Each landscape, drawn by the FL3 program in the
"rendered mode", looks two-dimensional and dead. The
reason of that is obvious : the author is finding the brightness
of any triangular part of the surface as value, depending
linearly on an angle between direction to the "sun" and
line, connecting the triangle's center of gravity with one of its
vertices. It is really a very poor approximation. Much better
solution is to regard brightness of surfaces as value, depending
linearly on the cosine of angle between the direction to the
"sun" and a line, orthogonal to the surface. We can
find vector, orthogonal to the surface as vector cross product of
two vectors - sides of the surface's triangle. Then we can find
cosine of the angle as scalar product of two vectors, divided on
length of each one. It is really simple, isn't it? Of course,
when we are fracturing each triangle to 4 ones and calling
recursively the same procedure for each new triangle, we should
keep stable direction of numbering of the triangle's vertices
(clockwise, for example).
FL3's author has numbered the triangle's vertices in
absolutely arbitrary way. After I've changed its numbers
properly, it was really easy to solve some another problem. This
problem is about drawing of the invisible surfaces. Mr.Shemitz's
written in his article that there is no easy way to recognize
invisible triangles, and therefore the best solution he's found
is to let them to be painted at first, and then hidden by the
visible ones. But if all the triangle's vertices are numbered in
the clockwise direction, the projection of some triangle to the
screen would have counter-clockwise direction of the vertices'
numbers only in case when the triangle itself is invisible. We
can recognize them easily by checking the sign of the respective
vector cross product.
Mr. Shemits himself admits that indeed we don't need to use
three indexes for access to the items of the triangular array.
The third index is redundant. But Mr. Shemitz insists that such
thing increases the clarity of the algorithm. I don't agree with
him, and I don't use the third index.
Drawing the surface of "sea", the FL3 program draws
a lot of little blue triangles. But the less time-consuming
approach is to draw the whole triangle of the "sea" at
once and then draw the land. ( I've added simple fractal clouds
to my landscapes. The sea looks so colorful because it is drawn
in the XOR mode over these clouds. It is only a trick).
The algorithm of drawing of the vertical sides of our
"slice" in the FL3 program was incredible tangled. I've
replaced it with another one, much simpler.
As I've mentioned already, I've added fractal clouds to my
landscapes. Off course, it slows down the speed of drawing, but
only a bit. It looks great and I sure it should be done.
Eventually I've changed almost all the parts of the FL3's
algorithm, and many parts was changed by me completely. Getting
rid from the redundant calculations and applying the double
buffering technique for drawing, I've really improved a lot the
time of drawing and appearance of pictures. In such way I've
gotten an opportunity to make not only static landscapes, as it
was in the FL3 program, but some kind of animation.
Up to now I've written two versions of the Fractal Landscape's
generator. The first version is a Delphi program, the second one
is a Java-applet.
June, 05, 1999. F.Golubov.