|★ APPLICATIONS ★ CREATION GRAPHIQUE ★ PAINTING BY NUMBERS|Computing with the Amstrad) ★|
|Trees / Landscape (Computing with the Amstrad)||Applications Creation Graphique|
IAN SHARPE expands the idea of mathematical trees to produce some attractive landscapes
IN the March 1987 issue of Computing with the Amstrad we introduced you to recursion and fractals in our Dragon Curve program. It generated a lot of interest so here is something more on a related subject - trees.
We had a look at these back in May 1985 but the method was crude and this time we're going to put the results to some use.
Trees caught my attention in Microcomputer Graphics by Mike Batty (Chapman Hall 1987 ISBN 0 412 28540 1). The author introduces simple graphics routines and develops them into interesting picture generating programs.
Poor old Mike uses the BBC Micro for his examples (we all have our crosses to bear), but BBC Basic does have procedures which can be called recursively with local variables and Mike takes advantage of these features to generate his trees.
Of course we don't have procedures on the Amstrad and using Robin Nixon's bolt-on routine from the May 1987 issue would have been admitting defeat. So I set about writing my own tree routine to get round the problems and came up with Program I. It's not an adaptation of the BBC Micro version but a different way of producing the same results.
The idea is that the tree is composed of branches, and at the end of each two new branches grow. At the tip of the new branches are two more and so on. You can see what I mean in Figure I.
Before we see how it works try it out for yourself. You will be prompted for three parameters - angle, depth and size. Angle is the angle of the V between two branches, depth is the number of times the tree is to subdivide and size is the length of the stem between its start and where it first splits into two. To begin with, try values of 45, 8 and 110 respectively. Also have a look at 120,10,150,180,10, 200 and 270,10,200.
What happens is that every time a V is drawn the program calculates the coordinates of the tips. It takes the right-hand fork, draws a line to the tip and in the array stack it stores the details - size, coordinates, angle - of the left-hand tip which it can't deal with yet. It repeats the process, always taking the right fork and storing the left until it has gone to the required level held in depth.
If you think about it, the maximum number of left shoots stored in stack can't be more than depth. When the required number of shoots have been drawn by taking right turns, the routine backtracks in stack to the details of the last left turn it missed. The program uses a pointer - sp - to keep track of which part of stack it is taking its parameters from.
It follows this new route, again always forking right and remembering places it needs to come back to. In this way nothing is left out and eventually the entire tree is plotted. At this point there are no more parameters stored in stack. The program detects this and comes to an end.
To obtain the trunk, stack is initialised with just enough information for one leg of the first V.
Program II - Landscape - uses a modified tree routine to introduce thickness, colour and some random elements to the branches which gives an impression of a real tree with spring foliage.
Using more ideas borrowed from Mike Batty other parts of Program II draw clouds, water, hilly background and a foreground. Again these are controlled by overall rules with random factors, so a different but convincing arrangement emerges every time the program is run.
One such scene is shown in Figure II and I think you'll agree that it isn't bad for something created by a few dozen lines of Basic.
I don't make any claims for its artistic merit but it's far better than I could achieve by hand. Landscape isn't perfect, but it's fairly simple and like many of the programs we publish, it's the starting point for your own ideas.
This program illustrates one of the fundamental points in Microcomputer Graphics. Mike Batty is at pains to highlight the distinction between art on a computer and computer art. The first is where the artist uses a drawing package to create pictures on the screen.
He isn't doing anything different to his colleague working with paints, just using a different medium, though the coarseness of a home computer display makes the level more akin to embroidery or tapestry.
In the second case, computer art, the computer generates the picture from a model programmed by the artist. This is a new concept brought about by the availability of machines which are programmable and have good display capabilities. It opens up a new world of creative graphics to conventional artists and those who have artistic inclinations but may lack the manual skills.
I'll leave you to ponder two questions that puzzle a lot of people - is computer art really art and if so, does the art lie in the program or in the display on the screen?
If you want to see some impressive graphics created on main-frames with very high resolution displays, ask at your library for Creative Computer Graphics by Jankel and Morton (Cambridge University Press 1984 ISBN 0