MSc Virtual Environments The Bartlett School of Graduate Studies University College London
Methods in Synthetic Construction 2: Invisible Cities
Final Report
Jorge Alberto Lopes Gil 31.3.2000
TABLE OF CONTENTS
OUTLINE .................................................................... 2
Introduction The book – “Invisible Cities” by Italo Calvino The text generator
A CITY DESCRIPTION ............................................... 5
A first example
THE CITY GENERATOR ............................................ 6
Introduction Initialisation Text creation City creation The Library Possible developments
THE GENETIC LAB.................................................... 14
Introduction The chromosomes The crossover operation Manual evolution Possible developments
CONCLUSIONS.......................................................... 21
Complexity Diversity The cities
APPENDIX A
Text strings selected from the book
APPENDIX B
City Generator source code
APPENDIX C
Picture Library I – City Elements
APPENDIX D
Genetic Lab source code
APPENDIX E
Picture Library II – Chromosomes
1
OUTLINE
INTRODUCTION
In the sequence of the preceding module “Methods in Synthetic Construction 1” (the VRML project) I am interested in exploring other aspects of creating a digital environment, that weren’t implemented at the time. The first project focused on the idea of interaction between the user and the environment and the use of animation (preset or user induced), making use of the possibilities offered by VRML 2.0 and VRML Script. But the architectural object itself was always the same, setting the user at the same starting point each time he returned to the scene. This time the focus will be on the exploration of complexity and diversity in the creation of the architectural object. Being C++ a programming language that enables a powerful manipulation of a scene graph, the use of randomness and algorithms will make this scene graph present a different object each time the program is run. Interaction with the user will be limited to the possibility of trying different worlds or versions of the same world, and the natural possibility to navigate these worlds.
THE BOOK: “INVISIBLE CITIES” BY ITALO CALVINO
What inspired me most while reading the book wasn’t any description of a particular city or the idea behind a category of cities. It was the description of the descriptions and the dialogues between Kublai Kahn and Marco Polo, and all the related events. - Marco’s methods of describing a city without being literal, i.e. without having a complete control over the outcome – the Kahn’s understanding of the city; - Kublai Kahn’s interpretations and his own descriptions of cities, using Marco’s signs and objects, trying to obtain from him the name of a city; - Kublai Kahn’s attempt to grasp all the empire by the understanding of the elements and the rules that originate the cities; - The Atlas, where all the past and future cities are described; - The Chess game, where all the cities can be created. Here are some passages from the book that are particularly meaningful:
«Kublai Khan had noticed that Marco Polo's cities resembled one another, as if the passage from one to another involved not a journey but a change of elements. Now, from each city Marco described to him, the Great Khan's mind set out on its own, and after dismantling the city piece by piece, he reconstructed it in other ways, substituting components, shifting them, inverting them.» 2
«The Great Khan owns an atlas in which are gathered the maps of all the cities. The atlas has these qualities: it reveals the form of cities that do not yet have a form or a name.» «The Great Khan's atlas contains the maps of the promised lands visited in thought but not yet discovered or founded.» «Kublai was a keen chess player, he observed that certain pieces implied or excluded the vicinity of other pieces and were shifted along certain lines. He could grasp the system of arranging one with respect to the others on the majolica floor. "If each city is like a game of chess, the day when I have learned the rules, I shall finally possess my empire, even if I shall never succeed in knowing all the cities it contains.» «Contemplating these essential landscapes, Kublai reflected on the invisible order that sustains cities, on the rules that decreed how they rise, take shape and prosper, adapting themselves to the seasons, and then how they sadden and fall in ruins.» «It would suffice to play a game according to the rules, and to consider each successive state of the board as one of the countless forms that the system of forms assembles and destroys.» «"I speak and speak," Marco says, "but the listener retains only the words he is expecting. It is not the voice that commands the story: it is the ear.» «The catalogue of forms is endless: until every shape has found its city, new cities will continue to be born. When the forms exhaust their variety and come apart, the end of cities begins.» «"Travelling, you realize that differences are lost: each city takes to resembling all cities, places exchange their form, order, distances, a shapeless dust cloud invades the continents.» So to me, the actual description of a city has become less important than the understanding of the events that are behind it’s creation. The aim is that of creating the pieces and the rules from which “all” the cities can be derived. Create the Kublai Kahn’s empire without really knowing every city.
THE TEXT GENERATOR
The description of a city wasn’t for me the right tool to start the project. Actually being the elements interchangeable, any description was good for my project, but would also limit its scope. So I decided to make a text generator program that, using quotations taken from the original book, selects and combines them randomly producing a different description each time it’s executed. The purpose of the text is not to create a good description of a city, although the text might sometimes become interesting, since the sentences were consciously selected and grouped in categories. The main purposes are firstly to make the project explain itself to the user, allowing him to understand the ideas raised in the book by the passages between the descriptions of cities; secondly to obtain the necessary data to inform the main program of what city to create. With repeated use of the program over time the actual content of the text will become more irrelevant, as it repeats itself. But the selection of data will always be necessary, and the user should have a certain freedom to play with it.
3
What the text generator program does (or will do when it becomes fully functional) is ask the user to select the location of the city he wants to visit, by clicking on a window with the image of a map. This way it determines a seed for the random numbers, using the coordinates picked by the user. Having the seed, the program selects a set of strings from a two-dimensional array, where they are ordered according to the place they will take in the text. Some of these strings have a certain code associated with them. This code determines the name of the city and the rules that will be used by the city generator part of the program. It can be interesting to allow the user to return to a previous city by inserting its name. He has always to choose the location of the city to determine the random seed number, so although he’s using the same genes (rules) derived from the city’s name, the random numbers in the city creation will be different, originating a changed city. Apparently the same city, visited at a different moment in time. It’s a sort of “static evolution”, a snapshot of a continuous process.
4
A CITY DESCRIPTION
A FIRST EXAMPLE
«Kublai Khan had noticed that Marco Polo's cities resembled one another, as if the passage from one to another involved not a journey but a change of elements. Now, from each city Marco described to him, the Great Khan's mind set out on its own, and after dismantling the city piece by piece, he reconstructed it in other ways, substituting components, shifting them, inverting them.» «Kublai was a keen chess player, he observed that certain pieces implied or excluded the vicinity of other pieces and were shifted along certain lines. He could grasp the system of arranging one with respect to the others on the majolica floor. "If each city is like a game of chess, the day when I have learned the rules, I shall finally possess my empire, even if I shall never succeed in knowing all the cities it contains.» «It would suffice to play a game according to the rules, and to consider each successive state of the board as one of the countless forms that the system of forms assembles and destroys.» The City of Genevolea «Whether [...] is like this because it is unfinished or because it has been demolished, whether the cause is some enchantment or only a whim, I do not know.» «In the centre of [...], that grey stone metropolis, stands a metal building with a crystal globe in every room. Looking into each globe, you see a blue city, the model of a different [...]. These are the forms the city could have taken if, for one reason or another, it had not become what we see today.» «The city does not consist of this, but of relationships between the measurements of its space and the events of its past. The city however does not tell its past, but contains it like the lines of a hand, written in the corners of the streets.» «When travelling in the territory of [...], you come upon the ruins of the abandoned cities: spider webs of intricate relationships seeking form.»
Quotations from the book "Invisible Cities" by Italo Calvino.
5
THE CITY GENERATOR
INTRODUCTION
The city generator is a program that creates a different city each time it’s run. Based on the ideas described previously it produces a description of a city, gives it a name, and then builds it for the user to explore. It uses a library of predefined objects, like the chess-pieces in the book, which are randomly combined to produce a variety of different cities. Besides that, each object is subject to a certain amount of random change that makes the return to the same city, or the reuse of an object, a slightly different experience.
INITIALISATION
The first step in the selection process is to obtain a different random number seed each time the program starts. The program uses the total number of seconds since a certain standard time, so that the available sequence of random numbers is always initiated in a different position. This is very important because allows the program to make different selections, thus creating different cities. Only chance will determine if the same selection occurs again. Then two numbers are randomly selected, “selection1” and “selection2”, which will be used throughout the program for choosing text strings and geometries. They are first used by the text generator part of the program, the “makeText” function.
TEXT CREATION
An adapted and simplified version of the original text generator program is now the first part of the city generator program. The “makeText” function assigns a text string to each part of the text. (The strings used for the text creation can be found in Appendix A.) The text consists of seven parts: - the first three are an introduction to the context of the project, based on quotations from the parts of the book in-between the cities descriptions; - the last four are the actual description of a city, with quotations that respect a certain structure of arrival, description and departure. The strings must be first assigned to the “TextArray” by the “getText” function, where they are stored. Then they are picked randomly for each part of the text by a “for” loop. Only parts 5 and 6, from the city description, use the two selection numbers, because they are relevant for the city configuration. This
6
loop also picks the two syllables for the city’s name using the “nameAssign” function. The “switch” is used because the type of the variable for the text parts cannot be the same as the type of the “TextArray” strings. Having all the text variables, the strings are simply printed on the output window to form the text. This has the inconvenient that the window’s default buffer or default size has to be increased to around 40 lines by changing the MSDos console settings, before the program is used, or else the text will be cropped and only the last strings appear on the screen. Ideally the program would create a simple text file, using the options in the standard “fstream” class, but I didn’t understand how to use it. The city name never exists as a single variable since it is only used when the text appears on the screen. It would be necessary to use some standard string class function to combine the two character strings into one single string. After printing the text on the screen the program returns to the main function for the next part: the city generation.
7
CITY CREATION
The “makeCity” function is responsible for the creation of the objects that build up the city. It takes “the_city” group node, where all elements will be added, and the two selection values used later on to pick objects from the library. The city structure consists of what I called “connectors”. They are large-scale structures that establish a certain order for the city, and which in turn contain “objects”, smaller scale structures. A table with the different “connectors” and “objects” can be found in Appendix C. The “connectors” are initialised in the “makeCity” function that calls the “selectConnector” function. This is a simple switch that using the initial value “selection1” chooses the “connector” from the library. The integers and general names at moment of selection enable an easy manipulation/ restriction of the objects to be selected and also an easy replacement of objects in the library. I created this function to allow the flexible use of more than one connector in the city creation. This way I can add more “connectors” at the “makeCity” function, or call them from inside another object’s function to create some type of recursion or just more complexity. The “connectors” are “csTransform” nodes to allow change (translation, rotation or scaling) at every level they are inserted. None of these situations is however used in the program. The connector functions create the city structure and use the value “selection2” for the selection of city “objects”. A function “selectObject”, very similar to the previously described “selectConnector”, calls the object function.
Diagram of a simplified scene graph with the several functions.
8
Both connector and object functions (the library functions) have a similar logic: - “limit” variable, sets the number of repetitions of the algorithm; - mutation values, set appearance values for the shapes; - structure, an algorithm that combines shapes; - shapes, primitive functions or object functions called by the structure. The “mutation values” are random numbers assigned to variables that are passed to the appearance of shapes. Mutation is important to define a certain amount of change in the objects each time they are used. It is one of the main factors towards diversity. The “shapes” are functions for frequently used primitives, with default values, that change colour, specular colour and transparency according to the values from the mutation. The size and position of the shapes can also be modified because they are Transform nodes. The “structure” is the output of these library functions that is added finally to “theCity” node. The result of all this city creation process is the combination of the geometries of two different structures from the library: one “connector” and one “objects”. Now, the user has the possibility to navigate and explore the city.
9
10
Images from different cities: Bioteria, Biovane, Cartirotona, Siriliga, Erevolea, Geneteria.
THE LIBRARY
The use of so many levels of functions increases the flexibility of the program allowing the reuse of certain functions, changing the normal program flow without having to change the code itself. This was done with the intention of replacing the present objects from the library with more interesting ones, or developing more complex structures from ideas that come up from the use of the program. The standard library “connector” is composed by an algorithm that places a primitive shape and an algorithm that places the selected “object”. The standard “object” has only one algorithm and a primitive shape.
11
Depending on the desired design for the object some changes were introduced in this logic. Some algorithms became more complex by introducing more algorithms or shape. It happened mainly while trying to mathematically reproduce the logic of a previously existing design idea. Often the result was too simplistic or didn’t correspond to the design. Other objects were born spontaneously from experiments with algorithms, resulting in a more rewarding design experience. Anyway, the form of the individual objects is very simple, despite the amount of time spent on tuning and developing them. This leads to cities that can be experienced in a short period of time, not displaying the richness of the descriptions created. After some time the cities actually start to resemble each other and the recognition of certain objects reduces the interest in exploring the new city. The user simply restarts the city generator in the expectation of seeing something new. The use of more complex geometries and other features, like sound and animations, would certainly improve the experience of the city. But the Cosmo3D Library doesn’t make it very easy to use geometries beside the sphere, cylinder and cube primitives. The others are dependent on many different classes, and to get something simple as a line, you have to understand the use of the “csGeoSet”, and many other classes. Going through this hierarchy and inheritances is very confusing in the beginning, and requires a dedicated study. I decided not to proceed in that direction, although I recognize the freedom it would give in the creation of more diverse objects for the library.
POSSIBLE DEVELOPMENTS
The part relative to the user interface wasn’t created in C++, but due to its relevance for the experience and understanding of the project by the user, it should be introduced contemplating the following steps: Selection of a location on a map, halt on the program to allow the reading of the text, a reset option that allows the user to return to the beginning without having to close the program, the option to introduce names directly without choosing a location. The first step would be the insertion of a textured object on the render window, and a “while” loop until the user clicks on the image. The coordinates would be used on the random number seed. This object would then have to be removed from the scene, and the text would be created. Once again the program would wait for user input to proceed to the actual design of the city. As it is now, the user dives immediately into the created city, not bothering to read the text and the name of the city. After the experience, a simple key press could clear the whole world and send the user to the beginning: the map. Presently, and for the presentation, a very simple interface was created in HTML, which allows the user to access the program by clicking on an image map.
12
The image used as a map to introduce the user to the Kahn’s empire. The introduction of more different objects in each city would make it more interesting to explore. But that would mean increasing the library size with more different objects, or finding a way to use the existing objects in such a way that they would generate different ones. This started to make me think about breeding objects and introducing genetic properties in the program…
City creation with simple object juxtaposition. The city is 50% of each, clearly recognizable on a different selection.
City creation with exchange of properties between objects. The city uses composites of the original objects, making the city more different each time.
13
THE GENETIC LAB
INTRODUCTION
While working on the city generator program some developments lead me into a new direction. I started calling the objects from the library chromosomes and their attributes genes. The reason for this lies in the fact that these objects aren’t created by a full description of their form and appearance, instead they originate from a set of algorithms and attributes. I realized that by exchanging or mixing these more abstract elements I could get even more diversity in the city without the need to introduce more objects into the library. And maybe I could develop complex and unpredicted structures or forms. The drawback was that I would loose complete control over the final appearance of the city, because the implications of opening the object functions to exchange of data is that anything can happen. So I started creating another program that explores the possibilities of genetic operations in the creation of form, but didn’t integrate these operations in the city generator program. It became a genetic lab, where I can experiment freely and easily with algorithms and shapes. Regarding the result, I can analyse the data (chromosome) used in the process and build an object with the same attributes (genes). This object can then be introduced as a closed design element in the city generator library.
THE CHROMOSOMES
The central data structure of this program is the chromosome. It is defined in the “Chromosome” class, and is used as a container of the genetic data of the object to be created. This container is passed to every function, where it either is manipulated or defines the several parameters of the function. This is the chromosome structure:
class Chromosome{ public: // Initialisation function Chromosome(); // Appearance data float red; float green; float blue; float specular; float transparency; // Geometry function selector int geometry; // Structure function selector int structure;
14
// Control values float size; // size of the geometry int depth_limit; // number of repetitions in the structure int variation; // randomness rate of structure elements };
The initialisation function defines the default genetic values. Then the different genes are defined, for different aspects of the object creation: - For the appearance, there are the three RGB colour components, a component for specular colour and for transparency value. These values are used in the geometry. - A value that determines the geometry used in the object. The geometries are functions that build a certain shape. In the case of “MrTree” it was the “basic_shape”. - A value that determines the structure that builds the object. The structures are functions that have an algorithm where geometries are used. In the case of “MrTree” it was a recursive algorithm. - A set of control values, used in the structure functions, that introduces changes to the algorithm, leading to a different result. In the genetic lab program I’ve created an initial chromosome pool. It consists of a series of functions that set the values for the genetic data of objects, where the main concern was variety. The several objects resulting from the combination of twice the same chromosome from the pool are displayed in Appendix E. The whole scope of options is evenly represented in the chromosomes of the pool, rather than setting more weight in some options, looking for the predominance of those characteristics. This way I look for surprising and even extreme results, depending solely on the outcome of the crossover operation.
THE CROSSOVER OPERATION
The genetic lab program starts by choosing randomly two chromosomes from the chromosome pool using the “select_chromosome” function, and sends them to the “Crossover” function. Here the mixing of the data takes place. This is the “Crossover” function:
Chromosome * Crossover (Chromosome * data1, Chromosome * data2) { // Object where the data is mixed Chromosome * mix_data = data1; // the genes from chromosome 1 are dominant int chance; // variable for the probability factor // The mixing operation chance = rand()%100; // a number between 0 and 99 if (chance > 49) // 50% chance of using data from chromosome 2 { mix_data->red = data2->red; // the colour components stay together
15
mix_data->green = data2->green; mix_data->blue = data2->blue; } chance = rand()%100; // each part has a new chance of crossing if (chance > 49) mix_data->specular = data2->specular; chance = rand()%100; if (chance > 49) mix_data->transparency = data2->transparency; chance = rand()%100; if (chance > 49) mix_data->geometry = data2->geometry; chance = (rand()%100); if (chance > 49) mix_data->size = data2->size; chance = (rand()%100); if (chance > 49) mix_data->depth_limit = data2->depth_limit; chance = rand()%100; if (chance > 49) mix_data->variation = data2->variation; return mix_data; }
An intermediary chromosome “mix_data” is created and receives the data from chromosome one, becoming these dominant genes. A probability factor determines if the genes of the future object are to be replaced by the ones of chromosome two. The factor is determined individually for different groups of genes, allowing many types of crossover, and eventually no crossover at all. The gene that determines the structure is the only that is not subject to crossover, and is always retrieved from chromosome one. In the end, the “mix_data” chromosome is returned to the main function and becomes the origin of the new object, passing its data to the “object_data” chromosome. All the genetic data involved in the process is displayed on the text window, plus the variable (“scale”) that determines if the object is going to be large-scale or smallscale. These values are fundamental for the control and analysis of the selection and crossover operations, and are the basis for manual evolution.
The text window displaying the data encoded in the chromosomes
16
MANUAL EVOLUTION
Each time the program is run the genetic operations determine the creation of a different object. By observing the result and analysing the genetic data, it becomes possible to perform a manual evolution of the original chromosome pool. As I mentioned before, this original chromosome pool was built towards diversity, using all the elements from a library of structures and geometries and setting a wide range of genetic values. My level of control was in building the library and choosing the genetic values between certain reasonable boundaries: colours between 0 and 1; “transparency” between 0 and 0.4; “depth_limit” between 1 and 10, “variation” between 1 and 10. In the design of the library there wasn’t much concern in tuning the functions towards a certain result, since the crossover operation can bring very different values into the library functions. There is a very high factor for the occurrence of crossover (50%), since I’m interested in mixing all of the available data to experiment different combinations and evaluate the results. One thing that I kept out of the functions was any kind of mutation, that is, random use of values. Since I want to know the exact origin of the objects, they have to be an exact result of their genetic code, and the crossover operation already does a great deal of inserting varied data into the library functions. From this initial state, evolution of the objects created by the genetic lab can be achieved using three different procedures: - Editing the content of the chromosome pool I change the values that give poor results, or introduce new values to test the result. - Editing the content of the library I replace structure or shape functions that don’t give interesting results. - Editing the structure and shape selection functions I can override the genetic data from a chromosome, or filter the objects from the library that can actually be selected. This way I have the possibility, according to some objective, to lead the genetic lab into producing more interesting objects.
17
Some variations that occur on the original Mr Tree algorithm
18
19
Other images captured from the genetic lab program.
POSSIBLE DEVELOPMENTS
The operation of evolving the genetic lab objects still requires some persistence, because the selection of chromosomes is random and there are a wide variety of chromosomes and elements in the library. The reason for this lies in the origin of this program: the city generator. There, a wide range of objects is required to achieve diversity, so this program tries to obtain a wide range of results, and not converge into a single optimum form. To optimise the program for such an operation the library of structures and shapes should be reduced and contain only elements that are close to the desired result. The fact that the design is still based on a library of objects is also a drawback. The elements from the library have to be designed and only some parameters are changed by the chromosome data. The actual structure algorithms are closed and static. Ideally the elements from the library would be cut into elementary pieces to produce more unexpected combinations and create new algorithms. Identifying recurrent elements, like x, y and z position or scaling, the different equations for each variable could be recombined, according to information encoded in the chromosome. The chromosome would contain more abstract data of rules (how to get an x value), than data to build a certain type of structure.
20
CONCLUSIONS
COMPLEXITY
In this project I approached, to some extent, two different ways of designing. The first is implemented in the city generator program, the second in the genetic lab. Both use the possibility offered by the computer of creating some sort of automatic design, which the user doesn’t control to its full extent. The first way, gives a lot of control to the designer. It’s based on pre-designed objects whose parameters are only subject to some randomness, and they are divided into two categories, “connectors” and “objects”. The number of possible combinations is reduced (49), allowing the user to test and tune most of the results. But randomness still plays a role, and when observed in detail, the whole composition and the diversity of individuals couldn’t be carefully designed, and also the repetition of some cities doesn’t offer the same experience again. These aspects are characteristic of cities, of their life and evolution, and it’s important to incorporate them in virtual environments. In this way of designing, the richness of the environment is directly related to the quantity and quality of the elements available, and the complexity of the structure that combines them. Being both designed, most of the production work is still done by the designer, and the more he produces, the better results he will get. The second way, takes some of the control over the end result away from the designer. He doesn’t have to worry so much about the design of individual objects, since they are going to be mixed and transformed. And he also doesn’t have to create so many objects, since they can be transformed via parameters, with data coming from the chromosomes. This way he can have a few primitives originating many different objects, depending on the complexity of the information structure encoded in the chromosomes. But he still manipulates all these ingredients by hand, designing the structures and shapes, depending the success of the results mostly on the quality of his design. What the two programs miss is a truly generative process, in the sense of the design being obtained by some purposeful rules leading towards an unexpected formal result. Both programs are based on plain randomness as initial rule, and form is not generated but simply combined and slightly manipulated from a set of pre-designed objects. They are form driven instead of rule driven, although the forms are created using algorithms. There isn’t a set of global rules above the object level. The result is never completely surprising to the designer, only more or less unexpected and weird. And for the user, if the designer tries to put to much control on the elements, can become repetitive after some experiments. There is a lack of the attractive complexity of cities.
21
DIVERSITY
Another aspect that has to be considered is how changes introduced into an objects appearance or structure influence the perception of the object. By running the program several times while constrained to certain structures or chromosomes I could experience different levels of recognition or of surprise. It would depend on the type of change and on how profound they were. The objects could be considered: - Same object- even suffering some changes in appearance and/or structure, they were so subtle that weren’t necessarily perceived. The shapes used were the same. - Same object, at a different stage/time – structure would change significantly, but appearance and the shapes used were still the same. - Different object, but of the same family – appearance and structure would change significantly, but the shape used remained the same. - Different family, but of the same species – appearance and structure didn’t change, but this time a different shape was used by the structure. - Of a different species – appearance, structure and the shapes used were very different from the previous object. This is purely subjective observation and cannot be taken as a general rule. But this aspect plays an important role in the control of the diversity of the elements of the city. A designer should consider how to deal with these levels to achieve the desired diversity result.
THE CITIES
My primary objective, as stated in the Outline of this report, was to explore complexity and diversity in the design of virtual environments, in the context of the book “Invisible Cities” by Italo Calvino. I understood that these two objectives cannot be achieved if the designer tries to take full control of the design result. He has to focus on the process and on developing rules and systems that make the computer produce a reasonable and interesting result. In this particular case, the use of the selected quotations describing cities would make a good context for the creation of rules. Their interpretation, translated into a few simple behaviour algorithms, could produce better results than search for algorithms that produce a certain form. That was the initial idea, and could be implemented now that the structure of the program is created.
22