Collaborative architectural design in virtual reality

(1)

COLlaborative Architectural Design

In VIrtual Reality

(2)

Trefw.: architecture, design process, collaborative design, parametric design, design evaluation, prototyping

(3)

Proefschrift

ter verkrijging van de graad van doctor aan de Technische Universiteit Delft

op gezag van de Rector Magnificus Prof. dr. ir. J.T. Fokkema, voorzitter van het College voor Promoties,

in het openbaar te verdedigen op maandag 11 februari 2008 om 15.00 uur

door Johannes Cornelis HUBERS bouwkundig ingenieur

(4)

Dit proefschrift is goedgekeurd door de promotoren: Prof. Ir. K. Oosterhuis en

Prof. Ir. L. van Duin

Samenstelling promotiecommissie: Rector Magnificus, voorzitter

Prof. Ir. K. Oosterhuis, Technische Universiteit Delft, promotor Prof. Ir. L. van Duin, Technische Universiteit Delft, promotor

Prof. Dr. L. Hovestadt, Eidgenössisches Technische Hochschule Zürich Prof. Dr. Ir. B. de Vries, Technische Universiteit Eindhoven

Prof. Ir. C.A.J. Duijvestein, Technische Universiteit Delft Prof. Dr. Ir. J.G. Rots, Technische Universiteit Delft

ISBN 978 90 5269 360 6

Published by: Publikatieburo Faculteit Bouwkunde TU Delft Printed by Sieca Repro BV

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronical or mechanical, including photocopying, recording or by any information storage and retrieval system without permission from the author.

(5)

pour Frédérique et nos fils

(6)

(7)

Figure 30 Screenshots of Second Life worlds...100 Figure 31 Zoom on an active world (Active Worlds 2007) ....101 Figure 32 Building possibilities in Active Worlds...102 Figure 33 Pre-designed objects in Active Worlds...102 Figure 34 Telescopic steel tubes in Waterloo International Railway Station (C. Rietveld Holden)...111 Figure 35 The Web of North Holland pavilion

(www.oosterhuis.nl) ...112 Figure 36 ADA (http://www.ini.unizh

.ch/~expo/_download/ada_vp_de.pdf) ...113 Figure 37 Knowledge based design at SIA ...114 Figure 38 Example of adaptive parametricdesign (Wymer 2002)

...115 Figure 39 Virtual Operation Room (Oosterhuis et al. 2003b).117 Figure 40 Kaisersrot parametric ’swarming’ software (Hovestadt 2007)...118 Figure 41 Swiss Re building designed by Foster and Partners (amateur photo) ...118 Figure 42 Double curved space frame in GC...120 Figure 43 File-to-factory, dependency graph and double curved nurbs surface in GC...121 Figure 44 POD as volumes loaded in 3D environment, Virtools

...122 Figure 45 Criteria overlay matrix in Virtools...124 Figure 46 Dynamic diagram with two way link to an array....125 Figure 47 Final DDDG prototype with multi way link between online database, diagram and geometry ...126 Figure 48 The HERMES system (Karacapilidisa and Papadias 2002)...129 Figure 49 An instance of the HERMES Discussion Forum (Karacapilidisa and Papadias 2002) ...130 Figure 50 Initial Fire Station layout (Case and Lu 1996) ...132 Figure 51 Initial design (top) communication between agents (middle) design after the negotiation (bottom) (Anumba et al. 2003)...134 Figure 52 House design with AMCE (Hauglustaine and Sleiman (2001) ...135 Figure 53 Noerrebro Park, the virtual market place,

(11)

Figure 54 Criteria Overlay Matrix programmed in Virtools...137

Figure 55 Result of COLAB prototype ...141

Figure 56 Program Of Demands as volumes loaded in 3D environment...143

Figure 57 Criteria overlay matrix Figure 58 Curves ...144

Figure 59 COLAB IDEF-0 Process diagram ...145

Figure 60 Database communication with one table ...146

Figure 61 Database communication with personal tables...147

Figure 62 Single user database communication...148

Figure 63 Multi-user database communication...149

Figure 64 Final setup of database communication...150

Figure 65 Translation of 2D Mouse movement on the screen to 3D plane ...152

Figure 66 Projection of point Q on a line PX...153

Figure 67 Absolute movement results in a jump...154

Figure 68 Relative movement is fluent ...155

Figure 69 Loop with two counters ...157

Figure 70 Upload, Download loop and New Data script (partly) ...166

Figure 71 Zoom out on Figure 70 ...167

Figure 72 End of session 1 ...171

Figure 73 End of session 2 ...173

Figure 74 Enquiry...175

Figure 75 Visualisation of the structural problems with vectors ...179

Figure 76 Dynamic diagram with two way link to an array....209

Figure 77 Dynamic diagram with two way link to array and database. ...211

Figure 78 Timing problem in programming the link diagram-array-database...213

Figure 79 Final DDDG prototype with multi way link between online database, diagram and geometry ...217

Figure 80 Overview of tables ...219

Figure 81 Objects table ...220

Figure 82 Architect criteria table ...221

Figure 83 Versions table of the Architect ...222

Figure 84 Users table...222

Figure 85 User chat table ...223

(12)

(13)

2 Acknowledgments

This book is about my research of mainly the last 3 years at the Faculty of Architecture of Delft University of Technology. My mentors Prof. Ir. Kas Oosterhuis and Prof. Ir. Leen van Duin I would like to thank for the possibility and support they gave me. My colleagues and students at Hyperbody I would like to thank for the pleasant cooperation.

Many thanks also go to the research committee: the Rector Magnificus, my supervisors Prof. Oosterhuis and van Duin, Prof. Hovestadt, Prof. de Vries, Prof. Duijvestein and Prof. Rots. A special thanks I would like to address to the team that was willing to test the developed method and prototype.

Throughout this dissertation the word ‘concept’ is frequently used. Since this word appears to be confusing in many research and design projects (Doorn 2004, Kleinsmann 2006), including this PhD research, it is important to make a difference in design concept, structural concept and installations concept. The architect when talking about the concept probably means the leading strong idea and the spatial layout. The structural advisor probably means the schematic diagram of the load bearing structure and its materials. The installation advisor probably thinks about the choice of heating, cooling and ventilation system and the schematic diagram that shows the conducts and equipment. The cost advisor thinks of the whole, but of course from the viewpoint of costs. In this dissertation the word is used to indicate all these conceptions of the word ‘concept’ together. When in this book the masculine form is used this is because of readability, not with the intention to exclude women. Writing everywhere “he or she” would become annoying.

(14)

(15)

3 Summary

In this PhD research a method and software prototype has been developed for collaborative architectural design in virtual reality. ‘Collaborative design’ stands for multidisciplinary working together from the very first beginning of a project. ‘Virtual reality’ stands for a simulation in 3D computer software in real-time. ‘Real-time’ means that it is not an animation, which is developed before, but direct manipulation of virtual cameras in a virtual environment on the Internet. This makes

collaboration over the Internet possible, e.g. if one or more members of the design team can not be present at the same location.

The reasons for application of collaborative design are:

• The big influence of decisions in the beginning of the design process on the cost/quality ratio.

• The potential contribution through knowledge and experience of all stakeholders at this beginning.

• The growing complexity of building projects, e.g. because of complex geometry, difficult locations in cities, underground building, building on water, the use of new materials and new building methods.

• The demand of guaranties of clients and the claims that different parties get because of building failures lead to the wish of these parties to have an influence on the design. • There is a waste of time and money in the actual design process where the advice of experts often comes too late because other developments changed the design already. Out of practical considerations this research is limited to a case where the design team consisted of an architect, a structural advisor, an installation advisor and a cost advisor who together developed the conceptual building design. Deviating from the tasks and responsibilities of every discipline as mentioned in Appendix 18, the design team was asked to execute the case study according to the method described below. An other

(16)

limitation is that this only takes place in virtual reality. The method and the prototype are based on twenty years of personal experience in building informatics, a broad search in literature of mainly proceedings of conferences in the domain of building informatics and the test of preliminary partial

prototypes in education. The design team tested the method with a prototype software application and a design case (Rotterdam Central Station).

The method consists of developing versions of a concept for a building and the evaluation of them with criteria. Every team member makes his own versions. This is necessary because it is impossible to work together on a concept if it is not clear yet that e.g. the building will be high or low. They would destroy each others work. The team members can evaluate the versions with a criteria matrix. I didn’t strive for a numeric validation system, because I prove that these are not valid. In stead I aim at a means to pay attention to many criteria and a way to quickly find the main differences in opinion. This should avoid loss of time because of discussions about subjects of less importance. The discussion should lead to a next version where advantages of earlier versions are integrated and disadvantages eliminated. I developed a software prototype in 3D programming software Virtools. This prototype supports the import of a 3D model of the environment and generates so called Functional Volumes on the bases of imported data from the Program Of Demands out of a spreadsheet or database. These data consist of the names of the functions, the desired area and indications concerning the

location and/or distance relations. Often the designer has to decide about the height himself. The program of demands is formulated by the client, or if the necessary expertise is not available, by the architect or project manager. These Functional Volumes have a so called swarm behaviour. Like bees in a swarm they follow certain behaviour rules that can be switched on or off. If e.g. the horizontal swarming is on, then an

adjustable number of parts of the Functional Volume will search a place next to each other at an adjustable distance. And if the behaviour Automatic Scaling is switched on, the total volume

(17)

will be constant. This accelerates the layout of the Functional Volumes in the virtual 3D situation.

Furthermore the prototype supports the evaluation of the versions with criteria matrices. The test showed however that the team didn’t reach this point within time and also filling in these matrices was not appreciated. The prototype is developed in such a way that the proposed method is not compulsory. It is also possible to start right a way with solo or collaborative design of one concept. This can be synchronic or a-synchronic, local or inter-local over the Internet. All data are stored in and exchanged via a database on an Internet server.

After choosing one or more concepts in order to elaborate on form, construction, installation and cost, the prototype supports the creation of 3D coloured lines. The architect makes yellow lines to indicate form, the construction advisor uses red lines for the load bearing structure and the installation advisor uses blue lines for the conducts and other equipment. A chat window with corresponding colours supports the exchange of thoughts and discussion. The cost advisor only uses this last way of

communication during the phase of elaboration of the concept. It is a pity that the team hardly used the coloured lines within the time limit. Chatting was confusing because of the intertwining of the threads.

The main conclusions of the research are:

1. It appeared to be possible to develop a working software application prototype in Virtools with which a

multidisciplinary design team can collaborate in a virtual 3D environment in real-time on the Internet.

2. Only the architect in the test team appeared to be able to develop a conceptual building design with this prototype within the limited time of twice half a day.

3. The advisors in the test team need training in developing and 3D modelling of conceptual building designs. Only after that they could be able to effectively participate in collaborative design of architectural concepts based on this method and prototype.

(18)

The last conclusion unfortunately brings the efficiency of

collaborative design on a lower level because training takes time and money. Estimations vary from 1 – 100 hours.

In order to design buildings that fulfil better the criteria of all stakeholders, training in collaborative design is necessary in the education of the concerned disciplines. As long as advisors are not trained as mentioned above, it seems reasonable to have the architect make the conceptual building design, eventually with real-time comments of the advisors. Only after the concept is ready, real-time data exchange between the members of the design team is relevant. That could be a follow-up of this research.

(19)

4 Introduction

The built environment is our habitat. This word is used in Ecology to address the circumstances that make species flourish or not. Most of our habitat is owned by different companies and institutes, but since we all have to work and live in this

environment it should be built with all stakeholders in mind. Who could better do this then the stakeholders themselves? This thesis is based on a research project in collaborative architectural design. It is supposed to improve the design of our built environment. Municipalities could play an active role in this. They should not only approve or ask for changes in the plans, but actively interfere from the start with the design of the habitat of its citizens. Municipalities could demand for design teams with delegates representing all stake holders (including the building professionals). Such multidisciplinary design teams can develop designs that fulfil the needs and demands of all concerned.

This research is a reaction on two developments in the building sector during the last 25 years: the application of Information and Communication Technology (ICT) and the phenomenon of design teams. The last development is mainly caused by two factors. Building contractors are confronted with clients that demand guarantees and high claims for failures. It seems logical that they want influence on the design and also ask for

performance specifications, where just as in the Dutch building regulations maximum and minimum values for properties of building parts are demanded, but no specific use of building products is prescribed (SBR 2007).

At the same time buildings get more and more complex, because of more attention for the (inside) environment, high rise

buildings, underground buildings, difficult locations, desired flexibility, new materials etc. This complexity is also a reason for the emergence of design teams; it just gets too complex for one person. Recent development of non-standard and interactive

(20)

architecture with sensors, actuators and kinetic structures ask for even more knowledge.

Figure 1 Hessing Cockpit Utrecht, ONL; an example of Non-Standard Architecture

The term non-standard architecture refers to computer generated complex geometry which can be observed in many

contemporary designs. With new parametric design software these complex designs can be adapted until the last moment and files can be sent to factories where the components of the building can be produced by computer numerical controlled processes that keep these complex buildings affordable. The term interactive architecture refers to a new paradigm outlined by my promoter, Prof. Ir. Kas Oosterhuis, who is also the director of Hyperbody at the faculty of Architecture of Delft University of Technology in the Netherlands and director of the renowned office ONL. This paradigm consists of the theory, methods and techniques that make the concept possible of architecture displaying a real-time behaviour. This behaviour is sometimes triggered by users, but can also be pro-active and gives more identity to the buildings.

Interactive architecture is an architecture that reacts on changes in the environment and causes them too. In many fields we can see an increase of interaction: cars show the way and beep when driving backward too near an object, TV-sets and phones

become web browsers, and kitchen equipment has many

(21)

interactive parts: automatic doors, intelligent heating and ventilation systems, elevators etc. But Prof. Oosterhuis not only expects this kind of practical interaction, he also foresees emotive architecture where building parts act and react as a swarm of birds creating a new type of environment.

The development in ICT is gigantic. Twenty five years ago only a few architect offices worked with computer systems. The Union of Computer using Architects in The Netherlands (VCA) was founded in that period and I was director during its last six years until 1995. Foreign CAD-systems had to be adapted to the Dutch situation and big flexible floppy disks, where no more than 1 Mb could be stored, were the only way to exchange data. And the data were not exchangeable between different systems. In 2001 data are exchanged in 33% of the projects of bigger building companies (Dolmans 2001). But mainly in the later phases of the building preparation; design is still badly supported by CAD-systems.

Now we are facing a new challenge to let partners in the building industry use each others data in real-time over the Internet and besides also walk through it in virtual reality. 3D multiplayer game technology makes this possible. Again a technology has to be applied in the building practice: COLlaborative Architectural Design in VIrtual Reality (COLADIVIR).

At the start of this research in 2003 the members of Hyperbody were asked to write an essay about the use of Protospace as collaborative design environment (Figure 2). My contribution was a 7 page description of a case, the new railway station area in Delft (unfortunately in Dutch and not published). It tells the story of an imaginary session from the point of view of an urban designer of the municipality who is sent by the deputy mayor to participate in a collaborative design session. A similar

description has been published by Penn (2004), only more aimed at designing with head mounted displays. This kind of exercises gave many ideas about how to support a group in Protospace with speech recognition, gesture tracking, simulation

(22)

techniques etc. Many of these ideas have been searched and developed into actual interfaces, mostly by other members of Hyperbody. For my thesis I focussed on what would happen if some of the team-members can not be present in Protospace. How can they still participate?

Besides, at that time it was not at all sure that iWEB/Protospace would be realized and COLADIVIR could not be depending on that. Also multiplayer game techniques over the Internet are fascinating to me. When I see my sons playing games with friends from all over the world in amazing realistic virtual reality, I think that a multiplayer game of architectural design should be possible too (Hubers 2004).

4.1 Reasons for collaborative design

One of the reasons for this research was that Prof. Oosterhuis got the idea to reuse the pavilion he designed for the temporary agriculture exhibition Floriade 2000. It became the iWEB, with the collaborative design space Protospace.

Figure 2 iWEB and Protospace

Since this pavilion had screens in a circle for a multimedia show of the North of Holland province, a function for collaborative design at Delft University of Technology is appropriate. I will

(23)

write more about this project in chapter 6 and 8.

Collaborative design also emerges from the insight that the quality of buildings rises by good teamwork and the cost decreases (Habets 2002). It is a well known fact that most influence on the cost/quality ratio of a building lies in the very first conceptual design phase. Figure 3 shows this; a comparable figure is found in Berenschot Osborne (1992). It seems therefore a good idea to develop a method that permits all (or at least the most important) stake holders to design the concept together from the start. They can bring their specialised knowledge to the project and so prevent that the design starts on the wrong foot.

Figure 3 Potential cost saving (Love 1998)

In the traditional design process the architect first makes a sketch design based on a Program Of Demands. He then asks a structural advisor for a proposal for the construction. Because the advisor has other projects too and wants to make some calculations, this often takes some weeks or even months. A model has to be built in specific software, only partial

compatible with the software of the architect. After integrating the construction in his design the architect might ask other advisors for suggestions. E.g. an installation advisor, cost

(24)

advisor, ecology advisor etc. It then may happen that in the meanwhile the client already changed ideas and the whole process has to start over again. To avoid this waste of time and money a real-time collaborative design method is needed. Why is collaborative architectural design not normal practice yet? Maybe because there is not a good method, maybe because appropriate software is lacking (both reasons are addressed in this thesis), maybe because the people that could benefit from it have no power or how, or the people that have the know-how don’t benefit from it, but maybe also because

responsibilities could get mixed. The architect normally is responsible for the good functioning of the building and the structural advisor for the structural safety. What happens if they start making decisions together? Even more troublesome it becomes if the principal becomes a member of the design team? Where should the claims go? This is not the subject of this thesis, so we assume an answer to this question. The answer would be, that all team members keep their traditional responsibilities and thus have a right to decide different from what the team proposes. Collaborative design does not

necessarily mean that decisions are taken democratically. The method that this thesis proposes tries to take advantage of the know-how of the team members and supports the generation of ideas and discussion about those ideas but leaves it up to the team how decisions are made and what method of collaboration is used, if at all.

When we write about collaboration between the different professionals in conceptual architectural design we first have to deal with data exchange. There are basically two ways to go. Either team members use their own software, or they all use the same (newly developed) application. In the first case data exchange is a much bigger issue than in the second. Being much involved in research in this field in the eighties and observing that very little progress has been made since then, it seems wise to choose the second option. Recent work of Hyperbody, especially by Christian Friedrich, however shows that there are interesting possibilities for real-time connections between

(25)

software applications based on XML (a flexible general language that most applications adopted) and open API-s (Application Programming Interfaces). But this development was after the results of this thesis and aims at avant-garde architecture with preferred software connections and not only the conceptual stage. For recent developments see

www.hyperbody.nl. This thesis aims at a general solution for collaborative conceptual architectural design and only in the very first conceptual stage. I will come back to data exchange in paragraph 4.5 Historical background.

4.2 Aim of the research

The aim of the research is to develop a design method and prototype software application for COLlaborative Architectural Design In Virtual Reality in the early conceptual stages of innovative projects. The method will be tested with a prototype software application by a professional design team in a case study.

4.3 Definitions

In scientific research it is necessary to define the issues, concepts and unusual words that the research uses in order to avoid misunderstandings. The aim is a method and a prototype. The prototype has to support the method and makes it possible to test if the method works. What is a method? What is a prototype? What is collaborative architectural design? What is Virtual Reality?

A method is a procedure, a way of working that normally will be followed under certain circumstances to reach a certain goal. It consists of a number of interrelated processes which can be put into a scheme, a process model (see Figure 59 COLAB IDEF-0 Process diagram on page 145).

A prototype in this case is a software application that has all the functionalities and interfaces that a commercial application should have, only parts of such an application that are not

(26)

necessary to test user satisfaction are not necessarily there. E.g. the maintenance of the software is not taken in consideration and the execution speed can be lower (unless speed is a crucial criterion in certain parts of the application). Also the style of the application, the layout, form, colour of the interface can often be neglected.

The goal of the method is innovative architecture. This must be seen as not exclusively innovative architecture, but also standard architecture, however not all kinds of architecture. The method that is needed to design an airport (Braaksma 1973) is quit different from the method to design a house. Therefore we take a case: Rotterdam Central Station, where the program shows many different functions like ticketing, parking, transfer of people, shops, offices etc.

The circumstances in which this method should be reliable are best described as synchronic and a-synchronic, local and inter-local. “Synchronic” means that team members can work together in real-time. But if somebody is not available or if the design process has to pause, a-synchronic working must be possible too. “Local” means that the method can be used by a design team at a certain location, but if somebody can not be present, then inter-local collaboration must be possible too. This means in this research that the method should work over the Internet. Virtual reality means that 3D computer software must be used in order to give the user an impression of what the design will be like in real-time.

Part of the circumstances is also that the method should be executable by a certain type of design team. Again we take a case: the team consists of an architect, a structural advisor, an installation advisor and a cost advisor.

Also the time to develop a concept (we limit the circumstances also to the conceptual stage) should be part of the method. Since the design team consist of expensive professionals and any way in most cases there is not much time to develop a concept (e.g. the land is already purchased and this investment is waiting to

(27)

become profitable), the aim is to develop a concept within 4 hours in the case of Rotterdam Central Station. Stellingwerff (2005) gives a good reason for such concentration: “Thus, in

each phase of the process, the main tasks of architects and their collaborators change. Likewise, it can be assumed that the tools and design-media to create and manage the design should adapt to the changing needs of the designers. Therefore, distinct research in addressing the role of design media and working methods should focus on one phase at a time.”

What is collaborative architectural design? This needs more explication than the above defined items. In next chapters we will have a close look at architectural design and possibilities to do it collaboratively. For now let’s define it as “architectural design with a multidisciplinary team from the start of a project”.

There is of course much more to say about the different parts of the aim of this research. This will be done in next chapters.

4.4 Method of the research

In many scientific research projects we see a well known method of research: hypothesis, analysis, syntheses. Or like Moughtin et al. (2003) describe: theories, hypotheses,

observations, empirical generalizations (see also page 62). Or like Priemus (2002) describes: observation, induction

(formulating hypotheses), deduction (verifiable predictions), testing, evaluation (hypotheses are confirmed or rejected). Without no doubt this research could be described like this and actually was executed partly with this method. The hypothesis could be that a method where every team member develops versions for a conceptual architectural design and where a criteria matrix is used to evaluate those versions, and this entirely in real-time over the Internet using a Virtools prototype (see page 122 and Appendix 3), will improve the efficiency of collaborative architectural design. Analysis could be the use of literature, rapid prototyping and the test case. Synthesis could be the evaluation and conclusions.

(28)

What Priemus writes about system analysis is very suitable for the method that was developed for collaborative design:

formulating the problem (this became importing the program of demands), identifying, designing and screening possible

(solution) alternatives, constructing and using models in order to predict results, comparing and classifying the (solution)

alternatives.

I could describe in more detail the hypotheses, but this is not the way a research like this takes place. It seems to me a rather silly exercise to bring this approach in afterwards. In reality another method of research was used. In the NOBI-BBB project (Jongkind et al. 1994), Geert Smeltzer, head of the research institute CALIBRE of Eindhoven University of Technology at that time, said “research is finding answers to questions”. The simplicity of this method is appealing. The NOBI-BBB project will be described in the paragraph about the historical

background.

The difficulty is to ask the right questions and often (partial) answers lead to new questions. The main question of this research is how to realize the aim as mentioned before. Then this decomposes in questions like “What is…?” and “How do we…?” and why, who, when etc. Sometimes answers are found in literature, sometimes by little experiments with partial

software prototypes and trial and error with students. In fact our master students helped a lot in exploring the field during my Research & Design Method classes. They stored there questions and answers in a database next to mine. As an exercise for the students to write about a new development I developed parts of the prototype software with them, where they often were very inspiring.

We always used the criteria ‘reliability, validity, openness to critics and scientific relevance’ when gathering and creating information (De Jong 2002). This means that we tried to use and generate information that is objective, verifiable and thus

reliable. Validity has to do with using the right measuring method. So instead of asking how much time somebody spends

(29)

on developing a concept, you better register time stamps in a database so you can objectively calculate the time spend. The conclusions of the research that will be described show problems with this criterion of validity. We will come back to this. What happened two phrases before is called openness to critics. The results are presented in such a way that the conclusions can be questioned and are questioned by the researcher himself. Scientific relevance is measured by evaluating how much new information was added to already existing information. E.g. the database of summaries of literature in the form of questions and answers was always checked before adding new information.

Figure 4 Literature database

Together with the students we developed a method to review and summarize relevant literature. We developed a template where in the first section all the relevant information for

(30)

references is put in. The next section contains a little general summary and then the most important section lists the questions and answers that are relevant to our research and which could be derived from the source. Finally the relevant references of the document are mentioned. The first section and the question and answers sections were pasted in an Excel spreadsheet where a macro keeps the questions and answers clearly ordered. Another macro makes it possible to highlight all the articles where a searched keyword is mentioned. The idea was that a conference paper (the assignment for the students) or the dissertation could be written by putting the questions and answers in the right order taking the highlighted text as references.

Figure 5 Questions and answers

In practice this didn’t work out, because the students - and me too sometimes - were not able to construct questions directly in a usable form. Instead this thesis is written with the documents

(31)

at hand, which were selected on the basis of the summaries. All the summaries and the database were stored on Black Board, an Internet site often used for file exchange in our education. In this way everybody could access the files and keep them up-to-date. The database is used to check if all relevant information was used in the dissertation.

Stellingwerff (2005) uses Protocol Analyses, combined with recorded virtual walks, conversations and drawings from memory after some weeks. Protocol Analyses are usually applied for large number of participants in an experiment, thinking out loud. Then the text is reviewed and coded. But I agree with him that anecdotal evidence is inevitably relevant, that it is reproducible and that it may provide valid knowledge on the level of hints, suggestions and impulses for further, possibly more precise, follow-up research. Stellingwerff writes extensively about his ‘design driven research method’. I will not repeat this here. On page 90 Stellingwerff compares the research to biological ‘in vitro’ research as opposed to ‘in vito’. On page 131 he states: ”On the other hand, it was experienced that

Protocol Analyses leave out many subtleties.” On page 151 he

states : “Conclusions may be drawn in different ways.

Conclusions can be based on insights and findings and do not always need quantification.”

With this in mind the research method becomes: develop a method, develop prototype software that supports the method and that can be used to test the method. Develop the prototype in such a way that all actions of the test group are recorded for analysis. Everything can be replayed as a movie, also in slow motion. It also should be noticed that the setup of the case study was aimed at evaluating the total proposed method and not only an easy verifiable part.

At the end of the research project we evaluate the results. It is obvious that this moment is not before the testing of the

prototype software with a target group. But since it is prototype software, how far does the research continues improving the prototype with the remarks of the target group? There is no good

(32)

answer to this question. Therefore it seems to me that for a PhD research the moment is right after the first user test. The

feedback of the test group can than be reported as the start for eventual further research and development. Also this last word shows that this is the moment where a PhD research should stop and a commercial development should start. That is to say if the results are positive. This seems rather clear and logical, but what if the result is not positive, what if the hypotheses are not

confirmed, what if the main question is not positively answered, or in this case, what if the test group is not able to develop a collaborative design with the prototype software?

Stellingwerff (2005) states that an experiment is successful:

• if it clearly supports or rejects hypotheses,

• if it proves the effectiveness or weaknesses of the prototypes, • if it provides new (unexpected) insights and

• if new theories, new techniques and new questions are generated (page 103).

And on page 255: “A research initiative may be considered

successful if relevant issues, characteristic phenomena and theoretical considerations are addressed and studied in such a way that a contribution is made to the existing body knowledge and/or state of technology, whereby new theories may be put forward and further study may be stimulated.” I agree with that.

4.5 Historical

background

This thesis is based on my own experience with the design and feasibility studies of an ecological office building for the interdisciplinary centres of Delft University of Technology (Hubers 1986), projects I did with the Union of Computer using Architects (VCA), literature studies and more recently the experience at Hyperbody.

The design of the ecological office building was guided by Prof. Kees Duijvestein and supervised by Prof. Tjeerd Dijkstra. They both helped me to systematically develop a design that takes all possible criteria into account. Prof. Dijkstra was

(33)

and was involved in the new building regulations which had much to do with the criteria that were used for the ecological office building design.

The whole idea of ecological design implies that one takes as many influences into account as possible. In fact I developed a design method that intermittently generated ideas and evaluated those ideas with criteria. Completing the criteria helped getting ideas for the design. Developing ideas also often brought up criteria. I used different techniques to get the list of criteria as complete as possible.

Figure 6 Ecological office building “Het Ei” (Hubers 1986) The combinatory method I remember. This consisted of creating categories that were then combined in all possible combinations in a matrix. Unusual combinations then suddenly bring criteria in mind that otherwise nobody would think of. I defined categories as relations to all the spheres: cosmos (sun, moon, and planets), atmosphere (wind, rain, and snow), hydrosphere (water), biosphere (people, flora, and fauna) and lithosphere (land). Later I rationalized the list into the one that is used in the case study (see Appendix 1 Criteria Matrix).

(34)

The ecological office building became a research object for many graduates of different universities and many innovating building techniques were developed. The most important

criterion for realizing the building became the yearly cost. I was offered a job to guide the feasibility study at one of the future occupants, the Centre for International Cooperation and

Appropriate Technology. After two years of research into many domains, often with personal computers that just emerged at that time, a graduate student of the faculty of Civil Engineering calculated that the return of investment would be negative. A professional office confirmed the calculations. Still many stakeholders found that the experiments were worth while, but the money to invest was never found. In the meanwhile I organized some international research and education projects about generation and evaluation of designs with personal computers and the board of the association of computer using architects (VCA) offered me a job I could not refuse. That was the end of this project, but the beginning of an interesting time of integrating computer techniques in architectural practice. The use of CAD systems in regular architect offices started in the 1980’s in the Netherlands. Most systems were not adapted to the Dutch situation. Therefore about 200 of the bigger offices united in the VCA, the association of computer using architects founded in 1984. I was director from 1989-1995. Different CAD-groups (AutoCAD, CADVANCE, Arkey/Arcos,

Architrion) met at each other’s offices to exchange information and to develop libraries of typical Dutch elements like isolated double brick walls and details of connections to e.g. window- and doorframes. In the beginning these CAD systems were 2D and only used for the production of drawings.

When the most important user issues were solved, the CAD-groups were taken over by the software developers/resellers. VCA started a new overall CAD group called FANFARE, with a project to improve the exchange of data between different CAD systems and -more important- the interchange of CAD operators. I’ll come back to this project below.

(35)

Around 1990 a user group was formed for budget, estimations and specifications, the VCA-BBB group. The CAD systems developed in the meanwhile quantities output, but it was not in the way the cost experts could use it. E.g. they would need the circumference of casing of the floor, but the CAD operators didn’t draw a line with that label. And this was only one of many wishes. A big project was needed with a considerable budget. The only way to get the budget was to participate in the national research project NOBI, obliging this rather practical VCA-BBB group to look into ISO/STEP and process- and product diagrams like IDEF and NIAM. The abbreviations stand for International Standard Organisation/Standard for the

Exchange of Product model data. IDEF is a process modelling method and NIAM a product modelling method. Also the project had to broaden to installation engineers who were leading in the field of data exchange and requested usable input from architects CAD drawings. The project, with an original budget of € 1 Million (guilders at that time), was a success. The prototype developed in cooperation with the University of Eindhoven was demonstrated, tested and approved by the VCA-BBB group, but then the software developers, who were in the comment group, decided not to implement the specifications in their software. The reasons they gave were that it was too much focused on the interest of architects and not enough on that of building contractors. But probably the real reason was that they didn’t want to invest.

Another interesting project of VCA was the FANFARE project. This project was aimed at standardization of use of CAD

systems in order to work more efficiently and to enable the exchange of data. The origin of this project was the wish of the VCA board to exchange CAD operators. It became more and more a problem to find skilled CAD operators in the specific systems. The idea was that if at least they learned to work with the same method the learning curve for temporary CAD operators could be steep. The project started with a little

subvention to interview 9 outstanding offices and to conduct an international survey with enquiries and literature research. The result was 135 pages of inventories, but there never came a

(36)

budget to bring it to a standard way of CAD in architecture. VCA also stopped at the end of this project.

The board of VCA decided in 1995 to integrate with the general foundation of architects BNA. The reason they gave was that offices paid double contributions, but some also thought that data exchange with other building partners is not advantageous for architects. They have to do more work and invest in systems while the other partners in the design can take profit of the improved data exchange. This would explain why since then the developments in this field have been very little.

We can learn from this that, while buildings become more and more complex, data exchange is not soon without problems. The parties that have the most profit of this don’t have the power, knowledge and money to solve this.

The software developers/resellers united in the Dutch

association FORUM. They developed a CAD exchange format with the same name. It wasn’t a success because some parties refused to accept it. Recently some members of this group started a project called The Digital House, representing 70% of Dutch architectural offices (40% AutoCAD and 30% Arkey). This group is planning to develop de facto standards for the exchange of data between different partners in the building industry: architects, construction advisors, installation advisors, clients, council and building contractors. But it will not be an open standard; members only (Het Digitale Huis 2007). Above is a description of the most important developments I personally experienced and much of it in international context. To broaden this knowledge a literature research was undertaken. Some general references are reported here. More specific

references are used in the other chapters.

De Vries in his dissertation “Communication in the building

industry” describes the international developments in data

exchange and proposes a Message Exchange Model (Vries 1996). He first explains what communication is and how this is related to ICT. I don’t repeat this information here. It has to do

(37)

with signs, syntax, semantics, pragmatics and the relation to the Open Systems Interconnection model of ISO. He also introduces ‘the meaning triangle of Sowa’ where an object refers to a concept that is symbolized by a sign that stands for the object. Here lies the basic problem of the communication in the building industry. The signs that are used are not always standing for the same objects and are not always interpreted in the same way. To solve this, standards are necessary.

This seems of course relevant for COLADIVIR. However the international standards for Product Data Management (PDM) and Product Data Interchange (PDI) appeared to be not applicable for innovative concept development, which is the scope of COLADIVIR. Still this publication is an important reference for later stages. It explains for instance that there are 2 situations in data exchange:

• Information stays as it is. In this case the data structure of the sender and the receiver has to overlap.

• Information is translated. This can be either by human interpretation or by a set of rules in a computer system. In both cases the information has to be mapped which result in data loss if data structures are not identical.

Translating information is mostly done to a neutral data format, a kind of Esperanto, like ISO/STEP. About ISO/STEP de Vries writes: “As with all emerging standards there are considerations

and circumstances that hinder the achievement of the ideal situation” and he points out that definitions can become

outdated, that already existing data structures in companies and their applications don’t match and have to be mapped and that standards must be adopted by government or other driving forces of sufficient weight. Although many CAD programs have STEP in- and output (STEP 2007) the impressive STEP

community seems not satisfied with the developments and e.g. complain that XLM standards are developing much faster. One reason might be “The government does not like to pick solutions

for industry, and industry does not like to fund the development of solutions that can also be used by their competitors”

(38)

XML format for STEP is under development. Besides ISO/-STEP and its application protocols AP2003 Configuration Controlled Design and AP225 Building Elements Using Explicit Shape Representation de Vries also describes the Building Product Model (BPM), Business Transaction Management System (BTMS), the different classification and coding systems like SfB and STABU, Electronic Data Interchange for

Administration, Commerce and Transport (ISO/EDIFACT), Engineering Data Model (EDM). He then develops his Message Exchange Model (MEM) which, and this is important for COLADIVIR, explicitly describes the information at any moment during the building project. Indeed it is important to be able to loop back to earlier states and restart from there.

Anyway it is obvious that these standards don’t help to collaboratively design a concept for an innovative building. They don’t tell how to work, but only in what format to exchange the data if you use different applications. They are only usable after the concept is defined and detailed models from different software applications have to be exchanged. Another inspiring publication is the ACCOLADE proceedings. Next a summary of contributions that is most relevant for collaborative architectural design.

Glanville (2001) from CybernEthics Research Southsea, Hants, UK: “For me, collaboration is more than operation or

co-ordination. It must involve novelty, the creation of something beyond the expected and more than an improvement – a quantum step.” He stresses the art of listening and also argues

that efficiency alone is not enough reason for collaboration: “There are qualities other than usefulness that are of value – are

of greater value. One is creativity and novelty. To be trapped by the useful is to be trapped the banal. This is an argument for the other than useful, rather than against the useful.” … “What I do decry is the valuing of collaboration exclusively for the benefit of efficiency: unless we so define efficiency that it includes joy, imagination, variety and delight, efficiency is a poor criterion, a poor single aim.” He also wants the computer to play an active

(39)

role with a behaviour of its own and provide a place for collaboration. This corresponds well with our ideas at Hyperbody. Last remark is what COLADIVIR is about. Gavin (2001) from the Bartlett School of Graduate Studies University College London reports on the Bartlett world which is made in Eduverse, the educational part of Active Worlds (see also 7.1Examples on page 99). The international students were asked to have all design discussions on-line. It was not an investigative research project, but nevertheless some remarks: students found that sketch facility was missing and made some web pages for that. At the evaluation however a number of students insisted that sketch models and text descriptions were certainly sufficient. Another issue that we can learn from this experiment is the reluctance of the students to through away their individual virtual design models. This questions if we can just have all team members design a part of the building. Heintz (2001) writes about coordination. His contribution will be discussed in 6.3 Coordination on page 78.

Pittioni (2001) states: “Co-operation between planning partners

is done, but with delays, which come shorter and shorter. Collaboration is not always done, often too late and it will be possible in the near future but we – or some of us – will have to reflect on our working habits and we have to find ways of

streaming together data of various partners…” This corresponds

very well to the findings of COLADIVIR.

Brown and Berridge (2001) work at the CAAD Research Unit, School of Architecture and Building Engineering, The

University of Liverpool. They have very similar approaches as we: using game theory and VR for collaborative design. They developed the Sustain Game, where players can get used to collaboration by means of a matrix of three main fields: economy, community and environment and three main

conditions: robust, stable and fragile. The game consists of the urban development of a region. Cards are dealt representing projects. The players must then decide if the projects fit with

(40)

their strategy for the region. Since designers are not the final decision makers, a dice is thrown where 1-4 means that the project is accepted and 5 and 6 means that authorities reject it. A Web based version has also been published. The game has been very successful in both education and practice (Highland Perthshire Communities Partnership). One reason for this the authors believe is the construct of a common ground. They reason that for collaboration a common language (in the broadest sense) is necessary and extend this to overlap of knowledge. The authors state, “…as viewpoints become more

diverse, collaboration becomes more difficult. Mutual understanding is a prerequisite for effective collaborative working.” This is too strongly put, because also if some

specialized knowledge is required, which some members of the team can not understand, then still collaboration is possible. In that case the team can either leave the decision of that part to the specialist or discuss the possible consequences and than decide by voting. An example is given of an architect in USA talking about the first floor, which in England is called the ground floor. Of course misunderstandings will always happen, as they do in every day life, but this doesn’t mean that collaboration is not possible. Longtime we thought that data exchange should also be perfect and went into large systems of coded definitions and synonyms, which became unpractical. Now we believe that through (artificial) intelligence and fuzzy logic it will be possible to solve this kind of misunderstandings. And for the time being in the actual communication this kind of

misunderstanding is quickly discovered and solved. The authors also give an answer to the question of what collaboration is. Co-operation involves agreeing on task

assignment; collaboration involves tackling those tasks together. Co-ordination is helpful in avoiding errors in information

transmission, but collaboration means that this information should be understood and agreed. Here we differ in opinion again. It is like making decisions in parliament: not everybody understands the ins and outs of everything, but still they collaboratively make decisions by voting. This parallel can be

(41)

drawn also for non-democratic decision-making and the conventional process of architectural design where an architect takes decisions as a dictator.

The question why collaborative architectural design should be promoted is answered with the example of Centre Pompidou and Lloyds of London where Peter Rice as engineer and Richard Rogers worked together. Rice is quoted “Good teams are made

up of different people: people whose separateness and attitude complement each other and who, by their individual willingness to work together and accept the presence and contribution of others, for a while at least make possible real momentum.” That

corresponds more to our definition of collaborative architectural design.

Game Two consists of an application in the Eduverse, the educational part of Active Worlds, called Erehwon. Surprisingly the same virtual worlds are discussed as in Maher (2002) where this source is not mentioned. Interesting is that the authors developed Erehwon initially not as a representation of a real environment and state that in a virtual world the need for a real world analogy is debatable (p.108). Elsewhere they argue that avatars should have a range of appropriate expressions (p.107) and they quote Slater (2000): “Group accord tended to be

higher in the real meeting than in the virtual meeting. Socially conditioned responses such as embarrassment could be generated in the virtual meeting, even though the individuals were presented to one another by very simple avatars. The study also found a positive relationship between presence of being in a place and co-presence – the sense of being with the other people. Accord in the group increased with presence, the performance of the group, and the presence of women in the group.”

So should a virtual working environment resemble to a real environment? Should avatars represent team members of a collaborative architectural design team? These are interesting questions, which are best answered by testing a non-realistic virtual working environment without avatars. If this works fine,

(42)

then much computational ballast can be avoided. If

embarrassment is generated because of misunderstanding or wrong interpretation of chats, then we should consider other means like avatars or video conferencing. It is not unlikely that embarrassment will be avoided, if the chat is structured in such a way that only professional communication about design

proposals and their evaluation is possible. It is well known and personally experienced that e-mail sometimes leads to angry reactions because of misinterpretation of messages that are too short or simply multi interpretable and that people tend to use emoticons like ;-) to avoid this. But it could be that this is in more general communication where emotions are at stake, while the collaborative design I would like to support should be efficient, professional and aimed at innovation. Not a place for personal feelings.

The test in COLAB (see chapter 10 and 11) showed that only chat is not very satisfying for the team. This can also be seen in the chat (see Appendix 2 Chat) “I think we are more in

Babylon” and “You don't know who is doing what at a certain time”. The advantage is that all communication is recorded in a

searchable way, but apparently the team has trouble with parallel discussing different subjects. A solution for this would be a forum kind of layout of the chat, where different subjects have their own thread. The remark “You don't know who is

doing what at a certain time” is due to a misunderstanding of

the method. The method proposes separately working with functional volumes and collaboratively working with coloured lines. Every team member has his own colour, so in the

collaborative part it is clear who is working on what object. But the main issue in the result of Slater (2000), the accord in the group, is evidently not reached. It is obvious that a face-to-face meeting would have led much easier to accord. But that would be because of strong persuasive personalities and not because arguments are better discussed leading to a balanced decision. And that is what we are after in collaborative design.

A third game in Brown and Berridge (2001) is about navigation in VR. A bicycle is used to navigate through a virtual city. This is a somewhat limited view on what a design team needs to

(43)

interact with the design, but of course a legitimate experiment to find more intuitive interfaces.

Achten and de Vries (2001) are from Eindhoven University of Technology. They give a short historical overview of VR, and state “The current state of Virtual Reality (VR) however, seems

limited to presenting relatively static models of more or less finished designs without much support to change elements of the design. …It is mainly used in later design stages…. One of the reasons for this lack of design support seems to be the rather cumbersome interface to create and change a design in VR.”

Therefore they developed a 3D sketching tool that following a pen stroke creates multiple linked blocks; also curved strokes are possible. It seems a nice tool for experiments by students. The question is though how many designers will find this way of 3D sketching useful in the early stages. The authors name

Wiegerinck Architecten in Arnhem, who used it complementary to AutoCAD and 3D studio. They suggest extension of the possible shapes and navigation possibilities.

4.6 Recent

developments

Are there any recent examples of collaborative architectural design? To answer this question we can first search the Internet. But a search on AltaVista and Google for “examples of

collaborative architectural design” resulted in 0 hits. A search

on AltaVista for “examples & collaborative & architectural &

design” gave 108.000 hits. "examples of collaborative" & "architectural design" give 15 hits, but all related to education. "examples" & "collaborative architectural design" 10 hits and

also included some links to VR-system and software developers, who were known to us, and will be discussed in the chapter 6, 7 and 8. "Collaborative architectural design" gave 125 hits. They were all explored, but none gave an example of collaborative architectural design in practice. In further research we stumbled into some vague mentions of collaboration during the design of buildings like Centre Pompidou in Paris (Andre Brown in Accolade), ING headquarters (remarks of colleagues) and some others, but it always turned out that some partial cooperation had

(44)

taken place, but certainly not collaborative architectural design in the early conceptual stages of innovative projects. Van Loon (1998) en van Gunsteren and van Loon (2001) report some examples, but more on the preparation of the design than the design itself (see also paragraph 6.2).

It is good to notice that collaborative design is sometimes named concurrent engineering, co-design, multidisciplinary,

interdisciplinary, transdisciplinary or interorganisational design or even integrated design.

The EC funded project ARTHUR described in (Fatah 2004) and (Penn 2004) comes closest to what we want (see also 7.1

Examples). The ARTHUR project is an augmented reality application through Head Mounted Displays with simulation of pedestrians influencing the collaborative design.

Figure 7 The ARTHUR project (Fatah 2004)

The software is VRML based and integrated with Microstation. The project was executed by the Bartlett Graduate School, University College London, Fraunhofer FIT, Aalborg University, SaabAvionics, Linie4Architekten, Foster and

Partners. ARTHUR was used in three simple design assignments with students and visitors of a computer fair. Some observations have been made, like the change in design method with or

(45)

without the system. But the assignment was too simple to take the conclusions serious. Of course are team members inclined to play around with virtual pedestrians and are they not thinking of that without VR, but it is also not a crucial criterion. We should even worry about the fact that it obviously distracts them from more important work. Pedestrian flow can be important of course, e.g. in situations where quick evacuation is important. But that was not the case in this research and then the behaviour should be well simulated and not only guided by openings between blocks.

For examples of collaborative design we have to look at other fields of technology. E.g. in the space craft, aeroplane and car design collaborative design is very common (see chapter 8 Parametric design). Software products are commercially available that support collaborative design in these sectors (http://www.3ds.com/home). However the collaboration appears to be not without problems (Kleinsmann 2006). Kleinsmann wrote her dissertation “Understanding collaborative design” at the Product Innovation Management research group of the faculty of Industrial Design Engineering in Delft University of Technology. She analyses two projects. One is about the redesign of a truck and one about the installations in a tunnel of a high speed train. In both cases she found a considerable amount of barriers and enablers on different levels. She distinguishes:

On the actor level:

• The ability of actors to make a transformation of knowledge • The equality of the language used between the actors

On the project level:

• The efficiency of information processing • The quality of project documentation

On the company level:

• The organization of resources

• The allocation of tasks and responsibilities

It is striking how many similarities with COLADIVIR can be found in this recent dissertation; e.g. the misunderstanding of the word “concept” and the most important conclusion of my

(46)

research that participation in the conceptual design phase requires knowledge that specialists often lack. On page 26 she states that research and her own interviews in this field show that “the different knowledge bases of the actors hamper

communication. This makes that the actors are not able to create shared understanding about the design they are making.”

It is surprising that while these problems are unsolved, commercial software exist for collaboration in these fields. AutoDesk also developed software to support collaborative design. It is called Revit. Allready many projects have been made with this Building Information Model (BIM) based software. In the Frequently Asked Questions session of the website (Revit 2005) is stated: “ Worksharing distributes the

power of the Autodesk Revit Building parametric building modeler across the project team. Worksharing provides a complete range of collaboration modes, from on-the-fly, simultaneous access to the shared model, through the formal division of the project into discrete shared units, to complete separation of project elements or systems into individually managed linked models. Worksharing enables team members to choose the best way to collaborate and interact based on workflow and project requirements.” But the documentation

shows that the product aims at traditional building methods, and though they claim to support the conceptual phase there is no mention of generating functional volumes, tools to layout these volumes over the 3D site and some support for the design team to make decisions. And the collaboration is limited to only AutoDesk products.

In stead of buying and trying existing software developed by companies with no or very little experience in architectural design, as we did already for so many years, this research proposes to define a collaborative architectural design method and develop a prototype to test this method. The idea was that if the result was positive a software company would be invited to work together on a commercial product based on the functional specifications and experiences with the prototype.

Collaborative architectural design in virtual reality