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.