Design Phase and Scale Level Transitions in a Digital Building Model by Stefan Boeykens

KATHOLIEKE UNIVERSITEIT LEUVEN FACULTEIT INGENIEURSWETENSCHAPPEN DEPARTEMENT ARCHITECTUUR, STEDENBOUW EN RUIMTELIJKE ORDENING AFDELING ONTWERP–EN BOUWMETHODIEK Kasteelpark Arenberg 1—B-3001 Heverlee

Design Phase & Scale Level Transitions in a Digital Building Model

Promotor: Prof. Dr. Ir. Arch. Herman Neuckermans Members of the jury: Prof. Dr. Adhemar Bultheel (Chairman) Prof. Dr. Ir. Arch. Frank De Troyer Prof. Dr. Ir. Bert Lauwers Prof. Dr. Ir. Arch. Ann Heylighen Dr. Ir. Arch. Ann Hendricx (UGent) Prof. Dr. Ir. Bauke de Vries (TU/Eindhoven)

Proefschrift voorgedragen tot het behalen van het doctoraat in de ingenieurswetenschappen door Stefan Boeykens

15 October 2007

c Katholieke Universiteit Leuvenâ&#x20AC;&#x201C;Faculteit Ingenieurswetenschappen Arenbergkasteel, B-3001 Heverlee (Belgium) Alle rechten voorbehouden. Niets uit deze uitgave mag worden vermenigvuldigd en/of openbaar gemaakt worden door middel van druk, fotocopie, microfilm, elektronisch of op welke andere wijze ook zonder voorafgaande schriftelijke toestemming van de uitgever. All rights reserved. No part of the publication may be reproduced in any form by print, photoprint, microfilm or any other means without written permission from the publisher. ISBN 978-90-5682-869-1 Wettelijk depot D/2007/7515/103 UDC 721.011:681.3

Preface This research would not have been possible without the continuous support of my Promotor, Professor Dr. Ir. Arch. Herman Neuckermans. I also want to thank the members of the Reading Comity, Professor Dr. Ir. Arch. Frank De Troyer and Professor Dr. Ir. Bert Lauwers, for their valuable feedback. Further on, the members of the jury, Dr. Ir. Arch. Ann Hendricx, Professor Dr. Ir. Bauke De Vries and the jury chairman, Professor Dr. Adhemar Bultheel. This research project has been partly funded by the Catholic University of Leuven (Belgium) with reference Research Fund, K.U.Leuven (OT/2000/18). A special “thank you” for Ann Hendricx, who defined the object model which formed the foundation for the IDEA+ system and Benjamin Geebelen and Bart Geeraerts, who developed the first embryonic version of the data structure. Further on, I would like to express my appreciation for my other colleagues, who have all collaborated and given valuable feedback during this research: Ann Heylighen, Bj¨ orn Vangenechten, Mathias Casaer and Raymond Kenis. I do not want to forget our system administrators who made sure all hardware and software kept running, despite my constant urge to install different applications and tweaking the installation: Gianni Cairo, Greet Gabri¨els, Ben Brants and Miguel Penalver. This development would not have reached this far without the help of some of the architecture students, who have worked on aspects of these concepts, through their Masters Thesis: Katja Malfliet, Ward Poelmans, Hans Van Laer and Pieter Withouck. In addition, some graduate students of informatics from the Rega Highschool have done an internship of three months with us and have all implemented some part of the software prototype: Davy Verhaeghen, Mathias Casaer, Valerie Witters, Wim Symens, Willem Mahy, Steven Vercammen, Thomas Borghs and Dirk Van Roy. The prototype application uses the Hoops 3D libraries from Tech Soft 3D, which are provided freely for academic research. Other used libraries are Qt, TinyXML and GPC, which were also freely available. I want to give a big hug to my sons Bram, Wannes and Jonas for their endless energy and for all the happy moments so far. I also want to thank my parents and my parents in law for their welcomed support. And last, but definitely not least, my wife Kathleen, for her continuous love and support, but also for convincing me to use LATEX instead of MS Word to finish this text. iii

Summary Korte Samenvatting Dit onderzoek beschrijft een aantal mechanismen om de ondersteuning van de vroege fazen van het ontwerp te verbeteren in ontwerpsoftware voor architecten. Specifiek wordt gekeken hoe een ontwerp kan evolueren doorheen ontwerpfazen en schaalniveaus. Er wordt vertrokken van een overzicht van ontwerpapplicaties, voornamelijk gericht op Computer Aided Design en 3D modellering. Hieruit worden een aantal trends en beperkingen afgeleid. Ook wordt gekeken naar de problemen rond het uitwisselen van ontwerpdata. Dit overzicht leidt tot de uitwerking en ontwikkeling van een aangepaste datastructuur voor de beschrijving van een digitaal gebouwmodel. Deze structuur is flexibel en generiek opgebouwd en biedt ondersteuning voor overgangen tussen ontwerpfasen en schaalniveaus. Dit wordt toegepast in een prototype applicatie, om aan aantal van de voorgestelde mechanismen tot verbetering te illustreren.

Short Summary This research describes mechanisms to improve the support for the early design stages in software for architectural design. The focus lies on the transition of the design between different design phases and scale levels. The research initiates with an overview of design applications, mostly in the context of Computer Aided Design and 3D modeling. From this overview, several trends and limitations are derived. In addition, the problems surrounding the exchange of design data are discussed. This overview leads to the elaboration and implementation of a custom data structure to describe a digital building model. This is a flexible and generic structure, supporting the transitions between design phases and scale levels. This is applied in a prototype application, to illustrate some of the proposed mechanisms for improvement.

Nederlandstalige Samenvatting 0.1

Introductie

Computers zijn niet meer weg te denken uit de architectuurpraktijk. Van administratie tot ontwerp worden bouwprojecten tegenwoordig bijna integraal met digitale toepassingen beheerd. Computer Aided Architectural Design (CAAD) omvat alle software toepassingen die bij het gebouwontwerp kunnen worden gebruikt. Meestal gaat het hierbij om tekenen modelleringsoftware, zoals Autodesk AutoCAD of Bentley MicroStation. Steeds meer gaat men echter gebruik maken van toepassingen voor Building Information Modelling (BIM), zoals Graphisoft ArchiCAD of Autodesk Revit. Hierbij wordt een driedimensionale database van een gebouw opgemaakt, waaruit informatie kan worden geÂ¨extraheerd. Dit kan gaan van tekeningen en 3D modellen tot berekeningen en simulaties. Het grote voordeel bij BIM is dat alle uitvoer gegenereerd wordt van dezelfde databank, zijnde het gebouwmodel. Elke wijziging in het gebouwmodel wordt consequent doorgevoerd in alle mogelijke documenten die uit het model afgeleid worden, waardoor elk document gesynchroniseerd blijft en tegenspraak kan worden vermeden. BIM belooft betere controle over alle uitvoerdocumenten, maar ook het verminderen van fouten en een hogere productiviteit.

0.2

Context: Stand van zaken met betrekking tot ontwerpsoftware

Om voeling te krijgen met ontwerptoepassingen voor architecten, wordt eerst een overzicht gemaakt van beschikbare CAD en ontwerptoepassingen. Dit gaat van algemene CAD en 3D toepassingen, tot specifieke animatie en visualisatie oplossingen. Hierbij worden naast een inhoudelijk overzicht ook een aantal trends vastgesteld.

0.2.1

Overzicht ontwerptoepassingen

Er wordt eerst een kort overzicht gegeven van de ontwikkeling van CAD. Dit wordt opgedeeld in categorieÂ¨en, waaronder 2D tekenen, 3D modelleren en Building Information Modeling (BIM). De focus ligt uiteraard op toepassing binnen vii

viii

Chapter 0. Nederlandstalige Samenvatting

architectuur, maar er worden toepassingen vanuit Mechanica (MCAD) en Digital Content Creation (DCC) aangehaald. Sommige concepten die gemeengoed zijn in dergelijke toepassingen vinden ook ingang binnen CAAD, zoals parametrisch ontwerpen en procedurale modellering. Dit overzicht wordt samengevat in een database van ontwerptoepassingen, die via een website raadpleegbaar gemaakt wordt op http://asro.sbuild.com .

0.2.2

Trends

Enkele trends zijn belangrijk om de evolutie van ontwerpsoftware beter te situeren. Er is een toenemende beschikbaarheid van functionele goedkope of zelfs gratis software. Dit volgt zeker niet uit vrijblijvende generositeit, maar is eerder het verlagen van de instapdrempel om met bepaalde software producten te werken. Vooral het opkomen van gratis “Learning Editions” van enkele 3D animatieprogramma’s is opvallend. Dit gaat niet om evaluatieversies, maar om programma’s met volledige functionaliteit, weliswaar met beperkingen om commercieel gebruik te vermijden. Daarnaast bieden meer en meer firma’s een gamma van aanvullende producten aan, die de gebruiker doorgroeimogelijkheden bezorgen. Dit is uiteraard een vorm van klantenbinding, maar dwingt tegelijk de fabrikant ook om minder uitgebreide versies van applicaties op de markt te brengen, die tegelijk functioneel blijven. Er is tevens een trend tot consolidatie, door de veelvuldige en soms onverwachte overnames. Bepaalde goede producten worden opgekocht en worden dan ofwel mee opgenomen in het regulier productengamma van een producent, maar sommige applicaties verdwijnen evengoed van de markt. Er wordt een kort overzicht gegeven van het gebruik van CAD toepassingen. We kijken daarbij naar gebruikte toepassingen binnen architectuuropleidingen, naar het relatief beperkt refereren naar dergelijke toepassingen binnen academisch onderzoek rond CAD en architectuur en naar de architectuurpraktijk. Op al deze vlakken ontstaat een hybridisatie van het gebruik van digitale toepassingen. Hoewel de activiteit van ontwerpen nog dikwijls gebaseerd is op handmatig schetsen, zijn toepassingen zoals Google SketchUp, McNeel Rhino en Adobe Photoshop belangrijke ontwerptoepassingen geworden. Ondanks de pogingen van fabrikanten om CAAD toepassingen te voorzien die functioneel zijn doorheen het volledig ontwerptraject, wordt vooral bij de ontwerpfase een hybride gamma aan toepassingen ingezet.

0.2.3

Uitwisseling CAD en ontwerpdata

Door een hybride gebruik van verschillende CAD en ontwerptoepassingen en door de toenemende digitalisering van het ontwerpproces, ontstaat een grotere noodzaak tot uitwisseling van digitale data. Dit kan gaan van het uitwisselen van tekeningen, tot het uitwisselen van 3D modellen en stilaan ook van digitale

0.3 Academisch Onderzoek

gebouwmodellen. De belangrijkste uitwisselingsformaten, zoals DWG en DXF, maar ook STEP en IFC worden besproken.

0.3

Academisch Onderzoek

Naast een uitgebreid overzicht van ontwerpapplicaties, wordt ook een wat beknopter overzicht gegeven van enkele onderzoeksthema’s en projecten uit een academische context. Hierbij is er onderzoek naar manieren om het schetsen te vertalen naar een digitale context, naar modellerings oplossingen voor schetsontwerp en naar toepassingen rond virtuele realiteit. De onderzoeksgroep Ontwerp- en Bouwmethodiek, van het Departement Architectuur, Stedenbouw en Ruimtelijke Ordening aan de K.U.Leuven houdt zich o.a. bezig met het ontwikkelen van hulpmiddelen bij het ontwerpproces. Hoewel onderzoek rond CAD en ontwerpmethodiek tegenwoordig niet meer de intentie heeft om de computer zélf het ontwerp te laten uitwerken, is het wel de bedoeling om het ontwerpproces te verbeteren, m.b.v. digitale ondersteuning. In dit onderzoek ligt de focus op de vroege fase van het ontwerpproces. In de vroege fase ligt het ontwerp nog niet echt vast, maar moeten wel de belangrijkste beslissingen genomen worden. Bij het vormen van het concept van een ontwerp gaat men ervan uit dat de beslissingen met de grootste impact meest baat hebben bij evaluatie toepassingen. Door van bij het begin van het ontwerp evaluaties in te bouwen, kan feedback verkregen worden, die het ontwerp kan bijsturen. Dit is belangrijk, omdat dergelijke bijsturingen later in het ontwerp dikwijls gepaard gaan met grote kosten of zelfs helemaal onmogelijk geworden zijn. Binnen deze onderzoeksgroep ligt de theoretische besis voor dit onderzoek. De omschrijving van het ontwerpproces is geschematiseerd in het Conceptueel Model [Neu92], waarin het ontwerp wordt gestructureerd aan de hand van Ontwerpfasen en Schaalniveaus. De ontwerper kan zelf kiezen doorheen welke fasen en niveaus het ontwerp zal evolueren. Hierbij kan tijdens het ontwerpproces overgeschakeld worden naar andere fasen of niveaus. Als men gaat van een groot schaalniveau naar een gedetailleerd schaalniveau, spreekt men van “Top Down” ontwerp, terwijl de omgekeerde volgorde een “Bottom Up” benadering is. Beide zijn mogelijk, ook binnen één ontwerp. Er worden drie schaalniveaus onderscheiden. Het Masterplan niveau beschrijft gebouwvolumes op een site en wordt gebruikt bij het fijner uitwerken van stedenbouwkundige ontwerpen en bij het ontwikkelen van grotere bouwprojecten. Het Blok of Type niveau beschrijft de opdelingen binnen een gebouwblok, zoals verdiepingen, zones en ruimtes. Op het niveau van de Ruimte worden ten slotte de eigenlijke gebouwelementen beschreven. Deze drie niveaus zouden kunnen worden aangevuld met een stedenbouwkundig niveau aan de ene kant en met het niveau van materialen of constructiesystemen aan de andere kant. Daarnaast worden ook drie ontwerpfasen vooropgesteld, die overeenkomen met de chronologische volgorde van een bouwdossier. De eerste fase, die volgt na het ontwikkelen van het gebouwprogramma, is het Schetsontwerp. Hier worden principiële beslissingen binnen het ontwerp bekeken, zoals de positionering

Chapter 0. Nederlandstalige Samenvatting

van dragende elementen, wanden, vloeren en de aanwezigheid van openingen. Dit komt overeen met het niveau waarop de architect een ontwerpvoorstel bespreekt met de cliënt. De volgende fase is het Voorontwerp, waarbij het ontwerp verder gespecificeerd wordt naar gebruik van materialen en de typering van de openingen. Dit is het niveau waarop een dossier wordt uitgewerkt tot een bouwaanvraag of in functie van externe instanties, zoals dossiers voor brandveiligheid, subsidies en installatieconcepten. en omvat alle administratieve informatie, zoals oriëntatie, materiaalgebruik en oppervlaktes. Ten slotte bereikt men een Constructiefase, waarbij het dossier bouwtechnisch uitgewerkt wordt voor uitvoering door de aannemers. Men zou voor de eerste fase nog kunnen spreken over een programmatie fase en na de constructiefase zou men van een gebruiksfase en eventueel van een afbraakfase kunnen spreken. Op elk van die niveaus en fasen kan men evaluatietests uitvoeren, die de ontwerper bijkomende informatie moeten bezorgen om ontwerpkeuzes te maken. Dit kan gaan van oppervlakteberekeningen, schaduwstudies en daglichtsimulaties, tot en met gedetailleerde kostenberekeningen en visualisaties. Op basis van dit conceptueel model, werd een object model uitgewerkt, genaamd het “CORE Object Model” [Hen00]. Hierbij werd gebruik gemaakt van de MERODE methode [DS94], voor het opzetten van een object georiënteerde structuur om het ontwerp voor een gebouwproject te omschrijven.

0.4

Een datastructuur voor een digitaal gebouwmodel

Dit onderzoek bouwt dus voort op het Conceptueel schema en op het CORE Object Model. Deze twee modellen vormen de basis voor de ontwikkeling van een Ge¨ıntegreerde Ontwerpomgeving voor Architectuur of Integrated Design Environment for Architecture (IDEA+). Dit is een combinatie van een databank die een digitaal gebouwmodel bevat en toepassingen die hiermee interageren. We denken daarbij niet alleen aan CAD of modelleringstoepassingen, maar ook aan simulatie oplossingen, die bijvoorbeeld de kostprijs of het energieverbruik ramen. Deze omgeving gaat uit van de enkele aannames over het ontwerpproces, gesteund op rasters en op de verschillende fasen en nivaeus. Hierbij is het vooral de bedoeling om ondersteuning te bieden bij de vroege fase van het ontwerpen. De volledige uitwerking van dergelijke ontwerpomgeving is echter niet het doel van deze thesis. Dit onderzoek wil eerder deelaspecten van dergelijke ontwerpomgeving verder verkennen en via een prototype enkele van deze concepten illustreren. Op lange termijn zou dit kunnen leiden tot een eigenlijke implementatie van deze omgeving, al is het op dit moment zeker nog niet duidelijk of dit ook haalbaar is. Uit het overzicht van ontwerpapplicaties en de trends is alleszins vast te stellen dat er zo nog geen systeem bestaat en dat het in de praktijk eerder gaat over manieren om verschillende toepassingen op een effici¨ente manier met elkaar te integreren, gebaseerd op de concepten van BIM.

0.4 Een datastructuur voor een digitaal gebouwmodel

0.4.1

Structuur van het digitaal gebouwmodel

Eerst en vooral wordt het CORE Object Model vertaald naar een data structuur. Dit is een serie klassen en methoden, die de functionaliteit en de gedragingen van de verschillende ontwerpentiteiten vastlegt en implementeert. Het CORE Object Model wordt uitgewerkt in de object geori¨enteerde programmeertaal C++ en is platformonafhankelijk. Dit model is tevens onafhankelijk van externe bibliotheken, zodat het binnen verschillende omgevingen zou kunnen worden toegepast. Deze data structuur bestaat uit een reels klassen, gegroepeerd in modules. De Basis Module omvat generieke klassen, die objecten en hun relaties beheren. Hier wordt het generiek Property System opgebouwd, dat toelaat om klassen te beheren, onafhankelijk van hun implementatie. Dit Property System vormt de eigenlijke kern van het hele systeem en er is veel aandacht besteed aan het voorzien van flexibiliteit en uitbreidbaarheid. De Grafische Module omvat een laag van geometrische objecten, die gebruikt zullen worden door de objecten van de CAAD Module. Deze grafische module omvat geen tekenroutines, maar enkel een reeks objecten die voldoende informatie moeten bijhouden om later binnen de representaties gebruikt te worden. Het eigenlijke afbeelden en genereren van 2D en 3D voorstellingen is dan een taak van de grafische kernel die gebruikt wordt binnen de prototype applicatie. De CAAD Module omvat dan de eigenlijk ontwerpentiteiten en alle klassen nodig om die te beheren. Dit omvat o.a. het Project, de Elementen binnen het project en de Representaties, die een voorstelling opbouwen van de Elementen. De Events Module bevat de commando structuren voor de functies binnen de prototype applicatie. Dit zijn de methoden om entiteiten te creren, te wijzigen en te verwijderen. Ook omvat dit methoden voor het transformeren, kopi¨eren en koppelen van entiteiten. De Tests Module omvat de evaluatie tests, zoals een hoeveelhedenberekening en een visualisatie. De Extra Module omvat ten slotte methoden voor het exporteren en het importeren van het project naar XML bestanden.

0.4.2

Representatie van gebouw informatie

Een digitaal gebouwmodel op zich is nutteloos als de informatie daarin niet op ´e´en of andere manier kan worden getoond. De klassieke manier om een gebouw te beschrijven is aan de hand van plannen. Dit is een 2D representatie van het gebouwmodel. Plannen zijn een conventionele manier om de informatie over een gebouw uit te wisselen. Op een eerder schematische manier worden de

xii

Chapter 0. Nederlandstalige Samenvatting

afmetingen van de verschillende gebouwelementen getoond en is er informatie leesbaar over functies van ruimtes, gebruik van materialen en de opbouw van de constructie. Daarnaast maakt men meer en meer gebruik van een 3D voorstelling. Dit is een geometrisch model van het gebouw, met informatie over hoogte, diktes en oppervlakte afwerkingen. Dit geeft een inzichtelijk beeld van het ontwerp en toont aspecten van het gebouw die onzichtbaar blijven bij technische tekeningen. Hoewel de 2D en de 3D voorstelling van het gebouw de meest gangbare weergaven zijn van een gebouw, worden bijkomende representaties voorzien. We bespreken twee manieren om naar de relaties binnen een gebouwmodel te kijken. In een hiÂ¨erarchische representatie worden elementen geordend in een boomstructuur volgens afhankelijkheden. Op het hoogste niveau zit het gebouwvolume, waaronder de verschillende opdelingen in het gebouw zitten, zoals verdiepingen en zones. Hieronder zitten de ruimtes en lokalen en daaronder de inhoud van deze ruimtes. De eigenlijke fysische gebouwelementen horen niet direct thuis in deze representatie, vermits die niet strikt tot een bepaalde ruimte of verdieping thuishoren. Een schematische weergave is dan weer een netwerk van relaties, waarbij de verschillende elementen knopen worden in het netwerk en de relaties met pijlen voorgesteld worden. Er zijn drie soorten relaties te onderscheiden. Object Relaties leggen vast welke elementen met elkaar in verbinding zijn, zoals een muur die verbonden is met een dak. Afhankelijkheidsrelaties leggen dan weer ouderkind relaties vast, waarbij bepaalde elementen afhankelijk worden van andere, zoals de meubels van een lokaal of een plint of een opening van een muur. Eigenschappen relaties tenslotte laten toe om specifieke verbanden te leggen tussen willekeurige elementen. Dit is een manier om ontwerp intenties te incorporeren in de project data, zoals het gelijkstellen van verschillende muurhoogtes of het uitlijnen van kolommen op elkaar. Er zouden ook tekstuele representaties kunnen gemaakt worden, zoals een lastenboek, waarbij de materiaalomschrijvingen een andere manier zijn om te kijken naar de project data. Binnen het prototype worden enkele van deze representaties voorzien, zonder daarom tot in het detail van afgewerkte plannen te willen verglijden. De bedoeling is informatie te visualiseren die bruikbaar is bij het ontwerp. De feitelijke uitwerking van technische plannen kan altijd gebeuren in bestaande CAAD of BIM applicaties. De bedoeling is wel dat het gebouwmodel op een intelligente manier kan worden overgezet naar dergelijke applicaties, zodat er niet enkel een tekening of 3D geometrie wordt omgezet, maar dat er effectief een overzetting gemaakt kan worden van het gebouwmodel.

0.4.3

Overgangen tussen schaalniveaus en ontwerpfasen

Omdat een ontwerper meer tijd spendeert aan het wijzigen en verbeteren van het model, dan in het initieel aanmaken ervan, is het belangrijk om te kijken

0.4 Een datastructuur voor een digitaal gebouwmodel

xiii

naar de manier waarop interactie met het model mogelijk is en hoe dit model tijdens het ontwerpproces kan evolueren. We kijken daarbij naar twee soorten overgangen. Wanneer men overgaat naar een ander schaalniveau, dan verandert de focus op het ontwerp en werkt men met andere ontwerpentiteiten. Op het niveau van het Masterplan wordt bijvoorbeeld ontworpen met gebouwblokken als een geheel. Bij de overgang naar het Block niveau, kijkt men naar de ruimten in de gebouwblokken, die echter gerelateerd blijven aan de entiteiten op het Masterplan. Bij de overgang naar de Ruimte niveau, worden de eigenlijke fysieke gebouwelementen gecreëerd en beheerd. In het ontwerp kan de architect op elke moment van focus veranderen en dus andere ontwerpentiteiten gebruiken. Er moet een manier gevonden worden dat het gebouw op de verschillende niveaus coherent blijft. Het tweede type van overgangen, gaat vooral kijken naar chronologie binnen het ontwerp, waarbij gaandeweg meer informatie aan het ontwerp toegevoegd wordt. Op het moment dat de ontwerper terug overstapt naar een eerdere fase, wordt de representatie aangepast, zonder daarbij het toegevoegde detail te verwijderen. Dit laat toe om bijvoorbeeld tijdelijk naar een detailoplossing te kijken, waarna weer teruggestapt wordt naar een minder gedetailleerd model, bij de exploratie van het ontwerp. Hiervoor zijn enkele mechanismen bedacht, die toelaten om het model te beheren over verschillende schaalniveaus heen en doorheen verschillende ontwerpfasen. Het gebruik van Gedeelde Referentiepunten laat toe om elementen, over verschillende schaalniveaus heen, met elkaar te verbinden. Wijzigingen worden doorgevoerd in gerelateerde elementen. Door een toepassing van het BB/SfB classificatie systeem [DNHS90], wordt generieke gebouwinformatie toegevoegd als attributen voor de verschillende ontwerpentiteiten. Dit laat toe om elementen te groeperen, classificeren en filters toe te passen, bij bijvoorbeeld evaluatie tests of binnen representaties. Het gebruik van Eigenschap Relaties en Eigenschap Expressies, is een manier om ontwerpintenties te formaliseren in het ontwerp. Eigenschappen van ontwerpentiteiten kunnen worden gekoppeld aan andere eigenschappen, zodat wijzigingen in één element kunnen doorgegeven worden aan andere elementen. De gebruiker kan zo specifiëren dat de hoogte van een muur bijvoorbeeld gelijk moet blijven aan de hoogte van een andere muur. Bij de overgang naar latere ontwerpfasen, is het ook nodig om de verbindingen tussen vlakke elementen correct in te vullen. Het beheren van deze aansluitingen is aangepakt door het definiëren van een Connection klasse. Die zal voor een bepaalde knoop tussen vlakke elementen kijken naar de verschillende lagen waarmee deze elementen zijn opgebouwd. Door een prioriteit toe te kennen aan deze lagen, kan berekend worden tot op welke afstand bepaalde lagen kunnen doorlopen in een verbinding.

xiv

0.4.4

Chapter 0. Nederlandstalige Samenvatting

Interactie met het gebouwmodel

Om de interactie met het gebouwmodel mogelijk te maken, wordt er een systeem opgezet van commando’s. Dit zijn operaties die uitgevoerd kunnen worden op het project, zoals de creatie van een nieuwe entiteit, het wijzigen van een parameter van een object en het cre¨eren van een koppeling tussen twee entiteiten. Deze commando’s worden bijgehouden in een chronologische lijst, zodat ze kunnen ongedaan gemaakt worden of weer hersteld worden. Tevens wordt door het Property System de mogelijkheid geboden om op een generieke manier eigenschappen op te vragen en aan te passen. Dit resulteert in de ontwikkeling van een Eigenschappen Dialoogvenster, dat de eigenschappen van eender welk element kan weergeven en bewerken. Dit vereenvoudigt aanzienlijk de ontwikkeling binnen een onderzoeksproject, vermits de interface niet telkens dient aangepast te worden wanneer nieuwe elementen ingevoerd worden. Tenslotte wordt ook gekeken naar het gebruik van Manipulators. Dit zijn tijdelijke hulpobjecten waarmee ontwerpentiteiten op een grafische manier kunnen worden gewijzigd. Dit biedt een visuele toegang tot ontwerpinformatie en is een opvallende trend in hedendaagse ontwerpapplicaties.

0.4.5

Integratie van evaluatietests

Evaluatietests laten toe om tijdens het ontwerpen informatie op te vragen over het project. Er bestaan geavanceerde simulatietoepassingen voor uiteenlopende tests zoals stabiliteitsberekeningen en energiehuishouding, inclusief zonnewinsten, bewonerswinsten en verlichtingswinsten. Dergelijke tests zijn dikwijls complex en vragen een specifieke data invoer. In vele gevallen is de gebruiker verplicht om het ontwerp te vertalen naar een ander formaat en zal daarbij nieuwe informatie moeten worden toegevoegd. Dit houdt dikwijls zelfs het volledig opnieuw opbouwen van de ontwerpdata in. Door de complexiteit en de omvang van het conversieproces, worden dergelijke simulaties meestal pas uitgevoerd op een uitgewerkt project, op een moment dat eventuele feedback van dergelijke tests eigenlijk niet meer kan worden gebruikt om het ontwerp bij te sturen. De bedoeling van het integreren van dergelijke evaluatietest is juist dat het conversieproces kan ingekort of zelfs vermeden worden en dat de tests tijdens het ontwerpen reeds zouden kunnen gebeuren, op een moment dat belangrijke ontwerpbeslissingen nog moeten worden genomen. Dit kan helpen om dergelijke beslissingen te motiveren en af te wegen. Het is zeker niet de bedoeling om bestaande simulatietoepassingen te gaan nabouwen. De nadruk ligt eerder op een directe omzetting van de projectdata naar gebruiksklare input voor dergelijke tests. Door een redelijke aanname te maken van de meeste input variabelen, zou een test in de vroege faze van het ontwerp toch kunnen worden uitgevoerd, met de data die voorhanden zijn in het gebouwmodel. Een daglichttest is wel in detail uitgewerkt, op niveau van de algoritmes [Gee03]. Deze is echter nog niet ge¨ıntegreerd binnen het prototype.

0.5 Prototype Applicatie

0.5

Prototype Applicatie

Omdat een datastructuur op zich waardeloos is als die niet wordt toegepast binnen een applicatie, wordt een prototype uitgewerkt, waarbinnen de concepten van het onderzoek ge¨ıllustreerd kunnen worden. Het IDEA+ prototype is een hybride programma, met kenmerken van zowel CAD als 3D modellering software. De applicatie is een grafische, platformonafhankelijke toepassing, waarbij op een grafische manier ontwerpentiteiten aangemaakt en gewijzigd kunnen worden. Er worden verschillende representaties ondersteund en door het aanmaken van de verschillende soorten koppelingen tussen entiteiten, kan een deel ontwerpinformatie ingebed worden in de project data. Het model kan bewaard worden als een XML bestand en biedt enkele— weliswaar beperkte—evaluatie modules. De bedoeling is niet om een afgewerkt product te implementeren, maar eerder ontwerpconcepten in BIM te verkennen en een platform te bouwen waarop ontwerptoepassingen kunnen worden uitgewerkt. Een modulaire structuur moet uitbreidingen eenvoudiger maken.

0.6

Conclusie

Op het einde van dit doctoraatsonderzoek is de datastructuur en het eigenschappen systeem operationeel. Een aantal ontwerpentiteiten is beschikbaar en relaties tussen de elementen kunnen worden bijgehouden. Tevens is het mogelijk om op een generieke manier de eigenschappen af te beelden en te bewerken en het model te bewaren. Door een generieke aanpak van het eigenschappen systeem, kan het model vrij eenvoudig uitgebreid worden, zonder aanpassingen aan de import- en exportroutines en zonder aanpassingen voor de manipulaties binnen de applicatie. Anderzijds is er nog nood aan een externe evaluatie van de concepten van het ontwerpprototype, bij voorkeur door het te gebruiken in ontwerpoefeningen, door architecten. Dit zou moeten leiden tot een verfijning van de concepten en kan wijzen op de meeste essenti¨ele tekortkomingen. Naar de toekomst toe kan nog gekeken worden of deze concepten kunnen toegevoegd worden aan bestaande applicaties, zoals ze gebruikt worden in de architectuurpraktijk.

Acronyms 2.5D 2D with added height dimension (not quite 3D) 4D 3D with added time dimension 5D 4D with added cost dimension AEC Architecture, Engineering and Construction API Application Programming Interface AJAX Asynchronous Java And XML BB/SfB Classification code, based on CI/SfB, but adapted for the Belgian building sector. BIM Building Information Modeling, which is the approach of managing the design of a building as a 3D model, from which other views are derived. BOM Bill-Of-Materials CAAD Computer Aided Architectural Design CAD Computer Aided Design (sometimes: drafting) CAM Computer Aided Manufacturing CG Computer Graphics CSG Constructive Solid Geometry, or the ability to perform Boolean modeling operations on 3D volumes D3D Direct3D, subset from DirectX from Microsoft, for the display of interactive 3D graphics DCC Digital Content Creation, which is usually performed with 3D Animation software DTP Desktop Publishing DYNAMO DYNAmic Memory Online is a research project on Case Based Reasoning at the Dept. ASRO of the K.U.Leuven. It contains a database of architectural cases, with thematic searches DWF Design Web Format (from Autodesk) DWG AutoCAD Drawing/Design Format (from Autodesk) xvii

xviii

Chapter 0. Acronyms

ERP Enterprise Resource Planning FAQ Frequently Asked Questions FEA Finite Element Analysis FM Facility Management, the management of a building in the post-built phase. GDL Geometric Description Language (from Graphisoft) GIS Geographic Information System, linking geographical maps with additional data GNU Recursive acronym for GNU is Not Unix GPL GNU General Public License, a licensing scheme for free software, with very specific usage requirements GPU Graphics Processing Unit or the graphics display adapter GUI Graphical User Interface GUID Globally Unique Identifier HVAC Heating Ventilation and Air Conditioning IDEA+ Integrated Design Environment for Architecture with the + indicating integrated evaluation testing IFC Industry Foundation Classes ISO International Standards Organization MCAD Mechanical CAD, or the use of CAD for the design and manufacturing of machines and products MERODE Model driven, Existence dependency Relation, Object oriented DEvelopment, a software development method used for the IDEA+ data structure MEP Mechanical, Electrical and Plumbing MFC Microsoft Foundation Classes NURBS Non-Uniform Rational BÂ´ezier Splines or Surfaces ODA Open Design Alliance OOP Object Oriented Programming OpenGL Open Graphics Language, a framework for interactive graphics, originally from SGI PDF Adobe Portable Document Format PDM Product Data Management

xix PLE Personal Learning Edition (of a software application) PLM Product Lifecycle Management SDK Software Developers Kit SQL Structured Query Language, information retrieval language for database systems UML Unified Modeling Language, often used for the design or analysis of Object Oriented software or libraries VRML Virtual Reality Markup Language XML eXtensible Markup Language, a widely accepted generic data format, used in many applications.

Contents Preface

iii

Nederlandstalige Samenvatting

vii

0.1

Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii

0.2

Context: Stand van zaken met betrekking tot ontwerpsoftware .

vii

0.2.1

Overzicht ontwerptoepassingen . . . . . . . . . . . . . . .

vii

0.2.2

Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

0.2.3

Uitwisseling CAD en ontwerpdata . . . . . . . . . . . . . viii

0.3

Academisch Onderzoek . . . . . . . . . . . . . . . . . . . . . . . .

0.4

Een datastructuur voor een digitaal gebouwmodel . . . . . . . .

0.4.1

Structuur van het digitaal gebouwmodel . . . . . . . . . .

0.4.2

Representatie van gebouw informatie . . . . . . . . . . . .

0.4.3

Overgangen tussen schaalniveaus en ontwerpfasen

xii

0.4.4

Interactie met het gebouwmodel . . . . . . . . . . . . . . xiv

0.4.5

Integratie van evaluatietests . . . . . . . . . . . . . . . . . xiv

. . . .

0.5

Prototype Applicatie . . . . . . . . . . . . . . . . . . . . . . . . .

0.6

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Acronyms

xvii

Contents

xxi

Introduction

xxxix

Context

1 Overview of Design Applications

1.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

A historic view on CAD . . . . . . . . . . . . . . . . . . . . . . .

1.3

2D CAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xxi

xxii

CONTENTS

1.4

3D CAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5

Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.1

Rendering Techniques . . . . . . . . . . . . . . . . . . . .

1.5.2

Hardware Base Rendering . . . . . . . . . . . . . . . . . .

1.5.3

Application into architectural practice . . . . . . . . . . .

1.6

Web applications . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.7

Building Information Modeling . . . . . . . . . . . . . . . . . . .

1.7.1

What is BIM? . . . . . . . . . . . . . . . . . . . . . . . .

1.7.2

Example BIM Applications . . . . . . . . . . . . . . . . .

1.7.3

CAD and BIM use in architectural practice . . . . . . . .

1.8

Building Simulation . . . . . . . . . . . . . . . . . . . . . . . . .

1.9

Administrative CAD . . . . . . . . . . . . . . . . . . . . . . . . .

1.9.1

Programming Phase . . . . . . . . . . . . . . . . . . . . .

1.9.2

Document Management . . . . . . . . . . . . . . . . . . .

1.9.3

Project Planning and Management . . . . . . . . . . . . .

1.10 Software for preliminary architectural design . . . . . . . . . . .

1.11 Design Applications from other disciplines . . . . . . . . . . . . .

1.11.1 Mechanical & Parametric Design . . . . . . . . . . . . . .

1.11.2 Using Parametric Modeling for Architecture . . . . . . . .

1.11.3 Difference between MCAD and BIM . . . . . . . . . . . .

1.12 Generative and Procedural Design Methods . . . . . . . . . . . .

1.12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . .

1.12.2 Procedural approach in design software . . . . . . . . . .

1.13 Visual programming using a node-based interface . . . . . . . . .

1.13.1 Example Applications . . . . . . . . . . . . . . . . . . . .

1.13.2 Relevance to Architecture . . . . . . . . . . . . . . . . . .

1.14 Creative Software on the border between 2D and 3D . . . . . . .

1.14.1 Relevance to Architecture . . . . . . . . . . . . . . . . . .

1.15 An applications database . . . . . . . . . . . . . . . . . . . . . .

1.16 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Trends and evolutions in design applications

2.1

Availability of free applications . . . . . . . . . . . . . . . . . . .

2.2

Different application versions, from free till expensive . . . . . . .

2.3

License subscriptions versus resistance to update . . . . . . . . .

2.4

Acquisitions and mergers of Companies . . . . . . . . . . . . . .

CONTENTS

xxiii

2.5

Software use in Architectural Education . . . . . . . . . . . . . .

2.6

References to common CAD and 3D applications in academic research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.7

Hybrid use of design applications . . . . . . . . . . . . . . . . . .

2.8

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Exchange of CAD Data and Building Data 3.1

CAD Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2

3D Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

3.3

Product Model Data . . . . . . . . . . . . . . . . . . . . . . . . . 104

3.3.1

STEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

3.3.2

IFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

3.4

Exchanging information without CAD software . . . . . . . . . . 106

3.5

Cross-application exchange and the online database . . . . . . . . 107

4 Academic Research

111

4.1

Sketch Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

4.2

Virtual Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

4.3

Representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

4.4

Building Information Modeling . . . . . . . . . . . . . . . . . . . 114

4.5

The Design and Building Methodology Research Group . . . . . 116 4.5.1

Conceptual Scheme . . . . . . . . . . . . . . . . . . . . . . 116

4.5.2

CORE Object Model . . . . . . . . . . . . . . . . . . . . . 119

4.5.3

Integrated digital modeling. . .

Concepts

5 The Data Structure 5.1

. . . . . . . . . . . . . . . 121

125 129

The structure of the digital building model . . . . . . . . . . . . 129 5.1.1

Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

5.1.2

Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

5.1.3

CAAD Entities and Graphical Entities . . . . . . . . . . . 129

5.1.4

Library Elements or Shared Entities . . . . . . . . . . . . 131

5.1.5

Physical Elements and Types . . . . . . . . . . . . . . . . 131

5.2

Template Entities or External Object Library . . . . . . . . . . . 132

5.3

Grids and working planes . . . . . . . . . . . . . . . . . . . . . . 133

5.4

Floor Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

xxiv

CONTENTS

5.5

Layers in a digital building model . . . . . . . . . . . . . . . . . . 137

5.6

Classification & BB/SfB . . . . . . . . . . . . . . . . . . . . . . . 140

5.7

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

6 Representation of building information

143

6.1

Representational limitations in BIM Applications . . . . . . . . . 144

6.2

Overview and definition of representation types . . . . . . . . . . 156 6.2.1

2D Plan representation . . . . . . . . . . . . . . . . . . . 156

6.2.2

3D Model representation . . . . . . . . . . . . . . . . . . . 160

6.2.3

Hierarchic representation . . . . . . . . . . . . . . . . . . 163

6.2.4

Schematic representation . . . . . . . . . . . . . . . . . . 172

6.2.5

Tabular & Textual representations . . . . . . . . . . . . . 175

6.3

A hybrid representation scheme . . . . . . . . . . . . . . . . . . . 177

6.4

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

7 Transitions between Scale Levels and Design Phases 7.1

181

Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 7.1.1

Scale Levels & Design Phases . . . . . . . . . . . . . . . . 181

7.1.2

Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . 185

7.2

Transitions in BIM software . . . . . . . . . . . . . . . . . . . . . 190

7.3

Transitions in the prototype . . . . . . . . . . . . . . . . . . . . . 193

7.4

7.5

7.3.1

Design Phase Transitions . . . . . . . . . . . . . . . . . . 193

7.3.2

Scale Level Transitions . . . . . . . . . . . . . . . . . . . . 195

7.3.3

A wizard-like approach

. . . . . . . . . . . . . . . . . . . 196

Mechanisms to support transitions . . . . . . . . . . . . . . . . . 197 7.4.1

Grid of Reference Points, Lines and Volumes . . . . . . . 197

7.4.2

Add Classification Information . . . . . . . . . . . . . . . 201

7.4.3

Connections between Planar Elements . . . . . . . . . . . 202

7.4.4

Links between entities . . . . . . . . . . . . . . . . . . . . 214

Example transitions in a design project . . . . . . . . . . . . . . 217 7.5.1

Main Overview . . . . . . . . . . . . . . . . . . . . . . . . 217

7.5.2

Creating the Masterplan Model . . . . . . . . . . . . . . . 219

7.5.3

Transition to the Block Scale Level . . . . . . . . . . . . . 221

7.5.4

Transition to the Space Scale Level . . . . . . . . . . . . . 224

7.5.5

Going back to the Block Scale Level . . . . . . . . . . . . 225

7.5.6

Modifying the building model . . . . . . . . . . . . . . . . 226

7.6

Questions and remarks . . . . . . . . . . . . . . . . . . . . . . . . 231

7.7

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

CONTENTS

xxv

8 Integrating Evaluation tests

239

8.1

8.2

8.3

Characteristics of Evaluation Tests . . . . . . . . . . . . . . . . . 240 8.1.1

Extraction Tests . . . . . . . . . . . . . . . . . . . . . . . 240

8.1.2

Data Generation Tests . . . . . . . . . . . . . . . . . . . . 241

Examples of tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 8.2.1

Daylight Estimation Test . . . . . . . . . . . . . . . . . . 241

8.2.2

Cost Estimation . . . . . . . . . . . . . . . . . . . . . . . 243

8.2.3

Visualization . . . . . . . . . . . . . . . . . . . . . . . . . 244

8.2.4

Other possible tests . . . . . . . . . . . . . . . . . . . . . 245

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

9 The Project Data 9.1

9.2

9.3

247

Storing the project inside a file . . . . . . . . . . . . . . . . . . . 247 9.1.1

Existing file formats . . . . . . . . . . . . . . . . . . . . . 247

9.1.2

The IDEA+ file format . . . . . . . . . . . . . . . . . . . 249

Conforming to existing structures . . . . . . . . . . . . . . . . . . 250 9.2.1

ISO Layer Standard . . . . . . . . . . . . . . . . . . . . . 251

9.2.2

BB/SfB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

10 Interacting with building data

253

10.1 Manipulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 10.1.1 Manipulators in design applications . . . . . . . . . . . . 254 10.1.2 Research Example . . . . . . . . . . . . . . . . . . . . . . 258 10.1.3 Manipulator types . . . . . . . . . . . . . . . . . . . . . . 258 10.2 Expressions & parameters . . . . . . . . . . . . . . . . . . . . . . 260 11 The Geometric Model

263

11.1 The complexity of translating building geometry into a digital model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 11.2 Geometrical limitations in building models . . . . . . . . . . . . . 264 11.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

xxvi

III

CONTENTS

Implementation

12 The data structure

273 277

12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 12.2 A modular data structure . . . . . . . . . . . . . . . . . . . . . . 277 12.3 Base Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 12.3.1 Main classes in the Base Module . . . . . . . . . . . . . . 279 12.3.2 Dimensions and Measurements . . . . . . . . . . . . . . . 280 12.3.3 The Property System . . . . . . . . . . . . . . . . . . . . 280 12.4 Graphical Module . . . . . . . . . . . . . . . . . . . . . . . . . . 282 12.5 CAAD Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 12.5.1 Main classes of the CAAD Module . . . . . . . . . . . . . 284 12.5.2 CAAD Entity : Physical Elements . . . . . . . . . . . . . 287 12.5.3 CAAD Entity : Space . . . . . . . . . . . . . . . . . . . . 287 12.5.4 CAAD Entity : Space Assembly . . . . . . . . . . . . . . 291 12.5.5 CAAD Entity : Masterplan Elements . . . . . . . . . . . 293 12.5.6 Library Element : Activity . . . . . . . . . . . . . . . . . 294 12.5.7 CAAD Entity : Grid . . . . . . . . . . . . . . . . . . . . . 296 12.5.8 CAAD Entity : User-Defined Entity . . . . . . . . . . . . 297 12.6 Organization and Implementation of CAAD Entities . . . . . . . 301 12.6.1 Object Factory . . . . . . . . . . . . . . . . . . . . . . . . 301 12.6.2 Physical Element, Type and Composition . . . . . . . . . 302 12.6.3 Links and Relations . . . . . . . . . . . . . . . . . . . . . 308 13 Representations

311

13.1 Graphical Representations . . . . . . . . . . . . . . . . . . . . . . 311 13.1.1 Working of Graphical Representations . . . . . . . . . . . 311 13.1.2 How many Representations are required? . . . . . . . . . 312 13.1.3 Sharing Graphical Entities or not? . . . . . . . . . . . . . 313 13.1.4 Showing and hiding parts of CAAD Entities . . . . . . . . 313 13.2 Elaborating the functionality of Representations . . . . . . . . . 314 13.2.1 Creating Elements . . . . . . . . . . . . . . . . . . . . . . 314 13.2.2 Removing Elements . . . . . . . . . . . . . . . . . . . . . 314 13.2.3 Modifying Elements . . . . . . . . . . . . . . . . . . . . . 314 13.2.4 Exporting Representations

. . . . . . . . . . . . . . . . . 315

13.2.5 Creating Representations . . . . . . . . . . . . . . . . . . 315 13.2.6 Adjusting Representations . . . . . . . . . . . . . . . . . . 316

CONTENTS

xxvii

13.2.7 Removing Representations . . . . . . . . . . . . . . . . . . 316 13.3 Characteristics of Graphical Representations

. . . . . . . . . . . 316

13.3.1 Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 13.3.2 Line Type & Line Width . . . . . . . . . . . . . . . . . . 317 13.3.3 Hatching . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 13.3.4 Textures & Materials . . . . . . . . . . . . . . . . . . . . . 318 13.3.5 Graphical Information and Representations . . . . . . . . 318 14 Transitions

319

14.1 Transition Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 14.1.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 14.1.2 RuleSets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 14.1.3 Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 14.1.4 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 14.2 Synchronization between Scale Levels or Design Phases . . . . . 322 14.2.1 Scale Level Transitions . . . . . . . . . . . . . . . . . . . . 322 14.2.2 Design Phase Transitions . . . . . . . . . . . . . . . . . . 324 14.2.3 Transitions require proper Connections

. . . . . . . . . . 325

14.2.4 Design Phase Transitions introduce Thicknesses . . . . . . 331 14.2.5 Transitions and their effect on Representations . . . . . . 332 14.2.6 Transitions and their effect on Spaces . . . . . . . . . . . 332 15 Evaluation Tests

335

15.1 Data Sets and Properties . . . . . . . . . . . . . . . . . . . . . . 335 15.2 Test Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 15.3 Example Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 15.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 16 Interaction in IDEA+

343

16.1 Manipulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 16.2 Commands & events . . . . . . . . . . . . . . . . . . . . . . . . . 345 16.2.1 Command implementation . . . . . . . . . . . . . . . . . . 348 16.2.2 Overview of Commands . . . . . . . . . . . . . . . . . . . 349 16.3 Expressions & parameters . . . . . . . . . . . . . . . . . . . . . . 353 16.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 353 16.3.2 Using Property Connections to enable expressions . . . . 354 16.3.3 An interface for Expressions . . . . . . . . . . . . . . . . . 355

xxviii

CONTENTS

17 The Geometric Model

357

17.1 A limited graphical model . . . . . . . . . . . . . . . . . . . . . . 357 17.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 17.3 Defining geometric information as Objects . . . . . . . . . . . . . 359 18 Object Oriented Programming in IDEA+

361

18.1 Generic approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 18.2 Programming style & techniques . . . . . . . . . . . . . . . . . . 361 18.2.1 Making IDEA+ in C++ . . . . . . . . . . . . . . . . . . . 362 18.2.2 Good Coding Practice . . . . . . . . . . . . . . . . . . . . 362 18.2.3 Realtime graphics . . . . . . . . . . . . . . . . . . . . . . 363 18.3 Abstraction, Interface & Independency . . . . . . . . . . . . . . . 363 18.4 Modularity and Plugins . . . . . . . . . . . . . . . . . . . . . . . 364 19 Implementing the prototype

367

19.1 Overview of different prototypes . . . . . . . . . . . . . . . . . . 367 19.2 The Graphical User Interface . . . . . . . . . . . . . . . . . . . . 373 19.3 The implemented Prototype . . . . . . . . . . . . . . . . . . . . . 379 20 Final Conclusions

381

20.1 Evaluation & Limitations . . . . . . . . . . . . . . . . . . . . . . 381 20.1.1 What about the Integrated Design Environment? . . . . . 383 20.2 Future research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 20.2.1 Integration with CAD applications . . . . . . . . . . . . . 385 20.2.2 Integration with DYNAMO . . . . . . . . . . . . . . . . . 388 20.2.3 Adding additional functionality . . . . . . . . . . . . . . . 389 Bibliography

391

Publications

403

Curriculum Vitae

405

Appendices

407

CAD & 3D Database

409

IDEA+ File format

417

Index

421

List of Figures 1.1

Screenshot of AutoCAD 2007 . . . . . . . . . . . . . . . . . . . .

1.2

Screenshot of MicroStation V8 XM Edition . . . . . . . . . . . .

1.3

Improved modeling in AutoCAD 2007 . . . . . . . . . . . . . . .

1.4

McNeel Rhino screenshot displaying freeform surface modeling .

1.5

MaxonForm creates complex geometry inside an ArchiCAD project 18

1.6

Autodesk Inventor from 2D sketch to 3D part model . . . . . . .

1.7

Screenshot of subdivision modeling in VIZ 2007 . . . . . . . . . .

1.8

Hurva Synagogue, 1st Proposal, 1967-68 (unbuilt) Radiosity-based Rendering, copyright Kent Larson 2000 . . . . . . . . . . . . . .

Concept image of the CAVE system . . . . . . . . . . . . . . . .

1.10 Kaufmann House by F.L. Wright, recreated in Half-Life 2 for realtime exploration . . . . . . . . . . . . . . . . . . . . . . . . .

1.9

1.11 Expressive Graphics using SketchUp (Architect: Stefan Boeykens) 29 1.12 Photo-realistic results using Autodesk VIZ 2008 with Mental Ray rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.13 Google SketchUp with versatile visual styles . . . . . . . . . . . .

1.14 Autodesk Vespa/Impression screenshot . . . . . . . . . . . . . . .

1.15 Presentation with Impression from an AutoCAD drawing . . . .

1.16 Architectural Studio screenshot. Original image from http:// micrograf.pt/aec/astudio/features.asp . . . . . . . . . . . . . . .

1.17 Moment of Inspiration screenshot . . . . . . . . . . . . . . . . . .

1.18 Three variations of the same design in MultiSurf . . . . . . . . .

1.19 The Guggenheim Museum in Bilbao (Architect: Gehry). Original Image: http://upload.wikimedia.org/wikipedia/commons/d/de/ Guggenheim-bilbao-jan05.jpg . . . . . . . . . . . . . . . . . . . .

1.20 The Ray and Maria Stata Center at MIT (Cambridge MA, USA) (Architect: Gehry). Original Image: http://upload.wikimedia. org/wikipedia/commons/2/25/Wfm stata center.jpg . . . . . . .

1.21 Assembly of generated geometry as shown on the SmartGeometry website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xxix

xxx

LIST OF FIGURES

1.22 Example of a geometric construction as shown in the SmartGeometry 2005 Lisbon workshop . . . . . . . . . . . . . . . . . . . .

1.23 Example of a GC session, displaying the interface elements . . .

1.24 Example of an elaborated parametric assembly . . . . . . . . . .

1.25 Illustration of a node network . . . . . . . . . . . . . . . . . . . .

1.26 The Quartz Designer . . . . . . . . . . . . . . . . . . . . . . . . .

1.27 The Pixelshox predecessor of Quartz Designer . . . . . . . . . . .

1.28 Demicron Wirefusion interface with an imported VRML model .

1.29 Plogue Bidule generative music composition . . . . . . . . . . . .

1.30 Buzzmachines freeware audio environment . . . . . . . . . . . . .

1.31 Shaderman with a fairly simple shader . . . . . . . . . . . . . . .

1.32 (Partial) Structure of the Applications Database . . . . . . . . .

1.33 Screenshot of the Render Study . . . . . . . . . . . . . . . . . . .

1.34 Screenshot of the 3D-CAD Tools Query Form . . . . . . . . . . .

2.1

The complex history of IntelliCAD . . . . . . . . . . . . . . . . .

2.2

Fragment from acquisition history of Autodesk . . . . . . . . . .

2.3

Average software references in Conference Proceedings . . . . . .

3.1

Data exchange between CAD applications . . . . . . . . . . . . . 108

3.2

Data exchange between DCC applications . . . . . . . . . . . . . 109

3.3

Data exchange between CAD and DCC applications . . . . . . . 109

4.1

Conceptual Model for CAAD . . . . . . . . . . . . . . . . . . . . 117

4.2

Core of the Entity Relationship Diagram for a building project . 120

4.3

Separation between conceptual and graphical information . . . . 120

4.4

Different types can share the same composition . . . . . . . . . . 121

5.1

The structure of an Element . . . . . . . . . . . . . . . . . . . . . 130

5.2

Project structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

5.3

Physical Element Types . . . . . . . . . . . . . . . . . . . . . . . 132

5.4

Illustrating a hierarchic Grid . . . . . . . . . . . . . . . . . . . . 134

5.5

Illustration of layer naming convention from ISO 13657

5.6

The BB/SfB Logo, depicting different fields . . . . . . . . . . . . 141

5.7

Five tables translate into four fields . . . . . . . . . . . . . . . . . 141

6.1

Display Manager in ADT . . . . . . . . . . . . . . . . . . . . . . 145

6.2

Style Manager in ADT . . . . . . . . . . . . . . . . . . . . . . . . 146

. . . . . 139

LIST OF FIGURES

xxxi

6.3

Display Properties for a particular Wall Style Override in ADT . 146

6.4

Display Representations for a particular Wall Style in ADT . . . 147

6.5

ADT Layout Sheet using references . . . . . . . . . . . . . . . . . 150

6.6

The Navigator in ArchiCAD . . . . . . . . . . . . . . . . . . . . . 153

6.7

Project Map and View Map in ArchiCAD . . . . . . . . . . . . . 154

6.8

Layout Book and Publisher Sets in ArchiCAD . . . . . . . . . . . 154

6.9

Project View in Autodesk Revit

. . . . . . . . . . . . . . . . . . 155

6.10 Extract from a 2D plan drawing (Architect: Van Dooren) . . . . 157 6.11 2D Drawing for a simple residential design (Architect: Van Dooren)159 6.12 Section through a 3D model to generate a plan . . . . . . . . . . 161 6.13 A simplified hierarchic solar system, modeled in Maxon Cinema4D164 6.14 Displaying document structure in WinEdt editor . . . . . . . . . 165 6.15 The Windows XP Explorer displaying the structure of a disk . . 166 6.16 The Mac OSX Finder displaying the structure of a disk . . . . . 166 6.17 Hierarchic object structure in Maxon Cinema4D . . . . . . . . . 168 6.18 Example Hierarchic Scheme Representation . . . . . . . . . . . . 170 6.19 Hierarchy in property panel . . . . . . . . . . . . . . . . . . . . . 171 6.20 Displaying Spatial relations in a Schematic Representation . . . . 173 6.21 Displaying Connections in a Schematic Representation . . . . . . 174 6.22 Schematic Representation from prototype, displaying different link types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 6.23 Relation between a Building, a Building Model and Representations178 6.24 Illustration of a Building Model . . . . . . . . . . . . . . . . . . . 178 7.1

Generic scheme with all Design Phases and Scale Levels . . . . . 186

7.2

Overview of common transitions . . . . . . . . . . . . . . . . . . 187

7.3

Limiting the scheme with most significant transitions . . . . . . . 188

7.4

Simplified transitions scheme with five chronological stages (not retained) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

7.5

Display Settings in Architectural Desktop . . . . . . . . . . . . . 190

7.6

Scale Level transition in Architectural Desktop . . . . . . . . . . 191

7.7

Example of Display Settings in ArchiCAD . . . . . . . . . . . . . 191

7.8

Example of Scale Level transition in Revit . . . . . . . . . . . . . 192

7.9

Example of adjustments on a Masterplan Block . . . . . . . . . . 193

7.10 Transition from one Design Phase to the next for one particular Scale Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 7.11 Reverse Design Phase Transition . . . . . . . . . . . . . . . . . . 195

xxxii

LIST OF FIGURES

7.12 Transition between different Scale Levels . . . . . . . . . . . . . . 196 7.13 Position of an axis line . . . . . . . . . . . . . . . . . . . . . . . . 198 7.14 Reference Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 7.15 Reference line is offset from axis line . . . . . . . . . . . . . . . . 199 7.16 Example of a grid adjustment that influences the building block . 199 7.17 Example of Height References and Reference Points . . . . . . . 200 7.18 Connections and influence of Cleanup Radius in ADT . . . . . . 203 7.19 Influence of Reference Line on the connection in ADT . . . . . . 203 7.20 Connecting walls with roof in ADT . . . . . . . . . . . . . . . . . 204 7.21 Connections in ArchiCAD . . . . . . . . . . . . . . . . . . . . . . 205 7.22 Complex connections using Profile Manager . . . . . . . . . . . . 205 7.23 Trimming walls with a roof in ArchiCAD . . . . . . . . . . . . . 206 7.24 Solid Element Operations in ArchiCAD . . . . . . . . . . . . . . 207 7.25 Aligning walls in Revit . . . . . . . . . . . . . . . . . . . . . . . . 208 7.26 Aligning unconnected walls in Revit . . . . . . . . . . . . . . . . 208 7.27 An L-connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 7.28 Different choices to position the reference line . . . . . . . . . . . 209 7.29 Joining multiple elements . . . . . . . . . . . . . . . . . . . . . . 210 7.30 T-connection between multiple elements . . . . . . . . . . . . . . 210 7.31 T-connection with aligned Reference Lines . . . . . . . . . . . . . 210 7.32 Aligning elements . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 7.33 Positioning Reference Lines on a Grid . . . . . . . . . . . . . . . 211 7.34 Concept of a Connection Wizard . . . . . . . . . . . . . . . . . . 212 7.35 Different element positioning and composition between Sketch and Construction Design Phase . . . . . . . . . . . . . . . . . . . 213 7.36 Elaborating Floor-Wall connections in the Construction Design Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 7.37 Dependence Links introduce Parent-Child Relations . . . . . . . 214 7.38 Dependence and Object Links between different Scale Levels . . 216 7.39 Example model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 7.40 Adding a Masterplan Block and the SitePart . . . . . . . . . . . 219 7.41 Simple scene with one Masterplan Element . . . . . . . . . . . . 220 7.42 Adding the second Masterplan Block . . . . . . . . . . . . . . . . 220 7.43 Adding a second Masterplan Element

. . . . . . . . . . . . . . . 220

7.44 Switching to the Block Scale Level and adding two Spaces . . . . 221 7.45 Subdividing Masterplan Element in Spaces . . . . . . . . . . . . 222

LIST OF FIGURES

xxxiii

7.46 Subdividing Masterplan Element in Spaces (simplified) . . . . . . 222 7.47 Subdividing Spaces, in this case Floors into Rooms . . . . . . . . 222 7.48 Adding additional Spaces . . . . . . . . . . . . . . . . . . . . . . 224 7.49 Switching to the Space Scale Level and adding Physical Elements 225 7.50 Returning to the Space Scale Level after adding Physical Elements226 7.51 Modifying building contour without changing topology . . . . . . 227 7.52 A conflict can occur when vertices or edges are moved . . . . . . 227 7.53 An existing simple space . . . . . . . . . . . . . . . . . . . . . . . 228 7.54 Walls enclosing a single room . . . . . . . . . . . . . . . . . . . . 228 7.55 Subdividing the existing space

. . . . . . . . . . . . . . . . . . . 229

7.56 Walls enclosing two rooms . . . . . . . . . . . . . . . . . . . . . . 229 7.57 Further subdividing the space . . . . . . . . . . . . . . . . . . . . 230 7.58 Walls enclosing three rooms . . . . . . . . . . . . . . . . . . . . . 230 7.59 A void might occur when a space is removed . . . . . . . . . . . 232 7.60 Modifications can introduce additional changes . . . . . . . . . . 232 7.61 Keeping several stages . . . . . . . . . . . . . . . . . . . . . . . . 233 7.62 Aligning floors when introducing thickness . . . . . . . . . . . . . 235 8.1

Impact of design information on design costs, from [Tro01] . . . . 239

8.2

Lower quality mesh provides sufficient accuracy in IDEA-l . . . . 242

8.3

Decreasing the required calculation steps in IDEA-l

8.4

Rendering a model directly with Radiance . . . . . . . . . . . . . 244

9.1

Possible Data Exchange paths from the design environment . . . 248

. . . . . . . 243

10.1 The AutoCAD command prompt . . . . . . . . . . . . . . . . . . 253 10.2 Grips editing in AutoCAD . . . . . . . . . . . . . . . . . . . . . . 254 10.3 Manipulators for a simple door in ADT . . . . . . . . . . . . . . 255 10.4 Manipulators for a simple door in Revit . . . . . . . . . . . . . . 255 10.5 Manipulators for a simple door in ArchiCAD . . . . . . . . . . . 256 10.6 Guides in ArchiCAD . . . . . . . . . . . . . . . . . . . . . . . . . 256 10.7 Tracker in ArchiCAD . . . . . . . . . . . . . . . . . . . . . . . . . 257 10.8 Examples of manipulators in SketchUp . . . . . . . . . . . . . . . 257 11.1 Villa VPRO (Architect: MVRDV) . . . . . . . . . . . . . . . . . 265 11.2 H2O Expo Pavilion (Architect: Nox) . . . . . . . . . . . . . . . . 271 12.1 Main structure of the prototype . . . . . . . . . . . . . . . . . . . 278

xxxiv

LIST OF FIGURES

12.2 Connection between Prototype and Frameworks . . . . . . . . . . 279 12.3 UML scheme for the IDEA+ Property System

. . . . . . . . . . 281

12.4 Graphical Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 12.5 UML Scheme of the IDEA+ Data Structure for CAAD Entities . 285 12.6 Inheritance Diagram for CAAD Entities . . . . . . . . . . . . . . 285 12.7 Inheritance Diagram for Library Elements . . . . . . . . . . . . . 286 12.8 Relation between Elements, Project and Library Elements . . . . 286 12.9 Inheritance Diagram of Physical Elements, based on [Hen00], page 94 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 12.10Inheritance Diagram for Space Classes . . . . . . . . . . . . . . . 290 12.11UML scheme with the added Masterplan Elements . . . . . . . . 293 12.12Adapted UML scheme with the Masterplan Elements . . . . . . . 294 12.13Illustrating a combination of Grids . . . . . . . . . . . . . . . . . 296 12.14Illustrating a Contour Based Grid . . . . . . . . . . . . . . . . . 297 12.15The working of the IDEA+ Factory . . . . . . . . . . . . . . . . 301 12.16Instantiating a Base Element from the Factory . . . . . . . . . . 301 12.17Join two walls through their Reference Points . . . . . . . . . . . 306 12.18Defining hole and window as part of same element . . . . . . . . 306 12.19Defining hole and window as part of separate element . . . . . . 307 13.1 CAAD Entity and Representation Links . . . . . . . . . . . . . . 315 13.2 Generate Graphical Entities . . . . . . . . . . . . . . . . . . . . . 316 13.3 Only a few different line widths are required . . . . . . . . . . . . 317 14.1 UML Diagram of Rules, used to implement transitions . . . . . . 320 14.2 Example of layers in Planar Elements . . . . . . . . . . . . . . . 325 14.3 Horizontal Connection between Planar Elements . . . . . . . . . 326 14.4 Vertical Connection between Planar Elements . . . . . . . . . . . 326 14.5 A cell as the underlying object to model connections. . . . . . . . 327 14.6 Using a matrix of cells to model a Connection . . . . . . . . . . . 328 14.7 Example results of solved matrices . . . . . . . . . . . . . . . . . 330 14.8 Solving a common wall-floor connection . . . . . . . . . . . . . . 330 14.9 Solving a more complex walls-floors connection . . . . . . . . . . 331 16.1 The Command Pattern

. . . . . . . . . . . . . . . . . . . . . . . 348

16.2 The Abstract Factory Pattern . . . . . . . . . . . . . . . . . . . . 350 16.3 Creating an Expression with Property Connections . . . . . . . . 355

LIST OF FIGURES

xxxv

16.4 Expression Builder mockup . . . . . . . . . . . . . . . . . . . . . 356 17.1 Objectifying topology . . . . . . . . . . . . . . . . . . . . . . . . 360 19.1 Screenshot of the GLUT version . . . . . . . . . . . . . . . . . . 368 19.2 Screenshot of the MFC version for Windows . . . . . . . . . . . . 368 19.3 Screenshot of the Windows and Mac OSX versions . . . . . . . . 370 19.4 Screenshot of the Linux version . . . . . . . . . . . . . . . . . . . 371 19.5 GUI Mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 19.6 Screenshot of the Main Toolbar . . . . . . . . . . . . . . . . . . . 375 19.7 Screenshot of the Modify Toolbar . . . . . . . . . . . . . . . . . . 375 19.8 Screenshot of the Create Toolbar . . . . . . . . . . . . . . . . . . 375 19.9 Screenshot of the Display Toolbar . . . . . . . . . . . . . . . . . . 376 19.10Screenshot of the Representation Toolbar . . . . . . . . . . . . . 376 19.11Screenshot of the Property Panel . . . . . . . . . . . . . . . . . . 377 19.122D and 3D Graphical Representation . . . . . . . . . . . . . . . . 377 19.13Schematic Representation of Object Links . . . . . . . . . . . . . 378 19.14Schematic Representation of Dependence Links . . . . . . . . . . 378 19.15Display of different Scale Levels . . . . . . . . . . . . . . . . . . . 378 20.1 An integrated design environment

. . . . . . . . . . . . . . . . . 384

20.2 Neutral versus Common Core Model, originally from [Hen00] . . 384 20.3 Integrating modules from IDEA+ in existing CAD software . . . 387

List of Tables 1

Overview of mailing lists and websites . . . . . . . . . . . . . . . xliii

1.1

Autodesk Installed Base Statistics . . . . . . . . . . . . . . . . .

1.2

Major players in the Mechanical CAD Market . . . . . . . . . . .

1.3

Comparison between Mechanical & Architectural Modeling . . .

2.1

Number of references to common CAD and 3D applications . . .

2.2

References to common CAD and 3D applications in CumInCAD

3.1

Compatibility Matrix between common BIM software . . . . . . 107

5.1

Suggestion for common spacing dimensions of Design Grids . . . 133

6.1

Project Structure in ADT . . . . . . . . . . . . . . . . . . . . . . 148

12.1 Example of wall parameters that relate to other objects . . . . . 310 20.1 Compatible platforms . . . . . . . . . . . . . . . . . . . . . . . . 382 2

Extracted list of BIM Applications . . . . . . . . . . . . . . . . . 410

Tags in the IDEA+ file format . . . . . . . . . . . . . . . . . . . 417

xxxvii

Introduction & Problem Statement For several years, architects are using software for Computer Aided Design or CAD. This ranges from administration and communication to drafting, modeling and simulation. Recent years have seen a widespread evolution from generic drafting applications, inspired by the traditional drawing board, to specialized systems for digital modeling of buildings, currently known as Building Information Modeling or BIM. Even though these software applications are evolving into complete solutions for the architectural practice, they have limited support for the design method of an architect. In most cases, they assume the design to be mostly finalized, before it will be translated into a digital building model. This doctoral research starts in Part I with a general overview of design applications, which are being applied by architects, engineers and visualization artists. This includes an historical overview of the evolution of CAD and a thematic overview of main application categories and concepts. The results are summarized in a database, allowing for extended querying and filtering. This database not only collects applications for drafting and modeling, but also includes additional programs for visualization, simulation and animation. From this database, some trends are extracted. There is an ongoing consolidation of the market for design software. This is caused by several acquisitions of companies, resulting in a smaller amount of major companies controlling the largest part of the market. Many firms will modularize their applications into different versions, targeted at different clients or even have different applications to distinguish between small businesses and larger corporate users. This presents customers with a growing path through different solutions. Even though these companies present their applications as full solutions, most designers are using a hybrid toolset, where different applications are being combined. The elaboration of an effective workflow between these different applications, however, poses practical problems, especially with data exchange. It is not trivial to transfer a design from one application to another, without at least some loss of information or additional data entry. The problems inherent with data exchange and an overview of different file formats is thus included with this overview. Within the general overview, a special focus is placed on the use of BIM software. The concept of BIM is based on the notion of a digital building database. This database describes a building as a series of building components and their xxxix

Chapter 0. Introduction

relations. From a BIM model other documents are extracted, such as drawings, sections and elevations but also quantity takeoffs and the bill-of-materials. Most BIM applications are developed to primarily support the generation of documents for a building permit or for the construction on site. However, applying these tools from within the the early stages of the design process presents several limitations. Especially when the design needs to be elaborated on different scale levels, there is little support to maintain a coherent design. Based on these limitations, this doctoral research suggest an approach to improve the functionality of BIM software in the early design stages. To this extent, a custom data structure, to manage a building project, is developed, alongside a prototype application, to illustrate the core functionality and the concepts from this research.

Model of the Design Process When elaborating a design, architects usually rely on sketches and calculations. Several design alternatives are tried and evaluated, in an iterative process. The evaluation of design iterations is mostly based on experience retrieved in previous projects or on education and formation. The digital translation of this process is commonly limited to modeling or drafting the design concept. Evaluation using calculations on the digital model are performed on an elaborate version of the design, rather then being continuously used during the design iterations. There is still a vast improvement potential by integrating the evaluation phase directly in the first design steps, during the sketch design phase. Adapting a design early on, based on evaluation feedback, takes less effort and yields more effect. The further on in the process, the more complex it becomes to make adjustments. Feedback from simulations might suggest modifications that are to costly or might even be impossible. Section 4 gives an overview of some current academic research projects, related to different aspects of supporting architectural design in the early design stages. This Section also references the foundations on which this doctoral research has been elaborated. In the Design and Building Methodology research group at the department of Architecture at the K.U.Leuven a framework was created to describe how the design process might be structured. Design Methodology has learned that there is not a single design method for architects, but rather a collection of different approaches. After studying the design activity of many architects, the Conceptual Model [Neu92] was established. This is a formalization of the different Design Phases in the design process and of the different Scale Levels on which the design might be elaborated. Within this framework, evaluation tests are chosen which are relevant for a particular Scale Level or Design Phase. The model relies on a design supported by Grids and is not assumed to be valid for all design methods. However, this framework is relevant for the majority of design methods. It has the ambition to cope with a considerable subset of design approaches, while at the same time remaining open enough

xli to not expose the same limitation as some of the closed building systems from earlier research. This Conceptual Model was then translated into the CORE Object Model [Hen00], giving it a specific structure of objects and functionality, aimed at a possible future implementation. The main results from this model are briefly discussed.

This Research The Conceptual Model and the CORE Object Model are the underlying framework for this doctoral research. Part II describes how a custom data structure has been set up, allowing the design to be represented as a digital building model. This data structure is then applied in a prototype application, to evaluate the structure and to elaborate a subset of the desired functionality of the CORE Object Model. It was never the intention to implement this as a completely functional system, since this requires more man power and implementation resources. The focus rather lies on some of the mechanisms to support Design Phase and Scale Level transitions, which occur during the design process. The mechanisms of the data structure and the prototype application are elaborated in Part III.

Research Methodology This research starts from an analysis of existing design applications. They are categorized in Chapter 1. Some of the more widely used BIM applications are used throughout the text as a reference for which limitations are discovered. The main concepts of the proposed data structure and prototype application are first illustrated with comparable implementations in these reference applications. Limitations are discussed and suggestions for improvement are made. This forms the main structure of Part II. Some of these improvements are further elaborated and implemented in Part III. Starting from the CORE Object Model[Hen00], the data structure is proposed and implemented. Since the development of this model made extensive use of MERODE â&#x20AC;&#x201D;as discussed further onâ&#x20AC;&#x201D;the elaboration required the understanding of Object Oriented Programming techniques and necessitated additional literature study to master efficient programming techniques. Approaches to generic programming and modularity were applied during the implementation. The development of the concepts and the prototype were not consecutive research steps, but occurred simultaneously. The concepts were adapted and revised from insight gathered during the implementation. While generic applicability was desired, a pragmatic approach was followed when required. This implies that the current structure and prototype is not completely generic and the application is not suitable for any arbitrary design project.

xlii

Chapter 0. Introduction

Sources of information Insight into the research problem is gained through several channels. • Former experience when working for several years in architectural practices and hands-on experience with several CAD- and 3D-applications helps understanding the workflow and limitations of such applications and their relevance in the architectural design process. • Literature study on recent developments in CAAD research, through conferences such as eCAADe 1 , the collected proceedings on CuminCAD [MT06] and online mailing lists or CAD portals, as listed in Table 1. • Learning and study of existing and emerging standards, such as STEP [Owe93, BW91] and IFC [Int06], but also common 3D-file formats, for the purpose of the exchange of design information. • Use of actual design examples and simulating the design process with small design exercises, which are traditionally done as sketches on paper. Additionally, extensive user experience with many different CAD and 3D applications is gained through teaching and participation in end user groups and forums. • Active study and teaching of current commercial CAAD and 3D applications. This is partly integrated in the CAAD courses2 at the Department of Architecture, Urbanism and Planning from the K.U.Leuven. A catalog of CAD and design software is also collected in an online database3 . • Participation in online forums for architects and designers using these applications, including Autodesk User Group International 4 , ArchiCADtalk 5 and 3D Buzz 6 . Also participation in activities from local user clubs, such as Computer Assisted Arts Association vzw 7 and the Flemish ArchiCAD User Group 8 (FAUG-VAGG). This includes workshops and user group meetings, to gain insight into the application of these programs in current practice and participation in beta-testing of some applications.

1 2 3 4 5 6 7 8

http://www.ecaade.org http://caad.asro.kuleuven.be http://www2.asro.kuleuven.be/asro/English/HOME/SBs or http://asro.sbuild.com http://www.augi.com http://archicad-talk.graphisoft.com http://www.3dbuzz.com http://www.c3a.be http://users.skynet.be/bert.nijs/VAGG

xliii

Table 1: Overview of mailing lists and websites Name AECbytes

AECCafÂ´e & AEC Weekly

AECnews.com

Architectural CADD Consultants architosh

cadalyst

CAD Digest

LaiserinLetter

Tenlinks Daily & Weekly

upFront.eZine

WorldCAD Access

Description & Source Analysis, Research and Reviews of AEC Technology http://www.aecbytes.com Portal for Architecture, Engineering & Construction Industry Technology http://www.aeccafe.com News and articles on Technology for Creating the Built Environment http://www.aecnews.com Help and Advice on CADD and Design Software for Architects http://www.architecturalcadd.com Webportal dedicated to use of CAD and 3D applications for Macintosh users http://www.architosh.com Webportal, newsletters and articles on CAD use in AEC, MCAD and GIS http://www.cadalyst.com Webportal for CAD, including articles and reviews http://www.caddigest.com Analysis, strategy and opinions for technology leaders in design business. http://www.laiserin.com Daily and weekly newsletters on CAD, MCAD, CAM and CAE http://www.tenlinks.com Newsletters, consultancy, blogs and books on CAD. http://www.upfrontezine.com CAD Blog from same the author as upFront.eZine http://worldcadaccess.typepad.com

Part I

Context: Design Applications, Trends, Data Exchange and Academic Research

Chapter 1

Overview of Design Applications 1.1

Introduction

There is a large collection of design applications available, both commercial and non-commercial. This section will give a selective overview of existing software which can be relevant for designers. This text attempts to use the correct Capitalization of referenced software applications and their respective company names, which is often neglected in other texts. This might be influenced by companies often changing the names of their products (or simply overtake another company and its products). A typical example is Autodesk 3ds max , which has evolved from Kinetix 3D Studio over Discreet 3D Studio MAX to Discreet 3ds max, leading to Autodesk 3ds max. At the time of writing, they seem to have switched back to Autodesk 3ds Max . . .

Motivation for an applications overview The motivation for making this overview is twofold. Firstly, the research efforts can be positioned with regard to the field of existing applications, to better illustrate conceptual differences. A second reason is the difficulty of finding a good overview of these applications, which can be utilized to compare their features. This motivated the creation of an applications and article website, focusing on CAD and 3D design applications. Feedback on the first two versions of the websiteâ&#x20AC;&#x201D;in 2001 and 2003 respectivelyâ&#x20AC;&#x201D;for which the database forms the underlying engine, already informed us about the desirability of such an overview. There are many applications available, both commercial and free, but it is hard for any user to compare them. Most of the information in the database is derived from either experience with the software applications, sometimes in a trial version, or from information that was readily available at the application home page. The online availability of the database invites users to discover relations and comparisons between applications. An additional result of compiling a database of design applications is informing designers of the large field of possible solutions. Even though this research mainly targets building information modeling, we want to enlarge the database with some of these more animation-oriented applications. There is a growing 3

Chapter 1. Overview of Design Applications

tendency of using 3D applications not only for post-design visualization, but also for design exploration.

1.2

A historic view on CAD

In this Section, we want to elaborate the definitions of CA(A)D and BIM. CAD can be the acronym for Computer Aided Design but also for Computer Aided Drafting. It is often used for the former, but at the same time often implemented as the latter. We use the term Computer Aided Architectural Design when CAD software is targeted at architectural use. When architects initially started using computers, they were not directly using CAD software. Although CAD applications existed, the main reason to introduce a computer into the office was administrative tasks. The power of the personal computer was simply too limited for running CAD-software, as known from other industries, in particular from automotive and aviation industry. An architectural office is often small and a large part of the architectural design work is on non-repetitive design, being a building, which is not a mass-product. The focus of this research is mostly on CAAD and Building Information Modeling (BIM), but in many cases, inspiration is derived from other applications, in fields as varied as animation, programming and multimedia creation. Before we start the definitions of different categories of CAD, an historic overview1 is given, to put events and evolutions on a general timeline. The overview discusses the general evolution of CAD, while the specific overview of the important categories of CAD that follow, focuses on the use of CAD and design applications by architects.

Until 1970 First traces of CAD software can be related to the US Air Force SAGE air defense system, in the fifties, but it is generally assumed that the first real CAD software was the Sketchpad application from Dr. Ivan Sutherland2 , which was developed as part of his PhD at MIT in 1963. It defined a Graphical User Interface (GUI) in a time were this term still had to be invented. Sketchpad was a design tool, which used a lightpen to input data. It also included innovations such as masters and instances, which is the same concept that is used with blocks in current CAD software. Initially, development of CAD software was performed by internal IT groups of large automotive and aerospace companies, such as Computervision, McDonnelDouglas, Ford and General Motors. These early CAD systems were typically 2D drafting solutions, which were developed in collaboration with university groups. This is also the era where classic software companies emerged, such as SDRC. 1 This overview is based mostly on information gathered at http://mbinfo.mbdesign.net/ CAD-History.htm and http://www.cadazz.com . 2 http://en.wikipedia.org/wiki/Ivan Sutherland

1.2 A historic view on CAD

1970s It is only in the seventies that CAD software migrated out of research and into a commercial use, albeit most development still happened on internal, proprietary systems. Companies such as M&S, MCS and EDS were founded in the first half of the seventies. Unigraphics I was released in 1976, based on CAM software from McDonnelDouglas, which acquired the software through the takeover of United Computing. The source-code of the CADAM (Computer Augmented Drafting and Manufacturing) system, which was developed by Lockheed since 1967, was licensed by Avions Marcel Dassault in 1975, which used it to develop the first version of the 3D CAD program CATIA (Computer Aided Three dimensional Interactive Application) , which is still in development today. Initially, two fundamentally different approaches to 3D modeling emerged. In 1972, the first solid modeling program, called SynthaVision, was released. It used concepts similar to Constructive Solid Geometry (CSG), but the performance of the computer systems of that time was lacking. In 1978, the BUILD solid modeler was the first to utilize the Boundary Representation concepts, which were developed in the early 1970s. In 1979 the IGES data format was developed by Boeing, General Electric and the National Bureau of Standards (NBS, now NIST), as the first real exchange format between different CAD systems, supporting complex 3D curves and surfaces. George Nemetschek founds a civil engineering firm in 1963 and delivers its first software system in 1977. SCIA is founded in 1974, to develop scientific application, mostly focusing on Structural Engineering and introducing the first Finite-Element program on Desktop Computers.

1980s Initially systems such as the VAX and MicroVAX by DEC seemed to dominate the market, but they underestimated the rapid adoption of UNIX workstations, which used an open software architecture. The early eighties were clearly marked by the evolution from mainframe systems to these UNIX workstations. Apollo Computer (1980), Sun Microsystems (1981) and Silicon Graphics (1982) were the first to release UNIX-based workstations. M&S was renamed as Intergraph in 1980 and Dassault Syst`emes released the first version of CATIA in 1982. SDRC releases I-DEAS, its flagship software for CAD/CAM/CAE. It includes the first automatic mesh generation system, Triaquamesh, based on the first NURBS-based modeler. At the same time, the fist personal computers appeared, from IBM in 1981. In 1982 Autodesk was founded and the same year, the first version of AutoCAD

Chapter 1. Overview of Design Applications

was released, as a 2D CAD program for PCâ&#x20AC;&#x2122;s. In 1983 Graphisoft, from Hungary released ArchiCAD. In 1984 Bentley was founded, which released the first version of MicroStation, which was a PC version of IGDS from Intergraph. The same year, CADKEY became the first 3D CAD program for PCâ&#x20AC;&#x2122;s and Apple released the Macintosh. Nemetschek releases Allplan version 1. In 1985, Diehl Graphsoft released MiniCAD, which rapidly became the most popular CAD software for Macintosh computers. The same year, Maxon was formed, as a software development company mostly focusing on Atari and Amiga software. Even then, the more powerful UNIX workstations would still be leading during the next decade, especially through their support for 3D and solid modeling. In 1981 Unigraphics released the UniSolid solid modeling system, based on PADL-2 and by the end of the decade, Unigraphics and CATIA were ported to UNIX. In 1983, work began on the creation of the STandard for the Exchange of Product model data (STEP) [Owe93]. In 1985, Paramatric Technology Corp. was founded, which released the first version of Pro/Engineer. This was the first UNIX 3D CAD software and it reshaped the whole CAD industry. Its user interface, ease-of-use and especially the speed of modeling changed user expectations of what CAD could be. It was the first commercial CAD system entirely based on solid models and it incorporated history-based features and constraints, almost 20 years after Sketchpad. The second half of the eighties was also a time when many large automotive and aerospace companies quit their internal CAD developments and started using commercial solutions. Two important modeling kernels emerged. In 1988 Unigraphics acquired Shape Data from Evans & Sutherland, which were preparing Parasolid . And in 1986 Spatial Technology was founded, which released the first commercial version of ACIS in 1989. Initially, DesignBase was another important competing kernel, but it disappeared later on. At the end of the decade, Pro/Engineer still dominated the advancements in modeling and rendering speed.

1990s In 1993, Maxon releases the first version of Cinema4D, on Amiga. Even though the classic large CAD vendors, such as Intergraph, Dassault and Unigraphics faced huge pressure from Pro/Engineer, Autodesk seemed to have the PC-market almost exclusively for itself and released several versions of AutoCAD as a 2D PC CAD program, including AutoCAD 12 which was the first version to be released for Windows. Autodesk then released AutoCAD 13 in 1994, which was the first version that supported 3D solid modeling, using the ACIS 3D kernel. Around the same time, Microsoft released its first 32-bit operating system, Windows NT, and Intel provided the first 32-bit Pentium Pro. It did not take much time before the three major modeling kernels were ported to the NT platform.

1.2 A historic view on CAD

This was helped by the availability of the OpenGL API on Windows NT since 1991, which was developed by Silicon Graphics as an open API for 3D graphics. This was followed by the porting of several CAD and 3D animation applications to the Windows NT platform. This includes CAD programs MiniCAD, ArchiCAD, MicroStation and 3D animation applications 3D Studio, Maya, Lightwave, Cinema4D and Softimage 3D. All these applications or their successors continue to dominate the market of CAD and 3D respectively. These two evolutions finally allowed the explosion of 3D CAD solutions running on PC’s. SolidWorks released their 3D CAD program at the end of 1995, which provided about “80% of the features of Pro/Engineer, at about 20% of its price”. When Intergraph released SolidEdge and Autodesk released Mechanical Desktop, both on Windows in 1996, the mid-range CAD market was effectively born. Autodesk added Inventor in 1999, which was their first large CAD product not based on AutoCAD. About two years later, Dassault acquired SolidWorks and EDS-Unigraphics acquired SolidEdge. The real technological breakthroughs seemed to have halted, though, and most 3D CAD applications began to support similar feature sets, using the same two modeling kernels, ACIS or Parasolid. To allow diversification, the focus shifted from 3D CAD to Product Data Management (PDM). The end of the decade was accompanied with acquisitions and a consolidation of the market, with the need to gain market share in the PDM market and the necessity to embrace the Internet. In the context of architectural design applications, Revit Technology Corporation released Revit in 1997, Autodesk released Architectural Desktop in 1998 and VectorWorks replaced MiniCAD in 1999. ArchiCAD was still around since its first release in 1983. At the end of the decade, Apple releases the first version of Mac OS X Server, their first version of the Mac OS to be based on technology developed by NEXT, which Apple bought in 1997. In 2001, the first desktop version is released.

From 2000 After the entire world started breathing again, because Y2K did not really pose many problems, the manufacturing companies started to increase the pressure to reduce the time to launch new products on the market. This required more integrated work flows and the focus clearly drifted further away from 3D CAD and the term Product Lifecycle Management (PLM) seemed to be the new buzzword. In 2001 EDS merged UGS and SDRC together to form its PLM Solutions line of business. The acquisition of Spatial’s ACIS modeling kernel by Dassault seemed to be one of the few important new evolutions, even though the Dassault and SolidWorks products do not even use the ACIS kernel.

Chapter 1. Overview of Design Applications

think3 introduced Global Shape Modeling (GSM) and Parametric Technology, now called PTC, introduced the WildFire 3D CAD software, which both promised simplifications in the modeling process, since the limitations of history-based parametric modeling began to arise. MiniCADs developer, Diehl Graphsoft was acquired by Nemetschek in 2000 to become Nemetschek North America. In the same year, Nemetschek also took over Maxon, developer of Cinema4D. In 2000, @Last Software releases the first version of SketchUp. Around 2005 the following vendors seem to dominate the complete CAD market: IBM-Dassault Syst`emes, using CATIA, ENOVIA and SolidWorks, UGS using NX and SolidEdge, PTC with WindChill and Pro/Engineer and Autodesk with Inventor and AutoCAD. The rest of the market is divided between several smaller CAD companies. When looking at the AEC market, the figure is quite different. The three major companies seem to be Autodesk, Bentley and Nemetschek. At the time of writing (2007), the evolutions are still continuing but more in terms of consolidation than in terms of innovation. The following list is not based on the overviews from the two source websites, but follows from personal observations, based on several mailing lists on CAD and 3D design applications. • In 2002, Autodesk completes the acquisition of Revit Technology Corporation. At the beginning of 2006, Autodesk also acquires Alias. This is discussed on page 88. • In 2005, Apple announced the move from PowerPC to Intel processors. This leads to a huge speed increase and apparently a new interest by developers in providing CAD software that runs on Macs. IMSI releases a Mac version of TurboCAD, although it is technically not a ported version of the Windows version of TurboCAD. But apart from VectorWorks and ArchiCAD, which have always been on Macintosh, other CAD vendors seldomly provide Mac-compatible versions. The audio, video and DTP industry is more dedicated to the Mac platform. • More vendors release CAD software that not only supports 3D but also additional time and cost dimensions, commonly dubbed as 4D and 5D. A particular example is the Virtual Construction-line of products from Graphisoft. • Google acquires Keyhole Inc. in 2004 and releases Google Earth in 2005. This virtual globe explorer software quickly gains interest and gets supported by many CAD and 3D applications, not only to geographically locate designs but also to place 3D models of designs. In 2006, Google also acquires @Last Software and releases a free version of SketchUp for non-commercial use.

1.3 2D CAD

• Partly based on the increased processing power of graphics adapters, more and more calculations are being delegated to the video card. GPU solutions emerge, including physics simulations and AI calculations, which are used mostly in computer games. Together with the increased rendering functionality for realtime environments, full rendering solutions are being developed. It can be imagined that this trend will slowly diverge into CAD software, after the current integration with major DCC applications. • In 2004 T-Splines, Inc.3 is founded, commercializing the T-Splines technology, which is based on the concepts of NURBS, but introduces a novel approach to improve modeling flexibility and freedom. • Autodesk aggressively markets the Design Web Format (DWF) as the best exchange format for CAD, as opposed to the Adobe PDF format. • Nemetschek takes over SCIA and Graphisoft in 2006, becoming one of the largest AEC companies world wide. • After UGS became independent from EDS in 2004, Siemens acquires UGS Corp. at the beginning of 2007, enabling the German company to provide an end-to-end solution for the manufacturing industry, including software and hardware4 to manage the complete lifecycle of products and production facilities. Some of the emerging trends, derived from this historical overview will be summarized in Section 2 on page 75

1.3

2D CAD

The actual introduction of CAD was effectively trying to replace the drawing board and its focus was clearly on 2D drafting. There have been some pioneering 3D applications, but they often required specialized hardware, which very few architectural offices could afford. The advantages of 2D CAD versus the drawing board do not need to be elaborated in detail, since it mainly came down to one factor: productivity. Most of the drawing work at an architectural office is not the drawing itself, but making modifications to projects and thus, the drawings to construct these projects. It is clear that computer tools, with even the simplest features as copying and editing line work gave an advantage over manually erasing and re-drawing on large sheets. Most concepts of these 2D CAD applications are directly related to the drawing board. Add to this the fact that drawn elements could be ordered in layers/levels and be reused as blocks/cells/library components5 , and it is clear where the productivity came from. Despite the fact that 3

http://www.tsplines.com the sense of complete facilities, not computers 5 The terms blocks and cells mean exactly the same here. They are merely the terms as used by two of the largest players in this field: Autodesk AutoCAD and Bentley MicroStation. A similar remark can be made for the terms Layers and Levels. 4 in

Chapter 1. Overview of Design Applications

a computer screen is far too small to have the same overview a plotted sheet provides, people could make more modifications in a shorter time frame. When we list some of the common features of 2D CAD, it is apparent that most 2D applications more or less follow the same approach and behave in a similar way: Line work lines, polylines, arcs, circles and parametric geometric figures, such as rectangles and ellipses; Annotation dimensions, text and labels; Modification tools copying, parallel copies (offsets and arrays), trimming and chamfering but also transformation (translate, rotate and scale); Organization tools instancing (blocks/cells), layers/levels, referencing (XRefs); Graphical properties line types, hatching, color and line widths. Some of these characteristics are only visible in printed output and not in the workspace. Some of these features have no direct counterpart on the drawing board or are much more flexible in a digital environment. Especially the possibility to change graphical entities at any time and the possibility to have a synchronization between elements that have to stay identical at all times gives an important productivity increase. There is an enormous choice of CAD software, yet two products dominate the market: Autodesk AutoCAD and Bentley MicroStation. These are two CAD applications with a very generic approach. They can be used for several goals: drafting, modeling, layout, programming or scripting and research. Autodesk AutoCAD AutoCAD, developed by Autodesk, is a generic CAD application, which is used for 2D drafting, 3D modeling, custom development and even visualization. A screenshot displaying a typical drawing session is shown in Figure 1.1. The history of AutoCAD is directly connected with the history of Autodesk itself. Autodesk has been originally founded by John Walker, who is still the largest private stockholder of the company. On his home page6 he provides an extensive overview of the first ten years of Autodesk, including information about the business plan behind the company. Autodesk was founded as a software company by a small group of programming specialists in 1982. Initially they tried to develop and launch a few very disparate applications, from which one did seem to get accepted by the PC market at the time. This was AutoCAD, although the software was originally called Interact, referring to the original software on which AutoCAD was based. This Interact application, developed by Mike Riddle, was one of the first PC-based CAD 6

http://www.fourmilab.ch

1.3 2D CAD

Figure 1.1: Screenshot of AutoCAD 2007 programs, in 19797 . Focusing on PC’s instead of mainframes and expensive UNIX workstations, AutoCAD was able to gain a market almost entirely for itself, by offering technical drafting at a fraction of the cost of commercial CAD solutions of that time. AutoCAD evolved from a generic 2D CAD application to a versatile 2D and 3D application platform, which forms the core for a few other applications. The Autodesk company evolved from a very informal group around John Walker, up to the industry giant it is today. Autodesk is one of the market leaders for several of its products. Especially AutoCAD, Inventor and 3ds max are widely used by designers world wide. The first CEO after John Walker was Carol Bartz, in 1992, who was followed up by Carl Bass in 2006. The company is evolving slowly to reach $2.000 billion in revenues, estimated for 2007 [Gra06a, eZine NEWS #496]. As reported on WorldCAD Access blog8 , Autodesk officially announced the “Seat Counts” displayed in Table 1.1. The AutoCAD number includes programs such as Architectural Desktop and Mechanical Desktop, but not AutoCAD LT, which is guessed at about three million. It is also interesting to see the continuously increasing amount of customers that are on subscription. An estimated user count of more than seven million, for all Autodesk applications, was announced at a local Belgian user event, in may 20069 . In the same 7

https://fastcad.com/x-about.html http://worldcadaccess.typepad.com/blog/2006/05/autodesk 07q1 s.html and http: //worldcadaccess.typepad.com/blog/2006/08/inventors shipm.html and http://media. corporate-ir.net/media files/irol/11/117861/5YearHistoricalQ2FY07.xls 9 An Autodesk presentation from the 20 year celebration event of the C3A Userclub is down8

Chapter 1. Overview of Design Applications

Table 1.1: Autodesk Installed Base Statistics Autodesk Seat Count Application Count AutoCAD-based 3.974.300 Inventor 592.600 Subscriptions 1.085.866

presentation, more than 440.000 ADT users were mentioned, which is included in the almost four million AutoCAD sites. Even though no official user counts are given for Revit, Autodesk announced in June 2006 that the amount of Revit installations reached 100.000 users mark10 . In may 2007, only one year later, Autodesk announced11 that the seat count of Revit surpassed 200.000 users and ADT, which was renamed to AutoCAD Architecture, kept growing to 500.000 users. In [Gra06a, eZine NEWS #496], Ralph Grabowski reported about the Autodesk Q3 Conference Call, where the total AutoCAD seat count, since AutoCAD 1.0 from December 1982 has risen to 4.056.200 copies. Embarrassing enough, the 2D Mechanical Add-on for AutoCAD is still widely sold, despite the continuous pressure from Autodesk to move users over to Inventor. At the same time, sales for AutoCAD LT are still much higher then for AutoCAD. This proves the feeling that 2D CAD is far from being completely replaced by 3D CAD. In fact, on many occasions, Autodesk reported that only about 10% of their customers are effectively using 3D CAD. The success of AutoCAD LT might have influenced the decision to launch an LT version of Inventor for MCAD12 . The application is free for one year and is said to have a retail price of less than $1.000. It lacks assembly modeling, but includes the same 3D modeling, rendering and file capabilities as the full Inventor product. Additional information: â&#x20AC;˘ Between the lines 13 is an AutoCAD-blog by Shaan Hurley from Autodesk. He also provides an overview14 of all AutoCAD releases with extensive details about the functionality in the consecutive versions. â&#x20AC;˘ Architectural CADD 15 gives a historic overview, but it has to be noticed that this ends at about 2004, where the rest of the text on the website becomes speculative and not accurate anymore. loadable from http://www.c3a.be/20jaar/AutodeskPresentatieC3A 10mei2006.pdf . The document is in Dutch. 10 http://www10.aeccafe.com/nbc/articles/view article.php?section=CorpNews\ &articleid=278870 11 http://management.cadalyst.com/cadman/article/articleDetail.jsp?id=425603 12 http://labs.autodesk.com/technologies/inventor lt/ 13 http://autodesk.blogs.com/between the lines 14 http://betaprograms.autodesk.com/history/area51.htm 15 http://www.architecturalcadd.com/classes/caddhistory.html

1.3 2D CAD

• AUGI 16 Autodesk User Group International is a portal site for all Autodesk software users. A recent review of AutoCAD can be read at the AECbytes website17 . Bentley MicroStation MicroStation can be mostly compared to AutoCAD, as it is also a generic 2D and 3D CAD application. The software has many identical features, but seems to have a more elaborated support for parametric modeling and data exchange. A screenshot displaying a typical drawing session is shown in Figure 1.2.

Figure 1.2: Screenshot of MicroStation V8 XM Edition A short overview of the MicroStation history18 . “In the late sixties and early seventies M & S Computing developed software packages for NASA and the Apollo missions. The software evolved into a multi-purpose CAD platform ( IGDS) that ran exclusively on expensive mini-computers. In 1980 M & S Computing changed their name to Intergraph. In 198619 , four brothers—the Bentleys—developed a version of MicroStation that could run on a personal computer. Intergraph and Bentley Systems worked closely to create a program that could run 16

http://www.augi.com http://www.aecbytes.com/review/2006/AutoCAD2007.html 18 From http://www-laep.ced.berkeley.edu/classes/la132/htdocs/ed134/cad1.htm 19 Bentley MicroStation dates from 1984. 17

Chapter 1. Overview of Design Applications on most computer platforms (PC, Windows, Mac, Unix). Recently, Bentley Systems has assumed greater control over the development and advertising of MicroStation and has begun to aggressively expand its market in the direction of engineering and design firms. Older versions of MicroStation for PC’s could only run in DOS, however MicroStation 95 runs in a Windows 95 or NT environment just like any other application. In the past MicroStation also used its own Graphical User Interface (GUI) which they have scrapped in favor of the standard Windows GUI.”

At the time of writing, MicroStation has evolved into a Windows-only CAD application platform, which forms the base for a whole portfolio of CAD products, targeted at different markets. These markets are called verticals by Bentley and consist of Building, Plant, Geospatial and Civil. For this overview, the focus is Building. There are some Building Products, based on MicroStation, that apply to architecture. • Bentley MicroStation is the core CAD program, which provides the basic drafting and modeling features and all the capabilities to manage design files and interact with the user interface. This includes visualization and customization features. • Bentley PowerDraft is a cheaper and lighter version of MicroStation, with all necessary drafting and basic modeling features. It is targeted as a drafting solution. • Bentley Architecture is the dedicated BIM application for architects and designers. This adds parametric building elements to the core MicroStation platform. • Bentley Structural is used for the design, documentation and analysis of structural systems, which include steel, concrete and timber elements. • Other versions include View and Redline, for reviewing and plotting of design files and solutions for Facility and Project Management. A special remark has to be made with regard to Triforma. This is a module for MicroStation, which Bentley acquired from the Belgian company Brics. This module adds parametric modeling features to MicroStation and is the underlying engine of the Architecture and Structural products. The Brics company has since evolved into BricsCAD and BricsNet. The former now produces the BricsCAD software, which is introduced further on. More info about MicroStation can be found at the Bentley website20 . Recent reviews of MicroStation can be found on the AEC Magazine website21 and on AECBytes 22 . 20

http://www.bentley.com/en-US/Products/MicroStation/Overview.htm http://www.aecmag.com/index.php?option=com content&task=view&id=117 22 http://www.aecbytes.com/review/2006/BentleyBuildingV8XM.html and http://www. aecbytes.com/review/2006/BentleyArchStructV8XM.html 21

1.4 3D CAD

What about other generic CAD applications? While AutoCAD and MicroStation are certainly not the only applications on the market, they are widely used and are representative for the type of software many CAD users utilize. Although both applications have extensive support for 3D functionality and support architectural modules, it is assumed that many customers are mainly using the 2D drafting features. Other applications that are used by architects and designers include Nemetschek VectorWorks, Graphisoft ArchiCAD, Autodesk Revit and Nemetschek Allplan. ArchiCAD and Revit will be discussed in the BIM Section on page 33.

1.4

3D CAD

Some early systems did provide options for 3D modeling, but it was not until computer hardware became powerful enough, that 3D modeling seemed feasible. Initially, 3D could be better described as 2.5D, where the third dimension was often simplified as a height property. A line with a height and some elevated position above the horizontal plane could represent a wall. The fact that CAD is often used on larger projects, with orthogonal layouts—horizontal floors and vertical walls at perpendicular orientations—meant that the limitations of 2.5D were not that problematic. Most buildings could be adequately described with this added height property. Today, most architectural CAD software, however, features real 3D modeling. These modeling features in architectural CAD are clearly derived from Mechanical Modeling software. Techniques and Definitions Giving a full overview of all modeling techniques is far beyond the scope of this research project, but a short summary of the main techniques is required, for a better understanding of the advantages and limitations of 3D modeling. Object Creation in 3D modeling is usually depending on the features that are supported by the applied modeling kernel, such as Spatial ACIS or UGS Parasolid . In many cases, a set of primitive volumes is available to start modeling, such as boxes, spheres and cones. In some cases, polyhedral meshes are available as well, but they are mainly used in DCC software. They are often accompanied with a series of operations to generate 3D volumes from curves, such as extruding, lathing or revolving and sweeping or lofting. Some applications feature freeform surface modeling, providing B´ezier and NURBS 23 surfaces [PT96]. Boolean operations provide Boolean set operations, such as unions, subtractions and intersections, allowing 3D volumes to be combined into more complex ones. 23 Non-Uniform

NURBS

Rational B´ ezier Splines or Surfaces, see

http://en.wikipedia.org/wiki/

Chapter 1. Overview of Design Applications

Viewport Navigation is essential for 3D CAD. Most applications enable fast navigation options in realtime. They usually define a virtual camera and a connected target point, which are transformed with similar movements as a realworld camera. The Pan operation moves the camera and the target simultaneously. Orbit rotates the camera around its target position, while Dolly moves the camera and target alongside the viewing direction. The Roll operation rotates the camera around the line connecting camera and target, while the Zoom operation moves the camera in the viewing direction, but leaves the target in place. These terms are also used in the movie industry, to describe physical camera moves. Modification tools are used to manipulate the created geometry. Many transformation tools are available, such as translation, rotation and scaling, both uniform and non-uniform. They can be applied from within different reference coordinate systems. Distortion of geometry, using tools such as shear or taper are less used, since they give less predictable control over actual sizes. They are applied in DCC software, were accuracy is of lesser importance. The transformation of control points for surfaces is another important modification operation. Organization tools are even more important than with 2D CAD. Many Mechanical Systems provide a full and visual control over the modeling history of parts, using a tree widget, representing the chronological steps used to create the model. Groups or Assemblies and layers are also important for better organization of the project data. Graphical properties are still important for a legible representation of 3D information on a 2D computer screen. While most applications are displaying shaded or hidden line views in realtime, it is still useful to be able to display a wireframe representation, to give access to the underlying geometry and for model inspection. Most CAD applications mainly use color to enhance the model display, but some systems start to incorporate advanced materials display, such as transparencies, shadows and textures. This is often accompanied with 3D annotation and line work, such as grids and the display of coordinate systems as axis tripods. BÂ´ezier and NURBS surfaces are widely used in product modeling and mechanical design, but to a far lesser extent in architectural modeling. On the other hand, the solid modeling techniques of extrusions and Boolean operations are conceptually easy to apply in a building context and are available in most architectural software. The modeling history tree, which is the default in mechanical modeling software is almost non existent in architectural software, even though these applications are often using the same modeling kernels. Even at the time of writing, most architectural CAD applications do not fully support freeform surface modeling. They are, at best, able to import them from other applications.

1.4 3D CAD

AutoCAD 3D and others Autodesk AutoCAD was discussed in the 2D CAD section, but it is a typical example of a generic CAD application, combining 2D and 3D features. While the 3D features of AutoCAD have improved a lot since release 2007, a majority of its users still apply it mainly for 2D drafting. Originally, AutoCAD provided only a limited amount of 3D modeling tools. Initially, 3D support was mostly in the form of giving 2D drawing entities a thickness and an elevation. This was extended with polyhedral geometry, called polymesh, which could be generated with a few simple input parameters, but the geometry was not parametric. The software incorporated the ACIS modeling kernel, with custom additions by Autodesk, which added basic solid modeling, enabling extrusions and Boolean Set operations with Solid Primitives. However, it was only when AutoCAD 2007 was released that better parametric modeling became available. The Solid Operations maintained a modeling history and tools such as sweeping provided a much requested boost in modeling capabilities. Figure 1.3, taken from the Autodesk website, displays a complex 3D model, created with the improved modeling functions and displayed with the new Visual Styles.

Figure 1.3: Improved modeling in AutoCAD 2007 While a program such as Bentley MicroStation offers even more elaborate modeling techniques, architects using these generic CAD applications are often applying only the drafting tools. In many cases, when 3D modeling is required they switch to a program such as McNeel Rhino or Google SketchUp for more efficient modeling, as illustrated with Figure 1.4.

Chapter 1. Overview of Design Applications

Figure 1.4: McNeel Rhino screenshot displaying freeform surface modeling MaxonForm An example of integrating freeform modeling with BIM software is the MaxonForm application, which is a module for Graphisoft ArchiCAD. This module is based on Maxon Cinema4D, where the 3D modeling features of Cinema4D are embedded in the building modeling features of ArchiCAD.

Figure 1.5: MaxonForm creates complex geometry inside an ArchiCAD project With MaxonForm, as displayed in Figure 1.5, the ArchiCAD user can either

1.4 3D CAD

create new geometry or modify an existing object. The MaxonForm application is launched and any modeling feature can be used, such as HyperNURBS 24 , parametric extrusions, sweeps or modifiers and all the editing tools for points, splines and surfaces. In both scenarios, the rest of the ArchiCAD scene is visible as transparent objects to help modeling. The end result is improved design freedom, but the integration with the ArchiCAD environment is limited to geometric data. The objects become native ArchiCAD library objects, but they lack all the advanced building modeling knowledge of the regular ArchiCAD objects. A wall that is manipulated inside MaxonForm ends up as a library object and does not behave as a wall anymore. This is an important limitation, which indicates that this modeling tool is mainly meant for design exploration and visualization. Autodesk Inventor and MCAD Software Autodesk Inventor, as shown in Figure 1.6, is a good example of the approach of most Mechanical design applications. The program supports parametric, feature based modeling, with an embedded design history. As with most of these programs, the designer starts from a 2D sketch, which embeds dimension driven design and supports relations between the dimensions. It is easy to indicate that the size of one line has to be twice the size of another line, or that the rounding radius between lines has to be identical to the rounding of another set of lines. This sketch can then be transformed into a 3D feature, using extrusion or revolving. This 3D feature can be additionally modeled, using fillets, to round of the 3D corners. Different features can be collected into a part and different parts can be juxtaposed into an assembly. Final drawings can be derived from this assembly and collected into layouts. A product or even a range of products can be modeled with this approach. At any time, the designer can edit the complete modeling history, to change the sketch, the extrusions, the filleting or the assembly. Polygonal Modeling Techniques A second category of 3D modeling features, known as polygonal modeling is almost non-existent in architectural software. Although they form the core of most animation oriented 3D applications, for utilization in computer games or special effects for film and television, they are not available in architectural design software. This includes the direct manipulation of vertices and faces, with features such as polygon extrusions, beveling 25 , subdivisions and inverse kinematics, which are often necessary for character animation. Especially the technique of Subdivision Modeling is popular, where a low-resolution polygonal â&#x20AC;&#x153;cageâ&#x20AC;? controls an underlying and automatically generated higher resolution organic model. An example is shown in Figure 1.7. It forms a very manageable mixture between the fast manipulation of polygonal modeling of low-resolution 24 The

subdivision surfaces from Cinema4D. edges, points or faces.

25 Chamfered

Chapter 1. Overview of Design Applications

Figure 1.6: Autodesk Inventor from 2D sketch to 3D part model models, with the visual appearance and smoothness of NURBS modeling, which is often accompanied with a great modeling complexity.

Figure 1.7: Screenshot of subdivision modeling in VIZ 2007 The reason that such techniques are hardly utilized in architecture, is probably based on demand: there is only a small number of architects that apply organic modeling into their design, so the classic 3D CAD tools suffice for the vast

1.5 Visualization

majority of architects. Those that do follow a less rigid approach are often using non-architectural software, such as Autodesk Maya, McNeel Rhino, Eovia Amapi and Autodessys FormZ but also mechanical modeling software such as Dassault Syst`emes CATIA. Some of these applications are already influencing architectural software development, as witnessed with software such as Autodesk Revit and Digital Project, which will be discussed further on.

1.5

Visualization

Introduction Architects often need to present designs to other parties. While contractors are used to interpret blueprints and technical documents, many involved parties are not trained to read drawings. Visualization techniques help to offer insight into the design and can present a project to a larger audience. Even though Visualization is strictly spoken not directly required to produce technical drawings with CAD software, this Section broadens the perspective and talks about visualization concepts that are valid in architectural design. When people started using 3D for architectural work, the primary goal was presentation and visualization. The architect could display renderings of a 3D model, which made the design result visible and often readable for the client. It is true that a technical drawing, which is the usual output of CAD, can be hard to decipher by non-professionals. This is especially important for architecture, where the majority of the clients are not professionally involved in the building industry. The presentation of a design can be improved using visualization tools. Many architects use it primarily for the creation of photo-realistic images of their design. Several techniques are utilized to reach this goal and some of them are getting integrated into architectural design software. Currently, the Architectural Visualization industry is growing. It seems that the field of visualization is far wider than only gaming and cinematic special effects. Techniques that used to appear in Hollywood blockbusters are being applied in promotional material for building projects and urban development studies. Clients come to expect a certain level of imagery from architects, to give a realistic appreciation of the design. This Section gives an overview of common techniques and will discuss how architectural visualization needs to be embedded more into the early design stages, rather than being a post-design presentation effort.

1.5.1

Rendering Techniques

When the software turns a 3D model into a 2D picture, several techniques are used to calculate sophisticated images. This is the domain of Computer Graphics (CG), where enormous efforts are done to elaborate and improve rendering algorithms. This is usually an intensive calculation task and even though these

Chapter 1. Overview of Design Applications

techniques are continuously being refined and hardware performance is increasing, the more advanced calculations still force computers into long and often slow renderings tasks. Especially all techniques that simulate some aspects of the real light interactions can be of great value to the architectural designer. Without going into their technical details, different techniques are helping in simulating realistic looking lighting conditions, which could give a huge potential feedback to the designer. Local Illumination techniques include methods to simulate how light will interact with materials. This includes the calculation of shadows, material colors, reflections and refractions. Most of these techniques are based on assumptions and simplifications, rather than on full simulations. Ray-tracing is such a technique, where light rays are cast from light sources and the rays that are calculated will interact with materials. The rays will be partly reflected, partly absorbed and partly transmitted. Global Illumination techniques solve additional light interaction, such as the way how light is effectively reflected and sent around between material surfaces. Radiosity is a Global Illumination techniques that involves the iterative calculation of an energy balance, where the effect of indirect light distribution is taken into account. A good source providing a semi-technical introduction to the working of the radiosity algorithm can be found at the website of Hugo Elias26 . Physically Based Rendering actually replaces both previous techniques. Instead of solving some part of the lighting equation with a trick, the full physical phenomenon of light is calculated. These techniques will be able to generate all lighting effects, such as refraction, reflections and indirect lighting into a single process. Examples of Renderings If there is one book that should be mentioned with regard to architectural visualization then it is “Unbuilt Masterworks” [Lar00]27 , which gives a realistic simulation of some of the designs by Louis I. Kahn, should they have been built, as shown in Figure 1.8. Larson used a combination of photographic material from existing buildings and a meticulous attention to detail to model and interpret the designs by Kahn and visualize them in a seemingly real set of photographs. The rendering application that was used, Autodesk Lightscape, is not even available anymore, yet the delicate lighting quality is still among the best visualization efforts when put aside current renderings. A good overview of the current quality of visualization can be found in the books from Ballistic Publishing 28 , such as the Elemental and Expos´e series [WS04a] 26 27 28

http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htm http://architecture.mit.edu/∼kll/Kahn book.htm http://www.ballisticpublishing.com/books/

1.5 Visualization

Figure 1.8: Hurva Synagogue, 1st Proposal, 1967-68 (unbuilt) Radiosity-based Rendering [WH05a] [ST03] [WS04b] [WH05b]. These books collect the best examples of current â&#x20AC;&#x153;Digital Artâ&#x20AC;?, prepared by artists world wide. There is a tendency to focus on Character Models29 and Science Fiction or Fantasy themes, but the previously mentioned series also contain sections on Architectural Visualization and Product Modeling. Other notable references are the [digital] series [Bir00] [Dem02] [Abl03] [Mae99] [Mae02], each focusing on a different theme, such as lighting & rendering, character animation or texturing and [OG96], which focuses on architectural visualization exclusively. Websites such as CGArchitect 30 , but also forums such as CGTalk 31 , which are members from the CGSociety 32 give a good overview of the artistic and technical qualities of current rendering applications.

RenderMan and Shading Language An overview of rendering would not be complete without mentioning RenderMan [AG00]. This is a standard for rendering applications, with a description of the possible geometry, transformations and the support of lighting and materials, through the use of a shading language. PhotoRealistic RenderMan or PRMAN 29 Many of the images show hardly dressed females, fierce alien creatures or a combination of both, which might reflect the average gender and age of the artists involved. . . 30 http://www.cgarchitect.com 31 http://www.cgtalk.com 32 http://www.cgsociety.org/

Chapter 1. Overview of Design Applications

is the best known implementation of this specification. This is commercial software from Pixar, which is now a part of Disney, that has been used in more movies than any other rendering software available. Based on the RenderMan specification, other implementations have emerged, such as BMRT & Entropy 33 , AIR 34 , Pixie 35 , Aqsis 36 , 3delight 37 and Render dot com 38 . The true power of the RenderMan specification lies in the Shading Language, which allows for an implementation independent description of advanced lighting and material properties. This is closely related to programming, although there are also graphical interfaces for shader creation, such as ShaderMan 39 . Radiance[LS98] is a classic example of a system that simulates real light interaction, although the implementation is still based on ray tracing. Radiance is oriented more at lighting designers than at artists. There is currently a new range of rendering systems emerging, that apply more to architects and artists, offering an easier approach to use realistic material properties and lighting characteristics, offering unparalleled realism. This still involves long and complex rendering calculations and is thus less used than the other techniques. Examples include Maxwell Renderer 40 , Fryrender 41 and the free alternatives Kerkythea 42 and Indigo 43 . More information can be retrieved from the application database.

1.5.2

Hardware Base Rendering

Introduction One of the major limitations in rendering is the time it takes to create qualitative images. The faster computers seem to get, the more rendering calculations people tend to require, which makes the time to generate a final image always quite long. The amount of geometry increases, but also the algorithms become more sophisticated. The output image size is also increasing. This is especially apparent for video and TV animations. Where the common NTSC and PAL formats contain 640× 480 and 720 × 576 pixels respectively, there is an evolution from SD or Standard Definition to HD or High Definition formats. With a common wide screen image ratio of 16 : 9, this implies an image resolution of 1920 × 1080 pixels44 . 33

http://www.renderman.org/RMR/OtherLinks/blackSIGGRAPH.html http://www.sitexgraphics.com 35 http://www.cs.berkeley.edu/∼okan/Pixie/pixie.htm 36 http://www.aqsis.com 37 http://www.3delight.com 38 http://www.dotcsw.com 39 http://www.dream.com.ua/thetool.html 40 http://www.maxwellrender.com 41 http://www.fryrender.com 42 http://www.kerkythea.net 43 http://www.indigorenderer.com 44 See http://www.highdef.org/library/glossary.htm and http://www.videohelp.com 34

1.5 Visualization

The result is that common software-based rendering solutions still require long rendering times for sufficient quality. This is sometimes solved through dedicated networks for distributed rendering, commonly called Render Farms. While this is a valid approach in professional visualization companies, most designers are not professional movie makers and do not have such networks available. There is an evolution of utilizing dedicated rendering hardware, which is plugged into the workstation. This diminishes the burden on the CPU, so some of the rendering calculations can be performed on a specific optimized chip. Non-realtime Hardware Rendering In regular software-based rendering, all calculations are performed by the processor or Central Processing Unit (CPU). This chipset is a general purpose unit, which can execute any calculation, but is not optimized for the specific rendering-based tasks. With hardware-based rendering, there are two approaches. The first utilizes the Graphics Processing Unit (GPU), to take over as many of the rendering tasks as can be supported, partly relieving the CPU of the host for other calculation tasks. The other approach is dedicated hardware, solely created for rendering. Some examples illustrate products that are available today. nVidia Gelato nVidia 45 is a company that is best known for their graphics display adapters. Gelato is a rendering solution for high-quality image calculations, but utilizing the graphics performance of the nVidia display cards. ARTVPS This company46 commercializes the PURE and Renderdrive cards, which are dedicated ray-tracing rendering card to be plugged into a workstation. They also provide stand-alone rendering units. They feature several processors to perform the complex calculations associated with the ray-tracing algorithms. GPUTech The RTSquare software from this company47 can be used as a stand-alone rendering software or as a plugin for other DCC applications. While it is no substitute for full quality final renderings, the rendering speed makes it a compelling option, e.g. for architectural animations, where large scenes need to be rendered as a long series of images. Realtime Rendering Hardware Largely derived from developments for military applications and for the game industry, the realtime display of a design gives the designer a very powerful representation of the design. Instead of laboriously making a physical model, the user or client can walk through the virtual building. This has been promised 45 46 47

http://www.nvidia.com http://www.artvps.com http://www.gputech.com

Chapter 1. Overview of Design Applications

since a long time, through complex virtual reality applications, of which the almost gimmick-like 3D glasses and the CAVE 48 setups are but two of the results49 .

Figure 1.9: Concept image of the CAVE system A more reachable technique lies in the fast advancing graphics adapters, using OpenGL and/or Direct3D, which are now common in personal computers, because of their use in computer games. Even though most of the technological advances in game engine design are used to display large amounts of aliens on which the user can shoot with several spectacular and violent weapons, the display of environments in realtime gives the user an absolute freedom in dwelling and exploring a design. When we strip the aliens and the action from such games, we keep highly sophisticated 3D engines, which support, in realtime, advanced lighting and material properties, combined with simulated physics, such as gravity and collision detection. The Unreal Runtime Environment is a good example, as it is a stripped down editing environment to create levels and define actions and behaviors for the Unreal Engine. This engine can be licensed for commercial work—albeit for a very large fee— and is used in the game series of Unreal and other games which licensed the engine. Other examples include Quake and Half-life, which, together with Unreal, are the most popular so-called first-person-shooters. An example of using the Quake program into a design context was mentioned at the BBC website50 . As indicated in the article, project leader Paul Richens said: “The best way to learn about a building is to run around in it, and in a computer game that is just what you do.” Another good example of a non-violent use of these technologies can be found on 48 The CAVE system is an immersive Virtual Reality system, placing the viewer inside the model by surrounded view projections. Info can be found at http://www.evl.uic.edu/pape/ CAVE and at http://www.fakespacesystems.com , the home page of Fakespace Systems, which commercialized this concept. 49 Figure 1.9 from http://www.evl.uic.edu/spiff/maxine 50 http://news.bbc.co.uk/2/hi/uk news/education/982346.stm

1.5 Visualization

the Digitally Distributed Environments blog51 , where a video is posted displaying the recreation of the famous Kaufmann House by Frank Lloyd Wright, using the Half-Life 2 Source engine. This level contains the complete house, including a large part of the surroundings and can be explored, in realtime52 , including gravity, collision detection, lighting effects and even sound. The model is created by user Kasperg and is available for download53 , but requires the Half-Life 2 game installed. Some screenshots are displayed in Figure 1.10.

Figure 1.10: Kaufmann House by F.L. Wright, recreated in Half-Life 2 for realtime exploration

1.5.3

Application into architectural practice

Visualization techniques are interesting and important in current architectural practices. When applied in a design context, people face the enormous effort to create these renderings, animations or realtime environments. In a practical situation, visualization is often a post-design effort, which limits the possible feedback it could give during the design process. This is usually due to the fact that it takes a considerable amount of input to generate the desired output. Renderings of the same quality as those from professional visualization artists are usually beyond the reach of an architectural designer, because it requires an amount of experience. This is indicated by the large growth of the architectural visualization industry, including the dedicated VisMasters DMVC Conference54 . It can be read in interviews with professional visualization firms working for high-profile architectural projects, that their visualizations often influence the decision process and sometimes even the design process itself, providing feedback 51

http://digitalurban.blogspot.com/2006/08/frank-lloyd-wright-architectual.html you look around, you can find a drivable car as well. http://twhl.co.za/mapvault map.php?id=3657 http://dmvc.vismasters.com

52 If 53 54

Chapter 1. Overview of Design Applications

to the design team, which is hard to obtain in-house. Examples can be read at the CGArchitect website55 . While it is true that such remarks might sometimes be biased or a part of a marketing effort, it is also understood that many architectural visualization artists have former architectural training or experience, which increases their sensibility with the architectural design process.

Integration of visualization tools with CAD-software That said, another emerging trend in the development of architectural applications is the integration of visualization tools with CAD-software. This can vary from integrated rendering features to dedicated plugins. Examples of visualization integration can be found in Autodesk VIZ Render, which is bundled with Autodesk Architectural Desktop, AccuRender , which is integrated inside Autodesk Revit or the LightWorks engine, which is utilized inside Graphisoft ArchiCAD, Autodessys FormZ, Nemetschek VectorWorks and many other CAD and 3D applications. An example of the possibilities of the LightWorks rendering engine as it is integrated inside Graphisoft ArchiCAD can be found in the end-user oriented book [Atk05]56 . In a similar effort, there is also a visualization oriented book about rendering with Bentley MicroStation 57 . We also see more and more realtime walkthrough applications having better integration with CAD tools, such as EON 58 , TurnTool 59 and Cult3D 60 . There are some dedicated modules as well, such as the Zermatt 61 and TurnTool modules for Graphisoft ArchiCAD and Walkinside 62 , which targets mostly Bentley MicroStation, with dedicated simulation tools for assistance in security training on offshore plants and similar industrial environments. Integration of visualization techniques into design software is very visible, but still mostly in the context of CPU-based rendering. However, migrating from game-engine development, the first signs of GPU-based rendering can be seen in CAD software, such as the Realview 63 module for SolidWorks. This complements the PhotoWorks module, from the LightWorks rendering system, which are both based on a shader language comparable to the RenderMan Shading Language. Another trend is the evolution of Shading Languages using OpenGL and DirectX, which are now being integrated in the HOOPS 3D Application Framework, which is embedded in several CAD applications. These technological shifts will probably be seen with other CAD vendors as well and have already occured with DCC applications. 55

http://www.cgarchitect.com/upclose Atkinson, the author of this book, likes to call himself “Canada’s funniest Architect” and has professional experience both as an artist and a former stand-up comedian. He now regularly teaches visualization courses for ArchiCAD users. He is also the author of a more general illustration book for use with ArchiCAD [Atk02]. 57 http://www.bentley.com/en-US/Training/Books/Rendering+With+MicroStation.htm 58 http://www.eonreality.com 59 http://www.turntool.com 60 http://www.cult3d.com 61 http://www.zermatt.se . This has become a part of EON Reality in 2006. 62 http://www.walkinside.com 63 http://www.solidworks.com/pages/products/solutions/RealView.html 56 Dwight

1.5 Visualization

Expressive Graphics Expressive Graphics 64 is a term to categorize techniques which enable designers to graphically display the status and maturity of a design, through the use of shader types. Sketch-like and soft-edged appearances indicate graphically what point the design has reached. A first sketch can be distinguished from an elaborate detailed construction model. This is comparable to the graphical styles that are used when presenting a design with hand-drawn sketches, in comparison with a final blueprint. An example, using Google SketchUp, is displayed in Figure 1.11.

Figure 1.11: Expressive Graphics using SketchUp It is important to understand that clients are often overwhelmed by renderings and the shear amount of detail in high-profile images might give the false impression that the design is finalized and that all details have been worked out. After all, the client witnesses an image of a full building. During the earlydesign stages, architects might apply non photo-realistic rendering techniques to display the design in a pleasing way, but avoiding to falsely give the impression that the design is finished.

Making photo-realistic results achievable in practice In architectural practice, it is often unfeasible to dedicate a large amount of time testing and tweaking rendering parameters and shaders. This is only obtainable for full-time visualization artists. That said, recent releases of Autodesk VIZ and 3ds max supply a series of dedicated Mental Ray shaders, called Arch & Design, which offer advanced settings, based on physical properties. This is also accompanied with a renewed Daylight System, including a Sun, a Sky and a background environment, which offer easier results. This is coupled with additional rendering presets, that take some of the burden from the artist when preparing a scene for photo-realistic results. Our own experience, coupled with the results recently obtained by students we accompanied in their Masters Thesis have indicated that far better results are obtainable, with much less effort, as illustrated in Figure 1.12. 64 The

term Expressive graphics is taken from an AECBytes viewpoint article on http: //www.aecbytes.com/viewpoint/2006/issue 25.html

Chapter 1. Overview of Design Applications

Figure 1.12: Photo-realistic results using Autodesk VIZ 2008 with Mental Ray rendering Systems that work with physically based properties promise to simplify the rendering setup. There is currently a new range of rendering systems emerging, that apply more to architects and artists, offering an easier approach to use realistic material properties and lighting characteristics, offering unparalleled realism. This still involves long and complex rendering calculations, which explains why most rendering systems still use the classic approximation techniques, such as ray tracing. Examples of such systems include Maxwell Renderer 65 , Fryrender 66 and the free alternatives Kerkythea 67 and Indigo Renderer 68 . More information about these tools can be retrieved from the application database. The emergence of these programs indicates the continued desire for many designers, both architect and artists, to create photo-realistic renderings. Radiance[LS98] is another example of a system that simulates real light interaction, although the implementation is still based on Raytracing. Radiance is oriented more at lighting designers than at artists, mainly due to the complex setup and the lesser interest for visual output. However, should a design application integrate with a system where high-quality visualization results are achievable by merely selecting the required light fixtures and material finishes from a catalogue, it seems possible to provide this directly into the design phase. When applying this into a BIM work flow, the definition of most materials and library entities is usually prepared into the main application library or templates. This suggests that in many cases, the user does not need to provide additional input. This evolution can already be seen in the automotive industry, where solutions 65 66 67 68

http://www.maxwellrender.com http://www.fryrender.com http://www.kerkythea.net http://www.indigorenderer.com

1.6 Web applications

such as HyperDrive and Hypershot from Bunkspeed 69 allow non-specialist users, such as salesmen, to create hyper-realistic renderings, using a simplified drag and drop system of preset materials and light environments. The results are interactive and still at a professional quality level.

1.6

Web applications

With all the promises of the world wide web and the rise of Google and other online only applications, it seems natural to think that CAD could benefit from online applications. While this is conceptually possible and the technology is ready and available, there seems to be little CAD use online. This can be attributed to several reasons: • Large data sets are not easily downloaded and uploaded. Complex CAD models might reach several tens of hundreds of megabytes for full projects. With reverse engineering, Point-cloud scanning techniques can easily generate gigabytes of data. Such techniques are increasingly being applied into architectural practice, especially in the context of conservation. • Protecting proprietary data and security concerns are also necessary. The output of a CAD model is not the same as the real design data, which might form an important intellectual asset of an engineering firm. To share these data with users is not evident. In many cases, web-tools focus on the sharing of flat data, such as the drawing entities or the final tesselated geometry, for reviewing purposes. • Navigation and execution speed might suffer. This is partly solved with highly compressed data sets, but also using a dedicated viewer plugin, which runs as a local application on the clients computer can increase performance. What seems to be immediately feasible, is redlining and publishing. Other applications of online tools with regard to CAD are project management, project communication and reviewing output from optimized export files, such as DWF.

Examples Some varied examples of what functionality can be expected from online applications include: HOOPS stream control is an ActiveX control that can display a CAD document online, albeit limited to Windows users, because of the platformspecific technology. It supports collaborative editing of documents. More info can be found at the HOOPS Developer pages70 . 69 70

http://www.bunkspeed.com http://www.hoops3d.com/downloads/stream control.html

Chapter 1. Overview of Design Applications

Autodesk Buzzsaw offers an online project management platform and will be discussed in Section 1.9. The application platform includes a client desktop application but also a browser based applet. While this removes some of the installation requirement for the end user, the applet is severely limited in non-Microsoft platforms. Alongside the client side is the quite expensive server-side software. The system is also offered as a service, removing the need for managing servers by the project team. ArchiCAD Project Reviewer is an approach to export a complete ArchiCAD project into a format71 ready for browsing, which can be uploaded to a web server. The user can view the different drawings, create redlining comments and print. The drawings are exported as DWF files and a Java-based viewer applet is copied alongside to let the user view and redline the drawings online. AfterCAD Another application of these concepts can be found with AfterCAD 72 . This is an application of Asynchronous Java And XML or AJAX technology. The server software prepares series of image tiles, which are then displayed to the user, without using any plugin. The use of ActiveX Plugins is quite common, but requires the user to install an external software program for the browser, which can pose compatibility or security problems. This is not always desired or even allowed by users or system administrators. The use of AJAX technology is not new, but the application for CAD is quite advanced. Upon panning and zooming, different images are loaded. The user can also add markup text or graphics on top of the drawing, which is then fed in back to the server. The company assumes that preset 3D Views could be supported using the same technology, but this will certainly not be interactive in realtime. Floorplanner from Suite75 is an online73 simple 2D CAD program for the creation and sharing of basic floor plans. Icovia A similar solution is provided by Icovia Space Planner. This uses a Flash-based plugin providing interactivity from within the web browser. It can be tried online74 . Project Freewheel is a technology demonstration75 from Autodesk to illustrate how browser based navigation of DWF files can be enabled, without any requirements for the end user. The server does the hard work of creating images from the 2D or 3D models, which are displayed in the browser window. Currently, this is available as a free service, allowing designers to publish their project online and request on-demand rendering of the files using the Autodesk server. It is unclear in what form Autodesk will continue to provide this service, but clever developers already developed 71 72 73 74 75

http://www.graphisoft.com/products/archicad/workflow management http://www.aftercad.com http://www.floorplanner.com http://www.icovia.com/design http://freewheel.autodesk.com

1.7 Building Information Modeling

the McDwiff desktop application for OSX, to display locally saved DWF files by integrating with the online Autodesk service76 . These different solutions currently target mostly the communication between the architect and the client, the contractor and other parties. However, the collaboration features will also appeal to the design phase. In multi-disciplinary design teams, online tools for collaborative design are more and more being integrated within the design process. Architectural design software is more and more capable of being integrated into a more elaborate design pipeline, communicating design to other parties and even more important, providing methods to transfer design comments back to the designer.

1.7

Building Information Modeling

When a CAD program provides additional functionality that is relevant for architects, we can talk about Computer Aided Architectural Design (CAAD). In this overview, CAAD can mean both a 2D CAD application with architectural libraries and a full 3D architectural modeling environment. In this text, we will make the distinction between geometry based CAD and BIM. CAD will be used to represent approaches that are mostly geometry based, be it 2D or 3D. On the other hand, CAAD and Building Information Modeling (BIM) are more concerned with building semantics and programs that follow an architectural design methodology. We will use the term Building Information Modeling from now on. At first sight, there is no inherent reason to drop the CAD acronym. After all, BIM and CAAD are still Computer Aided Design. However, historically and in the context of architecture, the CAD acronym has become a synonym for generic drafting and modeling, rather than for the use of architectural knowledge for the design of buildings. The choice for the BIM acronym can additionally be justified by the acceptance of the term by several competing software companies, as described on the Laiserin Website in the “BIM Debate” [Lai06]. There we can find a tremendous source of references to the discussion, including several “white papers” by several commercial companies: Autodesk, Bentley, Nemetschek and Graphisoft. Some historical background can be read at the CAD Digest website77 [CAD06a].

1.7.1

What is BIM?

Building Information Modeling can be described as a more advanced use of both 3D and database technology for architectural use. So far the overview merely talked about geometry, drawing elements and volumes. An elaborate use of layers and annotation is usually applied to deliver 76 77

http://www.macdwf.com http://www.caddigest.com/subjects/aec/select/Intelligent modeling day.htm .

Chapter 1. Overview of Design Applications

additional information with the drawing of the model, but inherently, all building information in a geometric CAD system is only stored as metadata: data about data. A designer does not draw a wall, but merely its representation. Building Information Modeling turns this around. The drawing and the 3D model become a representation of the actual building data, which can be described as some kind of database, using building semantics. The elements in the building database are semantically rich objects, with information about their type, their composition, their materials and their interlinks. To a designer, the biggest advantage is model coherence and productivity gains. The different drawings are not unrelated anymore, but will be derived from one central model: the building database. The position of elements in a section or in a floor plan is identical and modifications in one representation are visible in other representations. The main focus of commercial BIM applications is clearly the output for the construction phase. Even though there are tools to support design exploration, such as mass modeling tools for volume studies, the focus clearly lies on the output rather than the input. This is also apparent in the popularity of an application such as Google SketchUp, which is a 3D modeling application with particular strengths for architectural models: fast workflow and sketchlike appearances. There are several plugins to allow these design models to be incorporated into CAD software, where the design is more or less considered as finalized. Bentley holds a BIM Executive Summit yearly. The presentations of this conference can be accessed online78 . The U.S. General Services Administration (GSA) has elaborated a National (read: U.S.) 3D-4D-BIM Program79 , including specifications and pilot projects. There is a Spatial Program Validation, including specifications for what a spatial building model should contain. The program also identifies the project process, including the use of 3D Laser Scanning for data capturing and Energy Performance simulations. While this applies mainly to the American building market, the information is fairly generic and can be partially applied elsewhere.

1.7.2

Example BIM Applications

This is an overview of some common BIM-applications, which are in use in current architectural offices, world wide. For other applications, the reader is referred to the appendices and the online database. While this overview is rather brief, more detailed information about these applications is found in other Chapters, where ArchiCAD, Revit and Architectural Desktop are used as reference implementation to position the concepts of this doctoral research. 78

http://www.bentley.com/bimsummit http://www.gsa.gov/Portal/gsa/ep/channelView.do?pageTypeId=8195&channelPage= /ep/channel/gsaOverview.jsp&channelId=-18161 79

1.7 Building Information Modeling

AutoCAD Architecture/Autodesk Architectural Desktop (ADT) This is a commercial BIM application from Autodesk, which is made on top of the generic AutoCAD drawing and modeling software. The software adds AEC objects to AutoCAD and provides a main workflow for architectural design. In ADT a combination of general AutoCAD techniques are coupled with custom objects to define an assembly of a building. Different floors are usually placed in separate documents and collected together using the XRef technique. More background information about Architectural Desktop can be found in [ADT06a] [Yan06] [Koc06] [Aub06] [ARC06] [ADT06b]. A review of Architectural Desktop can be read at the AECbytes website80 . In 2007, the program was released under the AutoCAD Architecture name. Some of the recent improvements include automatic generation of rooms, which will adapt when walls are modified. There are also more and more possibilities to generate tabular data directly from the model, including linking to Excel. While Autodesk is actively promoting Revit as the most elaborated BIM-solution, it still develops ADT, for people who prefer an AutoCAD-based solution. Alongside the Architecture version of AutoCAD, there are also other configurations, such as AutoCAD MEP , AutoCAD Electrical, AutoCAD Civil3D and AutoCAD Map3D. Graphisoft ArchiCAD Graphisoft develops ArchiCAD for already more than twenty years commercially. The software was originally developed for the Macintosh platform, but is available for Windows too. ArchiCAD is a standalone design application, where a â&#x20AC;&#x153;Virtual Buildingâ&#x20AC;? is used as the central 3D model, from which other representations are derived. The main interaction happens in the 2D Window, which accesses the building model floor by floor. More background information about Graphisoft and ArchiCAD can be found in [Gra06c] [Boj05] [Atk02] [Atk05] [MP04]. David Nicholson-Cole, professor at the School of the Built Environment in Nottingham wrote a course book about GDL, the Geometric Description Language which is used at the core of ArchiCAD [NC00]. Recent reviews of ArchiCAD can be read at the AECbytes website81 . ArchiCAD has been a BIM solution for a long time, but Graphisoft acquired two additional solutions to extend ArchiCAD beyond the use by architects. Constructor and Estimator are two solutions for Virtual Construction. They allow the designer to model not only the building but also the construction process, including time scheduling. When a column is modeled, not only the end product is simulated but also the different steps to produce it, including temporary 80

http://www.aecbytes.com/review/2005/ADT2006.html http://www.aecbytes.com/review/2006/ArchiCAD10.html and http://www.aecbytes. com/review/2007/ArchiCAD11.html 81

Chapter 1. Overview of Design Applications

site constructions and all materials and manipulations. In 2007, Nemetschek acquired Graphisoft, adding it to their Allplan and VectorWorks solutions, effectively becoming one of the largest companies for AEC software, world wide. However, the Virtual Construction division from Graphisoft was spun off82 as Vico (Virtual Construction)83 . This new division of Graphisoft will still be using ArchiCAD as the core CAD engine. There is a range of different solutions, from modeling, over estimating and scheduling to procurement and control. This can be done with individual applications for each step in the process, but they can be combined to present a complete solution. It has to be mentioned that when Graphisoft initially launched its Virtual Construction offerings, it insisted on not simply providing a software application. Many construction firms have to learn to translate their whole business process with such tools and it comes as no surprise that Graphisoft offered this as a consultancy service alongside the application development. This includes both the simulation services itself and the software application consultancy, to integrate the solutions into the current business practice of a construction company. While this suite of applications is not cheap, these costs are almost negligible in the actual project organization structure. BricsCAD Architecturals Built as a module for IntelliCAD or AutoCAD, this is an architectural design application, utilizing a solid model from which other representations are derived. The Belgian company BricsWorks was founded in 1986. This was the name of a modeling software for architectural design, as a combination of geometric modeling and building information. Bentley Systems used this technology as the core for their Triforma module in MicroStation. The company then focused on Project Management solutions under the name Bricsnet. In 2002, the original founder bought out the CAD solution which is since known under the BricsCAD name84 . BricsCAD is a member of the IntelliCAD consortium, so is allowed to use the IntelliCAD source to develop and market a stand alone CAD application. BricsCAD provides both IntelliCAD and the Architecturals module. The former is a cheap competitor to AutoCAD, while the latter adds Building Information Modeling to both IntelliCAD and AutoCAD. In the Architecturals module, the connectivity between building elements is embedded and maintained. Modifications to elements will update connected elements, keeping the building model synchronized. From this 3D model, plans, sections and elevations are derived, allowing all documents to correctly reflect the state of the building model. BricsCAD defines the building model and stores it in the DWG format, which allows for flexible document exchange with other parties. It uses a Styles system, to define common attributes between building entities. 82 http://www.graphisoft.com/company/investor center/GRPH 02122007ENG.html , comments are on http://www.evanyares.com/the-cad-industry/2007/4/24/virtual-construction. html 83 http://www.vicosoftware.com 84 Summarized from http://www.bricscad.com/company/history.jsp .

1.7 Building Information Modeling

More background information about BricsCAD at the BricsCAD Website85 . Autodesk Revit This application starts from a centralized building model, from which all representations are derived. Each representation functions as a view on the central model and any change in the views is reflected immediately in the other views. Revit is specifically developed for a BIM workflow. It has been acquired by Autodesk and is not based on AutoCAD. What distinguishes Revit from the other applications are the parametric constraints that can be placed, where elements can be connected or aligned and also driven by a dimension. These concepts are well known in Mechanical CAD applications, but have not been applied in architectural design applications. More background information about Revit in [Rev06a] [Rev06b] [Zoo06] [Rev06c]. A recent review of Revit Building can be read at the AECbytes website86 . In 2007, Autodesk released the 2008 version of Revit, renaming it to Revit Architecture, to clearly distinguish it from Revit Structural and Revit MEP . Discussion around BIM Some additional opinions and reviews on the use of BIM and on BIM applications can be found online. The LaiserinLetter [Lai06] includes a collection of mailings and discussions with regard to the adoption of the BIM acronym, in the BIM section of the website87 . This includes webcasts and white papers from different involved companies. A description of how the BIM concepts are being integrated into the workflow of some large US Building Industry firms88 indicates that the increased use of BIM is definitely not limited to architects and designers, but can benefit the whole construction industry with better insight into design projects.

1.7.3

CAD and BIM use in architectural practice

Even though there is a growing availability of applications supporting building information modeling, many architects still use common 2D CAD applications. This section tries to give some reasons for this, but cannot rely on quantitative information. Architectural offices are often small and hesitative to changes, at least that is the situation in Belgium, where the architect is usually both the designer, project manager and site supervisor. Certainly when deadlines are close and pressure from clients is high, there is little time to change existing working habits. The reality is that most building partners have no need for the additional building model at this time. Building authorities only require plotted 85 86 87 88

http://www.bricscad.com http://www.aecbytes.com/review/2006/RevitBuilding9.html http://www.laiserin.com/features/bim/index.php http://www.bdcnetwork.com/article/CA6354606.html

Chapter 1. Overview of Design Applications

drawings and there is no demand for 3D information. Even though some authorities have installed a conformization procedure, such as CORENET ePlanCheck in Singapore as discussed in Section 1.8 on page 41, this is the exception to the rule. There is a chance that a younger generation of architects, who have been introduced to these concepts and who sometimes have less hesitation to learn new applications, might introduce these concepts in offices, provided they get an opportunity to apply this in a pilot project. Are there reasons not to adapt BIM? • It is expensive to learn new working habits. • Many architects are not familiar with the concepts. They often have been trained with manual drafting or 2D CAD methods. The training cost for an office to switch to a BIM-based process can be high. • There still is a limited choice of applications supporting BIM. When comparing with 2D or 3D CAD, BIM applications are usually expensive89 . In larger offices, it becomes more difficult to divide the work between project engineers, working on the BIM Model in one program, while drafters continue to work in separate 2D CAD software. The workflow has to be re-evaluated, to avoid reintroduction of data and to keep the approval process clear. • People might fear to be limited to one supplier, with possible uncertainty about product continuity or price increases. When only 2D drawings are drafted, it is easier to switch to other applications, for reasons of cost, availability or productivity. With BIM software and incompatible proprietary file formats, it is almost impossible to transform the full BIM model without errors into another application, even when the software is from the same vendors. • It is sometimes hard to see the benefits, when all project communication is paper based or—at best—based on 2D CAD, through the use of DWG, DWF or PDF documents. • To draw a building in a BIM application requires more construction knowledge and experience. The designer needs to understand how the project is structured before it can be modeled and correct drawings can be generated. In larger offices, the use of BIM requires more people with construction knowledge rather then drafting capabilities. There will be a different cost-productivity structure. More time will be spent up front, at the design stage. This is usually performed by architects or engineers rather then drafters. In the case where the project will be halted after the initial design, which often happens in competitions, the cost to the office will be much higher. Of course, the real productivity in the further stages can increase, through faster drawing generation and easier synchronization between drawings. 89 Most

BIM applications have a retail price between e4.000 and e6.000.

1.7 Building Information Modeling

â&#x20AC;˘ The ability to keep adjusting the design project until the construction phase also poses a danger. In a classic drafting based workflow, there is no way the whole building layout will be adjusted when the final construction drawings are being finalized. In BIM this is possible, but at the same time, it should be avoided. Users have to take care not to continue developing the design throughout the whole project cycle. â&#x20AC;˘ Many BIM applications have limitations to take freeform objects and treat them as valid building objects. Even when the BIM application allows the import of geometry from other applications, such as polygonal meshes or NURBS surfaces, it is often impossible to use the imported geometry as a true building object. This can be a major issue for firms who introduce BIM software to replace the existing hybrid set of modeling and drawing tools. An important limitation with current BIM applications is the lack of integration of geometrical objects and annotation into the building model. Annotations are mostly used to finish the drawings, but the data they present is not always fully visible from the model data. Additional research on BIM From an academic context, there is a lot of attention to BIM. It is widely discussed on conferences and in publications. That said, most articles are not suggesting the creation of new design applications but focus on productivity and work flow. They investigate collaborative design methods or evaluation and simulation tools that operate on IFC files. An interesting study around drawing production methods [Shi96] illustrates concepts that have been traditionally applied in generic CAD drafting. This study, along with other studies, such as the research on CAD usage [BFF+ 95], are still mainly valid in a BIM context. The use of BIM in many practices has increased recently, but many conceptual problems are still unsolved. A recent Cadalyst article [cad06b, Article ]42961790 ] gives an interesting overview of the use of Digital Design Tools by a selection of different architectural firms. This ranges from fully integrated use of BIM software to combinations of 2D drafting and 3D modeling software. This article also quotes a survey from the American Institute of Architects (AIA) on the use of design software in architectural practice. The survey indicates little more than 16% of firms are reporting to have acquired BIM software, while about 10% is said to have been actively using it for billable work. There is a trend that sees BIM being applied more often in larger firms, where the survey mentions that the usage of BIM software in those firms who have adopted it for billable work is about 60% for sole practitioners versus more than 85% in firms with more than 100 employees. A good example of the application of BIM methods in the context of architectural history can be found in a case study for historic reconstruction of synagogues by Martens et al. [MP02]. While the study uses a common BIM application, in casu ArchiCAD, it suggests that a structured approach can hugely 90

http://aec.cadalyst.com/aec/article/articleDetail.jsp?id=429617

Chapter 1. Overview of Design Applications

improve the documentation and reconstruction process, which is important with the sometimes delicate nature of these projects. In all these examples, BIM seems to be accepted as a methodology, but mostly as a production and documentation system. There seems to be little attention to the application of BIM in the actual design process itself. In many publications, the BIM model is simply assumed to be provided by the architect in the IFC format, suggesting the use of common commercial BIM applications, rather than exploring new design concepts. Main limitations of current BIM applications For many purposes it is required to define a spatial model of a building, through the definition of rooms. They require information about area, volume and desired activity and climate conditions. While most BIM applications provide means to define rooms and other spatial elements, they are usually treated as second-class design entities. Most applications require modeling the enclosing building elements, such as walls, floor and roofs, prior to the creation of the spatial elements. While there are approaches to update the spatial model when the building entities are modified, there are almost no possibilities to use spatial entities as real design elements, driving the enclosing elements or even creating the enclosing elements. While this was already apparent with regular CAD or modeling software, the improvements from BIM software on spatial modeling are limited.

1.8

Building Simulation

Whereas Building Information Modeling is describing an approach to define the content of a building, Building Simulation applications start from a building model in some form and use it to derive additional information. Simulations can be categorized based on the desired information extraction.

Structural Calculations Beams, Columns, Plates and other structural components using different materials, such as concrete, steel, wood or combinations need to be calculated before they can be manufactured. Those calculations range from simple spreadsheet forms to fully customizable applications with a graphical interface, that not only perform the calculations but also generate the required technical drawings, e.g. the reinforcements for a concrete beam. Similar to a building information model, which is created within BIM applications, these applications create a structural representation of the building, with loads and forces, together with axes and hinges to simulate beams, columns and other structural building elements.

1.8 Building Simulation

• SCIA91 develops and distributes a range of analysis and engineering applications, such as SCIA.ESA PT and ESA-Prima Win. • BuildSoft 92 distributes different applications, such as PowerFrame, PowerConnect, ConCrete and 1·2·Build. • AXISVM 93 provides structural analysis software using Finite Element calculations. This also exists as a plugin for use with Graphisoft ArchiCAD 94 . • The Graphisoft website provides a selective overview of connections between Structural Design evaluation and the ArchiCAD BIM software, utilizing IFC files to translate the building data95 .

Energy Simulation Thermal calculations, solar energy, heat loss simulation, ventilation and other calculations are all required for the total energy balance of a building. Different tools can perform these calculations. • ECOTECT 96 is a standalone graphical application for building simulation, including shadow and reflection calculations and solar, acoustic and thermal analysis. • EnergyPlus 97 is a building energy simulation program for heating, cooling, lighting, ventilation and other energy flows. It has no graphical user interface98 , but can convert some file formats from CAD software. • GreenBuildingStudio 99 is an online service, which specifies the open Green Building XML scheme (gbXML), which can be used for different engineering simulation tools, such as DOE-2, EnergyPlus and others. Architects can start from their BIM application, while engineers can perform the calculations in their own simulation software. The service is currently targeted at the US market.

Conformance Checking Local authorities require more and more of these calculations to be included in a building permission application. In Belgium, the EPB -regulation (Energy Performance and Inner Climate Regulation), which is based on European regulations, has been made obligatory in 91

http://www.scia.be/ http://www.buildsoft.eu 93 http://www.axisvm.com 94 Unfortunately, the plugin is not updated for recent ArchiCAD releases. 95 http://www.graphisoft.com/products/archicad/solutions/structural.html 96 http://squ1.com/ecotect 97 http://www.eere.energy.gov/buildings/energyplus/ 98 It is announced that a SketchUp-like interface is in the making. 99 http://www.greenbuildingstudio.com 92

Chapter 1. Overview of Design Applications

2006. The government distributes a Java-based application100 which is required to be used for the generation of the correct administrative forms. There is no automatic generation of these documents from current design applications, although a research group of the UGent (Belgium) is currently elaborating a project to automate the generation of these data from an Autodesk Revit BIM model.

Other examples â&#x20AC;˘ Solibri Model Checker 101 is an application that performs analysis and requirements testing on IFC files. The application interprets IFC files and generates analysis reports. The results can also be directly visualized as a 3D building model. The 2006 release102 includes comparison between different files, e.g. to check if the wall that was indicated as load-bearing in the architectural model has a counterpart in the structural model, even if the wall was replaced by a combination of columns and beams and a light structured wall. â&#x20AC;˘ In Singapore, a series of procedures has been set up to organize a complete digital administration process for building permits and regulation checking. This system is called CORENET ePlanCheck 103 and is based on IFC files. This procedure is described in detail on the AECBytes website104 and on the IAI website105 . Graphisoft announced that their ArchiCAD BIM software was the first software to get certified for this procedure106 107 . Autodesk Revit Building release 8 received IFC Stage One certification in 2005108 , which is one of the requirements to be able to participate in the ePlanCheck system.

Conclusion and evolution These applications display different trends, from ALL-IN-ONE solutions to black-box simulation engines. An application such as ECOTECT is evolving into a full design-model-simulation environment. While this might make it seemingly easier for users to create simulations, it is a difficult approach. When a company or research group which 100

http://www.energiesparen.be/energieprestatie/professioneel/software.php http://www.solibri.com 102 http://www10.aeccafe.com/nbc/articles/view article.php?section=CorpNews\ &articleid=306108 103 http://www.corenet.gov.sg/Corenet 104 http://www.aecbytes.com/buildingthefuture/CORENETePlanCheck.htm 105 http://www.iai-international.org/IndustrySolutions/sgCORENET.html 106 http://www10.aeccafe.com/nbc/articles/index.php?section=CorpNews\&articleid= 168291 107 http://aec.cadalyst.com/aec/article/articleDetail.jsp?id=152065 108 http://usa.autodesk.com/adsk/servlet/item?siteID=123112\&id=5481567\&linkID= 7770998 101

1.9 Administrative CAD

focuses on energy simulation is also adding a full CAD application as a front-end to the simulation core, people get high expectations. They expect everything they have grown familiar with from their CAD application to also be available in these simulation applications. It is unlikely that this simulation front-end would have the feature set or the flexible work flow that is known from common widely used CAD applications. It is thus unlikely that the application will fully satisfy the user, who is reluctant to step out of his or her CAD application. As an alternative, it might make more sense to integrate the simulation engine directly into existing CAD applications, provided that there is enough accessibility into the underlying model. Or the work flow could be improved, by providing dedicated export routines from the CAD model into the simulation engine. Even then, with already complex CAD applications, it is often not easy to create an optimized interface and work flow for such tasks. Many of the concepts and parameters that are required by the simulation engine are non-existent in the CAD software. It is even more difficult when a simulation engine targets multiple CAD platforms. These firms often opt to only support a single CAD application and this is usually AutoCAD, based on its large amount of users and its extensive programmability. With simulation tools this is not a trivial approach. While generic CAD applications can usually provide the required 3D geometry, they are often unaware of building information. Only when a simulation engine is integrated into a real BIM application, will the actual building data be accessible, such as spaces, rooms and building structures. But then again, the choice of BIM applications is limited and they are not always open for programmability. The traditional approach, where the simulation engine is a stand alone solution, requiring elaborate data input from the end user, is getting problematic for many users. With evolving designs, the labor intensive task of creating input files for many different applications is often unfeasible in the current context of shortening deadlines and more complex building projects. It is assumed that the evolution of BIM standards, such as the IFC format might be a good solution, where most current BIM applications can create a model with enough information about the building so simulation applications can use that as input.

1.9

Administrative CAD

In this short Section, some approaches to manage the work flow in an architectural office are discussed.

1.9.1

Programming Phase

In the Programming Phase, the architect needs to communicate with the client about the desired results for a design. This includes budget, areas and functionality. While this phase is usually not performed in a CAD environment, there is

Chapter 1. Overview of Design Applications

an interesting solution from Trelligence 109 , called Affinity. This system tries not only to create the whole set of project requirements in a structured database, but goes a step further by translating the design brief into a schematic design. It even continues this step by providing connections with BIM software, such as ArchiCAD. This is a nice example of an approach to integrate a product into an existing pipeline, rather than defining a whole new pipeline around their own solution.

1.9.2

Document Management

There are several Document Management Systems available. While most of them are very generic in nature, to be applied in many different businesses, a few products specifically target the building industry. They sometimes offer additional features oriented at the use of CAD documents, such as review procedures using redlining. Autodesk Buzzsaw is a collaboration platform110 , mainly used for project management for the building industry. Users can set up a project on an online server, define user permissions and communicate with the different project partners. Documents include CAD drawings, Office documents, links and discussion notes, together with a notification system for changes. It is typically managed by the design team, which grants the desired permissions for consultants, clients, contractors and all other involved parties.

1.9.3

Project Planning and Management

There are generic project planning applications, such as Microsoft Project or the Open Source alternatives such as Gantt Project 111 and GNOME Planner 112 . But in this Section, it is more interesting to look at solutions that specifically target the building industry. Bricsnet provides a a web-based solution for Workplace Management, called Building Center 113 which provides property management, maintenance and asset management and central storage of data and applications. The whole system is accessed from a browser. Another solution is ProjectDox 114 , focusing on both building project management and the development of an electronic permit process. It also supports 2D CAD data, alongside regular Office documents. D-studio 115 is a Belgian firm who offers several products for planning, project management and construction site follow-up. 109 110 111 112 113 114 115

http://www.trelligence.com http://www.autodesk.com/buzzsaw http://ganttproject.biz http://live.gnome.org/Planner http://www.bricsnet.com/building-center.html http://www.projectdox.com http://www.d-studio.be

1.10 Software for preliminary architectural design

1.10

Software for preliminary architectural design

Despite the fact that the market of architectural software seems crowded with CAD software, the early design stages is an area for which there is much less competition. Former personal experience in architectural practice did show that many younger architects start using CAD software to create early design attempts, mainly for the better support for working with accurate dimensions. Especially in renovation projects, architects will often create a draft of the current building and use a combination of manual sketching on printouts and creating digital CAD drawings, before the actual design is finished or transformed into construction documents. If this is caused by the advantage of these digital methods or more by the lack of experience and quality of hand drawing by many younger architects is not known. In the educational context of training students of architecture, the adoption of digital methods is evident. Many students start working on the computer from the beginning. While this seems to be an advantage, it must be said that at the same time, they still have only minor experience. In the BIM classes, this became evident when constructing a 3D model of their design studio assignment. Many students are capable of using the applications, but fail to model a structurally sound construction. While recent evolutions of BIM software might suggest a wide adoption of these methods in many architectural offices, remarks from other practicing architects and contact with CAD software resellers has learned that these evolutions are not occurring at a fast speed. These changes are not trivial in a design practice, which at all times has to keep to its own schedule and promises to clients. To embark with new software approaches is not something that can be done lightly. This might be motivated by the decreasing experience with manual drafting and working accurately on scale, which can be noticed with a younger generation of architects. We have witnessed several discussions between senior and junior staff, precisely on the validity of using the CAD application during conceptual design. This has been questioned in [BG05], where the role of CAD during Conceptual Design is investigated. In that paper, it was suggested by an experiment that designers were able to create a mental representation of a project during the design process, with or without the use of CAD software. In [GM06] and [MBG+ 06], different design experiments were executed on collaborative design in an online environment. The design was elaborated with a combination of a 2D sketch pad and a 3D world. The experiment showed that the focus from the designers during the design shifted from abstract design using the 2D environment to 3D for the elaboration. It was also in the 3D environment that most of the design time was spent, not on creating entities but manipulating them. This experiment both illustrates the validity of a digital environment during the design stage and the different approach that originates from working in 2D or 3D. The 3D World supports collaborative modeling of the design solution, while the 2D sketch pad supports the exploration of the

Chapter 1. Overview of Design Applications

design ideas themselves. Both have there place in the early design stages, so an ideal environment should still present the user with both modes. However, much of the research on CAAD in the context of design exploration is based on the assumption that digitized information and retrieval processes, which are enabled by the use of the computer, could aid the designer and possible improve the design results. This section briefly mentions software applications which are being used in architectural practice and which seem to appeal to many designers, as early as from the initial design exploration phases.

SketchUp The first application that is being increasingly used in architectural design is Google SketchUp. This is a 3D modeling application with a fast and fluent workflow that makes it particulary usable for architectural design. As a modeling application, it does not compete with any existing software, yet offers a workflow that is complementary to any CAD or 3D software. Couple this with a modest price of about $500 and sketch-like display properties, such as slightly offset lines extending past their endpoints, and it is clear that many architects embrace this program. Since it also allows the designer to import and export to common 3D formats it has its place in the workflow of any architect. It does not try to be a CAD application as such, which makes it attractive as a companion program for all other CAD software, especially since it runs on both MS Windows and Mac OSX. Figure 1.13 displays a small house model116 and different possibilities to display it in the main viewports, including realtime shadows, X-Ray transparent surfaces and sketch-like line types. While the SketchUp application is not meant to replace drawing software, since there is no full support for hatching, scaled output or plain 2D productive drafting, many users are using it anyhow. It is being extended with custom scripts and even with visualization modules, to broaden its intended scope. When Google took over the small previous developer of SketchUp, it made a free version widely available and also set up connections with Google Earth, to place models on geo-referenced coordinates, including aerial images, and the Google 3D Warehouse, which is meant to become a place for free download of 3D models. The impact of Google should not be underestimated, since most current design applications, including AutoCAD, Revit, ArchiCAD and MicroStation have plugins to better integrate with SketchUp. SketchUp is also used in many architectural schools and through conversations with students at our department, they seem to have adopted SketchUp as their primary design application in many cases. Several master theses and design studio projects are being modeled mainly in SketchUp, usually accompanied with AutoCAD for construction drawings. 116 Design:

Stefan Boeykens

1.10 Software for preliminary architectural design

Figure 1.13: Google SketchUp with versatile visual styles The quick modeling and presentation features are starting to influence other competitors, most notably Autodesk, which added similar modeling features to AutoCAD 2007 117 . While it can be argued that AutoCAD has the speed and ease-of-use of a program such as SketchUp, it is being applied during design exploration as well.

Impression Autodesk Impression (code name Vespa)118 is a stand alone presentation application, which manages 2D drawings and defines visual styles to create stylish, almost hand-drawn looking presentations. A technical CAD drawingâ&#x20AC;&#x201D;slightly prepared with the Vespa application in mindâ&#x20AC;&#x201D;can be quickly stylized using pre-defined or custom styles. Styles include color, line types and fill settings which mimic pens, pencils, brushes and felt markers. There is complete control over color, texture, line styling. An example, taken from the included sample documents, is shown in 1.14. This is a purely 2D drawing, but enhanced with the flexible styles, to give it a human touch. The common workflow of Impression is transforming existing CAD drawings into sketches and presentation drawings. It contains some basic drawing and transformation functionality, but the focus is clearly on finishing CAD drawings from AutoCAD. This indicates that it might be of lesser use in preliminary design, where the exploration process is more important then the visual output. But it has to be said that the software has been available for beta-testers for 117 The 118

pushpull feature from SketchUp is called presspull in AutoCAD 2007. http://www.autodesk.com/impression

Chapter 1. Overview of Design Applications

Figure 1.14: Autodesk Vespa/Impression screenshot quite some time, where the product team still requested feedback about the direction where to take this application. This workflow might seem remarkable. While a sketch presentation might seem appropriate to present an early design, in a rough form, this application actually assumes the design to be drawn in AutoCAD. It does present methods to update the presentation when changes in the DWG file occur, but the combination seems quite contradictory. In practice, when browsing through the discussion forum119 many people seemed interested in applying this software into their current office, but always as a sales tool or a presentation tool with clients and not as a design aid. Our own attempts using the application, as shown in Figure 1.15 have learned that it requires a very precise and clean CAD drawing to generate compelling results, which seems indeed to point into the direction of a post-design presentation tool rather than as an early design exploration tool. Architectural Studio It is remarkable that Autodesk regained interest in the early design phase, especially since the discontinuation120 of the Architectural Studio application as shown in Figure 1.16. This application was built around a drawing board metaphor, using pens, felt markers and simple modeling tools. Lack of commer119 During the beta phases, the discussion forums served as an aid for communicating not only about the functionality of the program but also about conceptual decisions. 120 http://www.aecbytes.com/newsletter/2004/issue 13.html and http://rcd.typepad.com/ rcd/2004/08/autodesk archit.html

1.10 Software for preliminary architectural design

Figure 1.15: Presentation with Impression from an AutoCAD drawing cial interest seemed to be the major reason to the demise of this still remarkable application, which promoted the use of a pen or stylus.

Figure 1.16: Architectural Studio screenshot While Impression and also the visualization software VIZ continue to be improved for architectural design use, they require CAD drawings or CAD models to start from, usually suggesting they be created in AutoCAD. But AutoCAD itself is mainly a technical drawing and modeling application and is less adapted for conceptual design work. Even though the modeling features in AutoCAD

Chapter 1. Overview of Design Applications

have been extended, the application of Impression and VIZ are usually postdesign efforts. In fact, the only real conceptual design application from the Autodesk portfolio, Architectural Studio, has been canceled. Others Other applications that are applied in the early design stages are usually not based on CAD and often not even on 3D. Many architects still sketch their masterpieces on a piece of paper. A younger generation of architects additionally applies digital collage techniques in programs such as Adobe Photoshop or Adobe Flash to develop or present a design. There are also the numerous 3D modeling applications which are used, such as Rhino, 3ds max or FormZ. They are all powerful but rather complex applications and their use in the early design stages is not entirely optimal. They are often used to create drafts for designs, which have been sketched out on paper on beforehand. Rhino is also often applied to transform digitized physical models to a numeric NURBS-based model, but this implies the design already took place, with the assembly or sculpting of the initial model. An exception to these complex applications might follow from the development of Moment of Inspiration 121 . This is a 3D CAD Modeling application, using NURBS. It has been created by the initial Rhino developer, who specifically wanted to target designers and artists, with support of simplified modeling methods. Especially the use of a tablet or pen device is encouraged, by relying on gestures that are fairly comfortable to make with a tablet. In contrast with a regular mouse, right clicking and scrolling is almost impossible to perform with a pen, which necessitated a rethinking of the main modeling interaction. The interface is rather clean and with an appeal to designers, as shown in Figure 1.17. At the time of writing, the software is only available as a free beta version, for the Windows platform, but it was announced to be released by the end of 2007 at a price point of about $200. The application has been described as â&#x20AC;&#x153;SketchUp for MCADâ&#x20AC;?[Gra06a, NEWS #484]. Using CAD or BIM applications for preliminary design? While it might be argued that the same applications that are used for the actual design output, such as AutoCAD or ArchiCAD, could be used for conceptual design, they pose limitations. ArchiCAD received additional freedom for modeling more complex building elements, through the addition of Solid Element Operations, support for slanted walls, beams and columns and complex profiles. But at the same time, Graphisoft proposes to use additional applications for conceptual design. SketchUp models can be imported with a dedicated add-on and MaxonForm is promoted as an integrated version of Cinema4D, for freeform modeling. But the model from SketchUp itself has no building information and deforming or creating complex, 121

http://moi3d.com

1.11 Design Applications from other disciplines

Figure 1.17: Moment of Inspiration screenshot

smooth, freeform MaxonForm elements, turns them into geometric objects, loosing their building information and knowledge. When the user twists or turns a wall from ArchiCAD in MaxonForm, the wall is not a wall anymore, but a mesh object. While the visual output might seem acceptable, this new element will not be captured in regular element queries, e.g. to calculate the amount of concrete and it is not longer possible to place a door or window into the transformed wall. In fact, when a wall with openings is deformed, both wall and openings are no longer recognized as such. This is a severe limitation when the building model itself needs to be used for queries and listings. Quite similarly, Revit can import freeform geometric models from other applications and can even assign them certain attributes to associate them with the building data, but this geometry can not be created in Revit itself. The biggest limitation is thus the lack of real building data when external modeling applications are being used alongside the BIM software.

1.11

Design Applications from other disciplines

This section describes approaches from non-architectural software to define a design process and to capture design intent. While many of this applications are not meant to design buildings, they can illustrate possible methods to manage the design process and to maintain design intention.

1.11.1

Chapter 1. Overview of Design Applications

Mechanical & Parametric Design

The main workflow of parametric design is briefly described. Initially, a sketch is made in 2D. The term sketch is deliberate, since in contrast with regular CAD drafting, the first drawing is dimensionless. The sketch will then be specified through the creation of dimensions, which will alter the sketch to receive precise dimensions. Additionally, constraints are applied to the sketch. Constraints will enforce certain connections between entities. Typical constraint types include alignment and coincidence, but also specific offest sizes or angles. The sketch can be adjusted at any time, but the constraints make sure that it stays within the limits as defined by the designer. The design intent is embedded inside the sketch. Dimensions can be fixed values, but they can also become expressions where they can be the result of a calculation, possibly referencing other dimensions. This is not unlike a spreadsheet, where cells can be calculated based on the values of other cells. This sketch is translated into a 3D model using features, which can be thought of as a recipe that acts on geometry. Typical features are the volumetric operations, such as extruding, lofting/sweeping and lathing/revolving. Another example of a feature is the creation of holes. Since a hole can be created using a feature, its list of operations stays parametric. It could include operations such as creating a shape, projecting it onto a surface, trimming a part of the surface with the shape and extruding the shape. Corners can be rounded with a chamfer or fillet. All these operations stay editable at all times. One or more features are combined into a part, which is a single object that can be manufactured. It is even possible to define parameters, so one part can be transformed into a whole gamut of possible and manufacturable objects. An assembly combines several parts into a full product, including all possible movements and the required hinges. The assembly can finally be represented in a drawing or a presentation. In the assembly, the documentation drawings are not drawn manually anymore, but they are generated. Depending on the fabrication process, the final element will be constructed from the 2D drawings or directly from Computer Numerically Controlled machines (CNC). In contrast with common CAD software, where dimensions are merely a label on a geometric model or drawing, dimensions become drivers for geometry in mechanical design. The dimensions can be values or expressions, where dimensions can become dependent on the size of other elements, in a parametric way. One part or one assembly can thus store a whole range of products that can be manufactured from the digital model. The way design intent is stored is of particular value for architectural design. As an example, an offset of a line does not not have to be merely a one-time operation, but can be stored as a permanent relation, which is maintained after modifications of other elements. Even though these relations are not always documented, they are embedded in the model and are enforced on other users. This is something that has not often been done in architectural modeling.

1.11 Design Applications from other disciplines

Two modeling approaches We can distinguish between two modeling methods in parametric modeling: dynamic and history-based122 . â&#x20AC;˘ A history-based modeling application defines a chronological order in which design operations are executed. The designer builds up a logical flow of decisions, which lead to the final output. Modifications have to be made in the correct position in the modification sequence to regenerate the output. Typical examples that rely on this approach are PTC Pro/Engineer 123 , Autodesk Inventor, Dassault Syst`emes SolidWorks and CATIA124 and others. They represent the most popular commercial applications in this field. A disadvantage of this approach is the complexity of the software and the possible limitations to make design modifications when models become quite complex. The dependencies embedded in the modeling history can effectively constrain a design to such extent that changes late in the design process become rather difficult to make. Any software gets harder to use when the project size grows, but in the history-based approach, the use of parameters and constraints can turn a parametric model into a fully defined or even an over-constrained model, where changes are not possible anymore. To change the outcome, the designer has to interpret the design history and indirectly control adjustments by modifying other related parameters. â&#x20AC;˘ A dynamic-based modeling approach does not rely on the history of the geometry, but rather tries to intelligently interpret the output geometry and make direct modifications on the end result. When the user wants to change the position of a control point, he can do this directly, which is more intuitive for certain modifications. This method also has some advantages when dealing with existing geometry, especially from other applications, where the design history might not be available. Making changes happens directly instead of indirectly, which requires a thorough understanding of the effect of modifications in a history-based approach. This would also lead to a shorter learning curve and more flexibility in the design process. Nevertheless, when we look at some applications that rely on this concept, such as CoCreate Designer 125 , IronCAD 126 , think3 thinkID 127 and 122 Information from [Gra06a, NEWS #457], http://worldcadaccess.typepad.com/ blog/2006/01/think1.html and http://manufacturing.cadalyst.com/manufacturing/article/ articleDetail.jsp?id=306252 123 http://www.ptc.com 124 http://www.dassault.com 125 http://www.cocreate.com (CoCreate Designer Modeling) 126 http://www.ironcad.com 127 http://www.think3.com (thinkID DesignXpressions Series)

Chapter 1. Overview of Design Applications Kubotek KeyCreator 128 , they are not the most widely used applications.

Major companies and applications The major players in the Mechanical CAD Market are applications such as Autodesk Mechanical Desktop129 and Inventor, UGS SolidEdge and NX, PTC Pro/Engineer130 or Dassault Syst`emes SolidWorks and CATIA. A short overview of the major players on the mechanical CAD market is displayed in Table 1.2. The difference between Mid Rand and High End is left at the discretion of the vendors. Table 1.2: Major players in the Mechanical CAD Market Company Autodesk UGS Dassault PTC

Products from Mid to High Range Inventor SolidEdge vs NX SolidWorks vs CATIA Pro/E Foundation Advanced & Enterprise

Example of parametric modeling This section briefly mentions a solution from Aerohydro, a company focusing on modeling technology for ship design and for general surface modeling. On their website131 is a presentation132 of MultiSurf, displaying their approach to parametric modeling. The exampleâ&#x20AC;&#x201D;summarized from the original presentation screenshots into Figure 1.18â&#x20AC;&#x201D;shows a simple surface model from a cabin on the deck of a small vessel. Almost any modeling application can create such geometry, but the novelty is the use of embedded parametric relations. Moving certain points results in the regeneration of the rest of the geometry, producing a valid design solution. Translated to architectural modeling, this could add control points to a building model, from which different variations can be produced. When the design is created parametrically, any variation still leads to a correctly fit model, leaving no gaps and adjusting surfaces and geometry to produce the correct model. Further information Good sources for more insight into the CAD market can be found at the upFront.eZine website and newsletter [Gra06a] and at the accompanying World128

http://www.kubotek.com Desktop or MDT is now bundled as a companion program with Inventor. Inventor was a former competitor from Autodesk MDT, but was acquired by Autodesk. 130 PTC adjusted their CAD gamma in the last years. All configurations of Pro/Engineer are based on the same interface and file format, which is not true for their competitors who offer different solutions. 131 http://www.aerohydro 132 http://www.aerohydro.com/msintrodemo/slide1.htm 129 Mechanical

1.11 Design Applications from other disciplines

Figure 1.18: Three variations of the same design in MultiSurf CAD Access blog [Gra06b].

1.11.2

Using Parametric Modeling for Architecture

Noticeable applications of the use of parametric modeling concepts in an architectural context are Autodesk Revit and the use of Dassault Syst`emes CATIA V5 by the architectural office of Frank O. Gehry. Autodesk Revit With the release of Autodesk Revit, a new generation of CAAD software seems to emerge. BIM software such as Graphisoft ArchiCAD, BricsCAD Architecturals, Autodesk Architectural Desktop and Nemetschek Allplan have been on the market for up to twenty years, but Revit utilizes a different approach, related to mechanical modeling. The concept of Revit is dubbed Parametric Building Modeling, which can be described as a relational database, which not only stores the building elements, but also the relationships that exist between them. They mainly take the form of geometrical constraints. Although the user mainly draws building elements directly, these elements are defined by a mostly two-dimensional sketch, which can be edited, if required. Where the constraints in mechanical modeling are made primarily in the sketch, the positioning constraints of an assembly are comparable to the constraints that can be made between building elements inside Revit. This is especially important in this overview, since Revit, as an example of an approach that is uncommon in architectural software, borrows precisely those tools from mechanical modeling that enable the program to capture design intent. While positioning an element in alignment with another element can be done in most CAD

Chapter 1. Overview of Design Applications

software, to make this into a permanent relation, which is enforced throughout design modifications is a novel approach. We can also notice the dimension driven features which are common in mechanical software: editing a dimension modifies elements, whereas the common approach in other applications is to let dimensions follow the size of building elements. Locking dimensions is identical to defining constraints and is not possible in most other architectural CAD software. The similarity between Revit and the approach in Mechanical Modeling is shown in Table 1.3. Table 1.3: Comparison between Mechanical & Architectural Modeling Mechanical Modeling Drawing Assembly Part+Feature Sketch

Revit Modeling Sheet Views Building Element Sketch

One aspect that is totally different between architectural modeling and mechanical modeling is the influence elements can have on each other. In architectural modeling, walls, floors and roofs need to join to make correct building element connections. This is something unheard of in mechanical modeling, where each part or feature is thought of as in independent object. They can be generated from their parameters, but they are not automatically merged with other elements. That said, we can use an approach of parametrization that influences different parts, so they are automatically connected.

Digital Project This is a modified version of the mechanical modeling application CATIA V5 , developed by Dassault Syst`emes, which is mainly used in aviation. The program is known for its extensive parametric modeling features, which comes at a high price and complexity. The architectural office of Gehry started using and modifying CATIA and eventually made a spin-off, called Gehry Technologies 133 . They provide a modified version of CATIA, called Digital Project, which has been targeted for building manufacturing. The software played an important role in the realization of the Guggenheim Museum Bilbao, displayed in Figure 1.19, and the Stata Center at MIT, displayed in Figure 1.20. At the same time, it has to be noticed that the design of those buildings was not done in CAD. The Guggenheim design is based on sketches by Gehry, which were translated into a clay-model. The model was digitized and then further elaborated as a digital model in the manufacturing phase [New06, Article#842]134 . 133

http://www.gehrytechnologies.com http://aecnews.com/articles/842.aspx select/022304 day gehry.htm 134

and

http://www.caddigest.com/subjects/aec/

1.11 Design Applications from other disciplines

Figure 1.19: The Guggenheim Museum in Bilbao Similarily, the design of the Stata Center was also based on traditional handmade sketches. This scheme was digitized and from then on, the process switched back and forth between the physical model and the digital model [BTM01].

Figure 1.20: The Ray and Maria Stata Center at MIT (Cambridge MA, USA) At the construction phase, the digital model is used to derive point coordinates, which are then used to accurately position the construction elements on site.

Chapter 1. Overview of Design Applications

This is valid with this complex geometry, where traditional 2D drawings would not really serve the same purpose. In [BTM01] it is stated that the CATIA model was sliced to generate more traditional AutoCAD DWG drawings, to prepare the surveying. At the same time, the digital model was never updated to an as-built model, mainly because of the large costs involved, which is unfortunate. At the end of 2006, Skidmore, Owings and Merill (SOM), as a large architectural form, decided to buy 100 licenses of this software 135 , which is remarkable as the office is one of the largest users of Autodesk Revit. It is not said that the software would replace Revit, though.

1.11.3

Difference between MCAD and BIM

In Mechanical Design Projects, such as aerospace or automotive projects, a relatively small number of highly precise pieces is described, piece by piece. These pieces are collected in an assembly. They are all manufactured and intended for mass production. In Architectural Design Projects, a relatively large number of imprecise pieces is assembled, many of which are site fabricated. The design is described in a specific context, with additional details and is usually intended to be unique. This was also discussed in a video on BIM from Nemetschek136 , by Robert Anderson, but we do not agree completely with his conclusions. MCAD applications are said to have only a limited amount of parts, which is obviously underestimating the complexity of the assembly of an aircraft or a car. It was also stated that building products are manufactured on site, which ignores the huge amount of building parts that are prefabricated and possibly pre-assembled. And while most architectural design is indeed customized for a particular project, repetitive design occurs in many large scale building projects, or in the product catalogue for large building firms, who work with standard designs.

1.12

Generative and Procedural Design Methods

1.12.1

Introduction

In [Nei04] a qualitative overview is given on recent developments in the context of procedural, algorithmic and generative design projects. Novel integration of computer-based processes into an architectural design workflow are discussed, from both academic research and architectural practise. Instead of directly drawing or modeling a project from scratch of from sketches, the project is transformed into series of design parameters, which drive a generation process 135 136

http://aecnews.com/news/2006/12/13/2146.aspx http://www.nemetschek.net/architect/bim.php

1.12 Generative and Procedural Design Methods

to create design proposals. Design parameters become drivers to generate geometry. Generative Modeling Language [Hav05] presents the Generative Modeling Language (GML)137 as an approach to derive geometry from functions, rather then by direct modeling. The meshes, edges and vertices are created from a functional description, providing means to modify to originating logic behind the geometry. Lindenmayer System L-system or Lindenmayer system is a grammar which was developed from biologist Aristid Lindenmayer, in 1968138 . This is graphically similar to the use of fractals, due to the recursive nature of the system. While widely applied in procedural generation of weeds and plants, such as in the Greenworks Xfrog 3D application139 , it can also be applied to generation of architectural forms. A particular application of this concepts can be found in the research on procedural city modeling[PM01], where entire city layouts, starting from road grids down to the individual building is described procedurally.

1.12.2

Procedural approach in design software

Generative Components/SmartGeometry An example of an approach to capture design intent can be found in the Generative Components module, which is being developed by Robert Aish for Bentley MicroStation. â&#x20AC;&#x153;Generative Components is a model-oriented design and programming environment which combines direct interactive manipulation design methods based on feature modeling and constraints, with visual and traditional programming techniques.â&#x20AC;? from the SmartGeometry website140 This is a hybrid environment, which creates a node-based and parametric workflow, where a design can be built up as a sequence of parametric operations, which can be linked to each other. All design decisions can be turned into parameters inside the workflow and be adjusted at any time. Since the whole workflow is modeled, changes can be made at any point in the design history and carried over to the related and connected stages. The term Generative Components is used to describe smaller components, which can be freely modeled and be applied or distributed over a larger feature. This 137 138 139 140

http://www.generative-modeling.org http://en.wikipedia.org/wiki/L-system http://www.xfrog.com http://www.smartgeometry.org/tech.htm

Chapter 1. Overview of Design Applications

Figure 1.21: Assembly of generated geometry as shown on the SmartGeometry website

system is partly graphical and partly textual. Editing the relationships can happen directly in the relation network or in the hierarchical table of operations. The relationships are displayed in the symbolic view, which is displayed at the top left side of Figure 1.23). The hierarchical table is shown at the right side of this figure. The geometric end result is displayed in regular MicroStation viewports, shown at the bottom left side of this figure141 . By allowing control points some degrees of freedom, nodes inside the system can also be moved graphically. New components can be scripted or programmed and added to the system. It is precisely the open endedness that qualifies GC as a design tool, since nothing is predetermined. The designer, who needs a fair conceptual knowledge of the possibilities of the system, makes a composition where every parameter can be named and edited. This enables a complex design to be built up in smaller steps and a custom interface for a particular design project to be created, to enable exploration of design alternatives. Since the whole relationship network forces the chosen design rules on the system, the outcome of each set of parameters produces a valid design. The software is in beta-phase at the time of writing, but is being used in several architectural offices on real-world projects and feedback is also collected through academic collaborations, workshops and conferences. 141 Created

during the SmartGeometry 2005 workshop in Lisbon by Stefan Boeykens

1.12 Generative and Procedural Design Methods

Figure 1.22: Example of a geometric construction as shown in the SmartGeometry 2005 Lisbon workshop

Figure 1.23: Example of a GC session, displaying the interface elements

Chapter 1. Overview of Design Applications

Figure 1.24: Example of an elaborated parametric assembly An article describing the initial startup of the SmartGeometry group can be found at the CAD Digest website 142 [CAD06a]. A few UK-based architectural offices already implement this application into their current practice, such as Foster & Partners, Arup and KPF 143 . Genometri Genometri 144 is a company that provides a generative modeling and design solution with the GenoForm software. This is a module for SolidWorks which provides a method to store the design parameters alongside the 3D model, so different variations of the design can be automatically generated. It enables a workflow where the designers can manage variations, which can be explored and compared, to select one or more results. Houdini SideFX Houdini 145 is a high-end visual effects and animation application which has a complete procedural workflow. It is used for many special effects shots for several blockbuster movies. Models and effects are generated through a connected network of operators and generators. It requires a technical mind set, but it can produce powerful and adaptable systems. 142 143 144 145

http://www.caddigest.com/subjects/aec/select/day smartgeometry.htm http://www.bentleyuser.org/LarsWord/larsIndex.htm http://www.genometri.com http://www.sidefx.com/

1.13 Visual programming using a node-based interface

K-3D 146 is an Open Source application utilizing a comparable approach as Houdini. It has a similar modular structure and provides parametric tools for most operations, allowing the user to create a complete procedural work flow. Even the rendering engine is not fixed, but

1.13

Visual programming using a node-based interface

Introduction and Concepts There is a considerable amount of applications from different fields which utilize what can be called a â&#x20AC;&#x153;node-based interfaceâ&#x20AC;?. The approach in these applications is defining a set of model blocks, with input and output parameters. The user can make a network of these blocks, where the output of one block can be used as input for another block. This can be compared to programming in a visual way.

node1

node2

node3 node6

node4

node5

Figure 1.25: Illustration of a node network This Section mentions examples for graphics and even music creation. What is remarkable in these applications is the flexibility of their design process, in the broadest sense of design. They apply the visual metaphor of connecting parameter blocks with wires. This is not unlike the first telephone stations, where physical patch cables were used to make connections between different modules.

1.13.1

Example Applications

Several multimedia applications follow this approach. 146

http://www.k-3d.org

Chapter 1. Overview of Design Applications

Quartz Composer and Pixelshox Apple Quartz Composer allows the user to connect different media sources, such as audio, video, text but also RSS news feeds and system information, with object generators, effect filters and other procedures. This can be used to generate interactive multimedia applications, without writing any code. This technology147 is tightly connected to the OSX operation system and is not portable to non-Macintosh systems. See Figure 1.26.

Figure 1.26: The Quartz Designer The Quartz application is based on PixelShox, which is discontinued but still freely available148 . See Figure 1.27. Pixelshox includes an interesting option to include 3D objects, which can in turn be linked into the network. With some additional programming, it might be possible to create geometry generation blocks, which can then, in turn, be controlled by other parameters, such as sound, MIDI or keyboard events. It is even possible to generate random data streams, which can create automatically evolving animations. Web Authoring software Demicron Wirefusion is an authoring system149 for interactive Java applets, which can be embedded in a web site, requiring no plugin installation150 . This 147

http://developer.apple.com/documentation/MacOSX/Conceptual/OSX Technology Overview/Tools/chapter 10 section 3.html 148 http://www.pol-online.net/pixelshox technology 149 http://www.demicron.com 150 Most competing products require the user to install a plugin for their browser, which is not always possible, e.g. for security reasons or because the user uses a different system, for which no plugin is available.

1.13 Visual programming using a node-based interface

Figure 1.27: The Pixelshox predecessor of Quartz Designer

is also a system where both static and dynamic data can be connected to the user interface. For architects it is particulary interesting to know that the application can incorporate VRML models, including textures and predefined animation. This can be used to make the 3D scene interactive, e.g. for a dynamic walkthrough. The end result is a Java applet, which references compressed data, for a quick download. As an example of an architectural use of Wirefusion, we exported a model from ArchiCAD as a VRML object, as displayed in Figure 1.28, to embed it into an interactive applet. The user can look around the model but also interactively choose two of the materials for the facade or set the transparency of the glass from a simple interface, using sliders. Other applications, such as Quest3D 151 and Cycore Systems Cult3D 152 seem to take a similar approach. Models created in DCC applications are imported into an authoring environment in which a Visual Programming interface enables the designer to define interactivity. Quest3D seems to be well suited for the display of interactive architectural models, while Cult3D is more focused on product presentation, even though their VIZ Exporter 153 product provides a realtime walkthrough solution.

151 152 153

http://www.quest3d.com http://www.cult3d.com http://www.cult3d.com/products/prod vizexporter.php

Chapter 1. Overview of Design Applications

Figure 1.28: Demicron Wirefusion interface with an imported VRML model

Music Composition Software Native Instruments Reaktor 154 , Plogue Bidule 155 , Pure Data 156 and Buzzmachines 157 are all examples of audio environments, where data input, audio processing and mixing blocks can be connected together to make a full custom music system. This is illustrated in Figures 1.29 and 1.30. They can be used to build sound effects, virtual synthesizers, sequencers or other tools, without programming. In these applications audio players, sound generators, sound effects and note sequences can be linked together in a network. This can be controlled by data, audio or even external MIDI devices, such as a controller keyboard or a synthesizer. They can be used in interactive performances, combining random generated sound, pre-recorded audio loops and sequences that are performed live. Some applications can even integrate video into the mix. While architects do not require music software for architectural design, the approach in these systems, which target a much wider and less-educated audience is interesting. It enables end users, without the need to access the application source or to create text-based scripts, to embed arbitrary logic into the project file. This is effectively an interesting approach to embed design information within the resulting document. At any time, the parameters might be adjusted and the system reflects these changes. 154 155 156 157

http://www.native-instruments.com http://www.plogue.com/ http://crca.ucsd.edu/â&#x2C6;źmsp/ http://www.buzzmachines.com/

1.13 Visual programming using a node-based interface

Figure 1.29: Plogue Bidule generative music composition

Figure 1.30: Buzzmachines freeware audio environment

Chapter 1. Overview of Design Applications

3D Animation Software Autodesk Maya and AVID Softimage|XSI are both complex animation and effects applications, which have a similar node-based system for their material editor. XSI also uses it for the compositing module. Different compositing software applications follow the same approach, including Apple Shake, D2 Software Nuke and eyeon Fusion. The freeware Shaderman application provides a similar interface to edit RenderMan Shaders. See Figure 1.31. More info on the Renderman specification in Section 1.5.1 on page 23.

Figure 1.31: Shaderman with a fairly simple shader SideFX Houdini , as mentioned in the previous section, uses a similar network interface, to connect nodes. All modifications are effectively modifiers or operators. Some operate on geometry, while others on data or materials. The whole pipeline of the software is adjustable and highly scriptable. The program is popular with technical directors for special effects animations in movies.

1.13.2

Relevance to Architecture

Even though most of these applications are not meant for architectural design, it is interesting to imagine a similar concept being applied to architecture, where a set of building blocks or generators could be combined with modification blocks or operators. Connected together they store all parameters that are used to generate the end result. This network is effectively a formalization of the underlying design intent. In fact, the Generative Components module, which is discussed in Section 1.12.2, follows a similar concept. A modular system is used by connecting parameters that allow for the storage of the design process. In this approach the default

1.14 Creative Software on the border between 2D and 3D

behavior of the software automatically stores the chronology of applied modules and modifications, so the workflow is at the same time the interface to the design and a logbook of the design history.

1.14

Creative Software on the border between 2D and 3D

ZBrush and Piranesi are two very distinct applications, which can be of further interest in the general overview of design approaches in creative software. Pixologic ZBrush ZBrush 158 is a modeling and sculpting tool for artists. It comes close to the workflow of clay modeling and appeals to many artists who have been trained before the digital age. The application uses a painter approach to sculpting. The user can choose to work on a flat canvas, painting with brushed that inhibit 3D behavior, but it is also possible to work on full geometry. The flat approach borrows depth-information allowing 3D techniques such as lighting and reflection to influence the painting. The 3D approach is often used to generate additional geometric detail in less detailed 3D models. These models are typically imported from other applications, but they can be created completely inside the ZBrush application. A common use of this application is in sculpturally adding geometric detail on existing 3D models, increasing surface detail, such as wrinkles, scratches and small accessories, which would be tedious to model with traditional tools. A similar application is Mudbox, which was acquired by Autodesk in 2007 to extend their range of entertainment products159 . Informatix Piranesi Piranesi 160 is somehow related to ZBrush, since it is a 2D application using methods from 3D visualization. The application is a Photoshop-like painting tool, mostly used for architectural visualization. The novel approach Piranesi takes is that the image contains additional depth-information. This Z-Buffer161 is kept within the otherwise flat pixel-based image, so the painting tools can be influenced by orientation and position of surfaces. The user can start painting with textures such as a photographic image of a brick wall and the software automatically fixes the perspective. It also allows placement of photographic entourage, such as cars or people, with a correct perspective deformation. Its main use is non-photo-realistic, sketch-like renderings, mainly for architectural visualization. The architect can give an artistic impression of the design, 158 159 160 161

http://www.pixologic.com www.autodesk.com/mudbox http://www.informatix.com http://en.wikipedia.org/wiki/Z-buffer

Chapter 1. Overview of Design Applications

conveying the client information about the design, without the false assumption that the model is completely finished.

1.14.1

Relevance to Architecture

Both these applications are showing the possibilities of combining knowledge from 2D creative software and extending this into 3D. While the use of Piranesi is directly related architecture, for its use in creative presentations, ZBrush is mainly used in creature design. However, one could imagine the same technique being applied into freeform design. The software can be used to create additional geometric detail on top of a mesh. While this is usually a character, it could as well be a rough model of a building. It provides a modeling potential not found in regular CAD or 3D software.

1.15

An applications database

References to a large collection of design applications are collected in a database. The appendices display a table with some filtered information from the database that was set up in the context of this research. This database is also available online, for custom browsing. The database is structured to provide flexible access to the listing of applications and companies, but also means to find information about the data exchange possibilities between these applications, through the addition of supported file formats. Additional queries allow to retrieve which applications can exchange files. The structure of this database is displayed in Figure 1.32, which explains the available tables and their relations. In this database, applications are disconnected from the companies, allowing a more profound structuring of the data. The structure of this database is revised based on the methodology explained in [Pow05]. The description of normalization was especially useful to decide upon the division of the database in tables. The actual database contains additional tables, such as news articles and case studies, which are not displayed in this scheme. They serve as the underlying structure for the online access of both the applications database and associated articles at http://asro.sbuild.com . In particular, the Render Study as elaborated on these pages, is a case in point of the possibilities of exchanging the geometric part of a design with visualization applications (see Figure 1.33). A single CAD model, modeled with Graphisoft ArchiCAD, was exported in several of the supported file formats of this CAD application and imported in or converted to a large number of visualization applications. This was both a comparison study of visualization possibilities in these applications and the file exchange limitations posed by common 3D formats. It is planned to enhance this website with better cross-links to the applications database and with an additional study on 3D web applications, allowing the designer to present 3D information embedded in a web site or as a stand alone viewer application.

1.15 An applications database

2DFeatures

Companies

Fileformats

2D_ID (PK)

CompanyID (PK) CompanyName

FormatID (PK) FormatName

ApplicationID (FK) Lines Text Dimensions Hatching Trimming Chamfering ...

Country Homepage IsPerson

Extension Description Supports2D Supports3D SupportsBIM SupportsVIZ SupportsANI OpenStandard IsBinary XMLbased

CompanyID ApplicationID

3DFeatures

Applications

3D_ID (PK)

ApplicationID (PK) ApplicationName

ApplicationID (FK) Primitives CSG NURBS Sweeps Extrusions SubD.Surfaces ...

CompanyID (FK) Supports2D Supports3D SupportsBIM SupportsVIZ SupportsANI OpenSource HasTrial SupportsWindows SupportsMacOSX SupportsLinux Homepage1 Homepage2

FormatID

...

ApplicationID

ANIFeatures

FileSupport

SupportID (PK) ApplicationID

ANI_ID (PK)

ApplicationID (FK) FormatID (FK) Remarks CanImport CanExport IsNativeFormat RequiresAddon

ApplicationID

ApplicationID (FK) Keyframing NonLinearAni FK IK Physics ...

FK = Foreign Key PK = Primary Key

exactly one one or zero zero or more identifying non-identifying

Figure 1.32: (Partial) Structure of the Applications Database

Figure 1.33: Screenshot of the Render Study

Chapter 1. Overview of Design Applications

The database is also structured for other application types, such as video or audio, which might eventually turn it more into covering the whole gamut of design and multimedia software. Currently, the database contains more than 400 applications and more than 200 companies. The file format tables are still a work-in-progress, but the main browsing functionality is set up to filter the database according to category, file format, company or application type. An additional form provides more detailed application filtering.

Figure 1.34: Screenshot of the 3D-CAD Tools Query Form

1.16

Conclusion

This section ends the overview of different design applications and their relevance for architectural design. The overview has been compiled into a database, for online querying. This text only mentioned the core players, but the database is much more extended and covers a large part of the available 3D and CAD applications. It might be of special interest for architects, artists and designers who often lack a good overview of the different available solutions. Even though most architectural offices work with the same five or six applications, the architectural practice is shifting more and more to an all-digital practice, in which many different applications can have their rightful place.

1.16 Conclusion

The database also presents a wide range of cheap and free applications. This ranges from simple applications with one particular purpose, such as a file conversion program, up to full production-ready content creation applications. While the availability of free CAD applications is limited, there is a large set of free DCC applications, which can be added to the regular workflow, such as in the rendering process or in the modeling and design exploration stage. The database tries to be as complete as possible, mentioning the main capabilities in the form of a comparison table for some common features, but also the available platforms and a special attention to the file formats that are supported, allowing the user to make an informed choice to add new applications into their current workflow. The database can be queried online at http://asro.sbuild.com .

Chapter 2

Trends and evolutions in design applications Introduction When having a closer look at the database of design applications, current trends and general evolutions in the design application field are analyzed in this Chapter. First, there is a increasing volume of applications which are freely available, even though many of these applications take an enormous programming effort to produce. There is also a growing tendency to provide a gamut of applications, to present customers with a growth path, usually within products from the same company. More and more companies currently suggest the users to enter into a subscription-based licensing scheme. These companies additionally often engage in mergers and acquisitions, which reshapes the design software market considerably. Some conclusions are also formulated on the growing integration of design applications in architectural education and the seemingly small attention for referencing these applications in academic research on CAAD. Finally, the increasingly hybrid use of CAD in architectural design practice is discussed. The evolution of design applications and especially architectural design applications seems to be at a point where most commercial companies focus on creating large and complex applications, to be widely applicable. Most of them seem to be mainly interested in the phase where the architect needs to prepare construction documentation, hence the importance of solid drafting and annotation tools. In many cases, modeling and visualization tools are being integrated directly into the CAD software. This seems to promise an out-of-the-box solution for architectural design, yet they somehow seem to be not really interested in the early design stages. Even though a program such as SketchUp is widely accepted as a good alternative to sketching on paper, especially for its 3D capabilities, it is still a geometric modeler. 3D models can be generated and materials applied, but no information about the building is available. Smart use of library elements and scripting can generate a wide variety of objects, but they are not parametric. As soon as they are generated, they become an unstructured mesh. 75

Chapter 2. Trends and evolutions in design applications

This is also soon in many generic CAD applications, where one-time object generation tools are created for objects such as roofs or stairs, but they lack any kind of editability afterwards. And while this might seem obvious in a generic CAD or modeling application, this is also witnessed with some dedicated BIM applications. A roof generator will be able to create a complex roof, but afterwards, there are no options to alter the creation parameters, rather than by starting again. The first Chapter deliberately focused on mechanical design and parametric modeling, because of the implied design information that they capture. When a generic CAD application creates an extrusion of a profile, at best it is able to alter the extrusion height afterwards. Some of them are even unable to modify the creation parameter. BIM applications usually provide parametric objects. Snaps and alignments in generic CAD software and in most BIM software are only used upon creating elements. When objects are modified, they are modified in a vacuum. Most BIM software totally ignores any associativity or relationship between the elements. The notable exceptionsâ&#x20AC;&#x201D;Autodesk Revit and GehryTechnologies Digital Projectâ&#x20AC;&#x201D;are derived from MCAD concepts or technology.

2.1

Availability of free applications

In a field largely dominated by expensive commercial applications, we have especially tried not to neglect free applications. They are often smaller, not only in terms of feature lists but also in terms of budget. Especially with the growing acceptance of the Open Source concept, there is an increasing number of freely available and adaptable applications. Open Source software is often released under the GNU General Public License (GPL)1 . This license has very specific requirements for developers. The software or libraries are made available complete, with their source code and they allow a fairly liberate use, but at the same time, restrictions apply, to prevent the commercialization of products including this code. The licensing wording is rather specific, so it is best to read through the Frequently Asked Questions (FAQ)2 . Other licensing schemes exist, such as LGPL and MIT, which are more open for commercial use.

Free CAD We first mention a few free CAD applications, allowing commercial use, but not providing access to their source code. DESI-III is a Belgian 2D CAD system3 for MS DOS, but it runs fine in Windows. The Acronym DESI stands for Drafting made Easy Software Implementation. 1 2 3

http://www.gnu.org/copyleft/gpl.html http://www.gnu.org/licenses/gpl-faq.html http://users.pandora.be/desi-iii/index.html

2.1 Availability of free applications

Cadvance 6.5 is an older version4 from 1995 of the commercial Windows-only CAD application, which has been adapted to run on Windows XP. CadStd Lite is an elementary CAD program5 for Windows. There is a professional version, which only costs $37.50. MINOS is a solid modeling application6 for Windows. This displays solutions that are either completely free or that are limited or older versions from commercial applications. Other examples include AllyCAD Freeware, Draft IT, and Varkon. These and more examples can be retrieved from the database.

Open Source CAD On the level of Open Source solutions it might seem strange that there are only a few CAD applications. Despite the enormous amount of applications on Sourceforge 7 there are almost no CAD applications available. A few notable exceptions are mentioned here. QCad is a 2D CAD application, running on all major platforms and which has an open source community edition which is released with a GPL license. The program also has a professional edition which is proprietary and includes support for scripting and is available as Windows binaries and the latest sources8 . BRL-CAD is a solid modeling system, developed for over 20 years by the U.S. military9 . It includes interactive modeling, visualization and analysis tools. It is available for most platforms, although the Windows platform has only been included in 2006. FreeCAD is a freeware 3D CAD application with motion simulation10 . It is free through advertising inside the program and it utilizes the open source StCAD framework for the Object Oriented Programming language Smalltalk. OpenCASCADE is a CAD framework, rather than a full CAD application, but it can be used to build CAD applications. This is available with an open source license, opening the possibility of developing an open source CAD application. It supports the Windows and Linux operating systems11 . 4 5 6 7 8 9 10 11

http://www.cadvance.com/65form.htm http://www.cadstd.com/lite.php http://www.le-boite.com/minos.htm http://www.sourceforge.org http://www.ribbonsoft.com/qcad.html http://brlcad.org http://www.askoh.com http://www.opencascade.org

Chapter 2. Trends and evolutions in design applications

SALOME is a suite of engineering applications, built on Open Source frameworks. It utilizes OpenCASCADE as modeling kernel and then includes additional pre and post-processing modules for numerical simulation12 . This is mainly focused on finite-element analysis applications and is completely built on Open Source components. It is only targeting the Linux OS, which might make it harder to get accepted in existing practices. There are a few others, which can be found in the database, such as Irit, SagCAD, SolidGraph and Varkon. On the other hand, considering the complexity, development effort and licensing issues involved in most commercial CAD applications, it seems remarkable that there even exist Open Source CAD applications at all. The scale of a full CAD application is usually beyond reach for any individual developer, although many open source systems successfully emerge with a community effort. Even mathematical and technical complexity as such is not a reason for the limited existence, since many academic research results have been delivered in an open source spirit. Apart from the commercial interest of most CAD vendors, most of the typical CAD applications rely on the licensing of libraries from other companies. These include modeling kernels, visualization libraries and programming or scripting libraries. They are proprietary and demand a fee from the CAD vendor, either as a percentage of the license fee or for a fixed fee. This usually prevents the release of a free version and prohibits the release of the source code. Sources of commercial libraries is something most CAD vendors not even possess, as they usually license compiled libraries, rather than the use of the source code. The example of OpenCASCADE is somehow misleading, since it was initially a proprietary kernel, which has only been released in 2000 as Open Source, with a specific licensing model, more then a decade after it was originally developed by French company Matra Datavision, under the name of EUCLID CAD system 13 .

Open Source DCC When looking for Digital Content Creation (DCC) or 3D Animation software, the choice is larger. One of the best examples is Blender 14 . This started as an internal modeling, animation and compositing application for Dutch animation studio NeoGeo in 1995 and evolved into a commercial application, but with a free version also available. After the company Not a Number (NaN), which handled the Blender development, was shut down, a community effort collected the funds to pay all debts and the Blender Foundation was born in 2002. The Blender sources became an Open Source project. The original founder and developer recently finished the first Open Source movie project, called â&#x20AC;&#x153;Elephants Dreamâ&#x20AC;? 15 , 12 13 14 15

http://www.salome-platform.org http://www.opencascade.org/about/profile/history/ http://www.blender.org/cms/History.53.0.html http://orange.blender.org

2.1 Availability of free applications

which was modeled and animated exclusively with Open Source tools and which is not only freely available, but all arts assets and production sources have been made available as well. Another example is OpenFX, which also started as a commercial product, by one of the original developers of the commercial Lightwave3D software. It was released as Open Source in 1999 and is currently still further developed. Other notable examples include Art of Illusion, K-3D, K3Studio and MindsEye.

Free versions of Commercial Applications Apart from the real free applications, there are some free versions of commercial applications. The last few years, several commercial companies have drastically diminished their pricing and many of them have made adapted versions of their professional tools available as free or cheap learning editions. Autodesk provides a non-commercial version of Maya as a Personal Learning Edition (PLE). These applications are often partly crippled to disable commercial abuse, but they can be distinguished from more traditional demonstration or trial versions which usually disable saving capabilities or are disabled after a certain amount of time, which is typically one month. These learning editions are usually targeted at students, who might need to learn such applications for possible employment and to build up some much desired industry-quality experience. Other examples are Houdini Apprentice Edition and Vue PLE. Many are normally quite expensive commercial applications, so their availability for learning purposes might help them to get trained before applying for a job. An additional trend, especially in applications targeted at wider audiences and consumer level users, is the bundling of special editions of commercial applications with magazines, such as 3D World Magazine 16 and Digit 17 . Companies provide Limited Editions of their regular offerings, when the user buys one of these magazines and registers the application with the company. These cut-down versions have to be distinguished from learning and demonstration editions, since they are commonly save-enabled and sometimes even allow commercial use, which makes them usable inside a professional office environment. These special editions are usually either a limited edition or a more complete but older release. A typical example is Cinema4D CE from Maxon, which is functionally identical to the full commercial release 6 of the 3D animation application, originally available for about $2000. The software is at release 10 at the time of writing (2007). The only limitation of the CE edition is the render size, which is limited to 600Ă&#x2014;400 pixels, but this can be solved with an upgrade to the â&#x20AC;&#x153;plus â&#x20AC;? version, which was available at a $100 price level. This is still considerably less than the full commercial price. 16 17

http://www.3dworldmag.com http://www.digitmag.co.uk

Chapter 2. Trends and evolutions in design applications

Other examples that have been made freely available with such magazines are TurboCAD, IntelliCAD, WorldBuilder, Vue dâ&#x20AC;&#x2122;Esprit, Amapi, Artlantis, Carrara3D, Realsoft3D, Shade Designer and Poser. These evolutions are mainly noticed in the field of 3D animation software and are less visible with CAD software, although programs such as Autodesk AutoCAD and Graphisoft ArchiCAD have been made available as trial versions. Despite the availability of trial software, it is quite common that a user who wants to learn about an application directly contacts a local distributor for a personal demonstration. It is technically possible to experiment with a trial version, but the complexity of these applications makes it very difficult to thoroughly evaluate the applicability of this software in the workflow of the user. That said, the last two years have shown an increased interest by commercial CAD vendors to provide free or cheap non-commercial editions of their commercial offerings. References to all these applications are available in the database.

Additional Information A review which discusses some of the low-cost and free offerings in the context of CAD can be read in [cad06b, Getting the Last Drop18 ]. Apart from our own database effort, there are some additional websites that provide information about free CAD or 3D software, such as cadazz 19 or intrastar 20 . Many software download sites also allow to browse for free software, but CAD is usually located underneath graphics, which combines it with many other unrelated applications.

Conclusion While the availability of free applications gives beginning architects or students many opportunities for learning and even for initiating their professional career, there is a large gap with all these offerings. There is a nice choice for drafting, 3D modeling and animation, but there is no free BIM solution available. The only free program that we could find that can be categorized as being BIM-capable is Real Architect for LT, which is a drafting add-on for the commercial Autodesk AutoCAD LT, which can hardly be called free. There are no Open Source BIM solutions, to our knowledge, apart from some rather limited Academic efforts, such as the B-processor [ALK+ 07]. Within an educational context, there are more opportunities, since a few commercial BIM applications have free student versions, such as Graphisoft ArchiCAD and Autodesk Revit. That implies that custom development of concepts for BIM will either require access to a closed source commercial application, which might be free, or require 18 19 20

http://management.cadalyst.com/cadman/article/articleDetail.jsp?id=397488 http://www.cadazz.com/free-cad-software.htm http://freeware.intrastar.net/cadsoftware.htm

2.2 Different application versions, from free till expensive

the development of a custom BIM application from scratch. Both approaches have advantages and disadvantages. When choosing for the development of an add-on for an existing BIM module, the developer gains the full capabilities of the underlying platform, including all modeling and drafting features and data exchange possibilities. However, to be able to manipulate the foundations of the software is often impossible. The access to these applications is commonly possible with scripting or through the Application Programming Interface (API). Scripts do not have to be compiled, but give only limited access. Compiled modules, usually written in C/C++ or more recently a .NET language, give better access, but still limited. Should a developer which to fundamentally alter the behavior of such an application, an alternative solution is by developing a prototype as a stand alone application. To elaborate concepts, this gives the most freedom, but the developer needs to write a large part of the CAD system functionality underneath, to create a usable application. In this research, this last path has been chosen. The aspirations are not to develop a complete BIM application, but rather to present possible mechanisms and solutions to improve the early design stages. Wherever possible, existing libraries or frameworks will be applied. More technical details will be discussed in later Chapters, when the implementation is elaborated.

2.2

Different application versions, from free till expensive

Some companies provide several versions based on the same platform, with increasing features and pricing. There is a tendency, especially in Mechanical Modeling, to target a whole field of potential users, through the availability of mid and high level applications. In some cases, this is combined with a free non-commercial or limited edition too.

IntelliCAD A good example is IntelliCAD, which is a generic CAD application that targets the users of Autodesk AutoCAD by providing document compatibility. IntelliCAD uses the DWG-format as internal format, but is available at a much lower price level than its main competitor. It is especially remarkable that some of the products based on the IntelliCAD platform are even available for free. The Italian firm ProgeSOFT released ProgeCAD LT as a free application, which uses the IntelliCAD platform. This provides a possible growth path to the commercial full version of ProgeCAD. The main limitations in the free version are the omission of some licensed components, which are not allowed to be freely distributed. These are modules for programming (Microsoftâ&#x20AC;&#x2122;s Visual Basic for Applications), solid modeling (Spatialâ&#x20AC;&#x2122;s ACIS kernel) and rendering (LightWorks

Chapter 2. Trends and evolutions in design applications

rendering engine). These modules are often used by other applications as well. There are several IntelliCAD based solutions, such as BricsCAD, ZwCAD and Cadopia IntelliCAD. More information about the IntelliCAD consortium can be found in the next section.

Alibre Design Alibre Design, by Alibre is an MCAD application. In 2005, the company released Alibre Xpress 21 , which is available as a completely free application, based on the commercial products of the same company. The software has update possibilities to these commercial versions which contain more features, obviously. The initial version required a permanent internet connection and displayed banners in the application, but these limitations were removed after an intermediate update.

PowerSHAPE PowerSHAPE-e 22 from UK-based company Delcam is also a free version of the commercial versions of PowerSHAPE. This application has the full functionality, including saving, but the export possibilities are only available through a voucher system. The user can create any model, but to be able to exchange this with other partners, a voucher has to be bought at a price of about £ 200. This has to be paid with every export, which might become quite expensive in the long run.

Other examples • UGS provides a free 2D drafting version of SolidEdge 23 which includes some of the specific functionality of the 3D sibling. • SolidWorks has several free products. People who sign up for the 3D Skills Program24 can receive a free personal edition of SolidWorks. This expires after 90 days and is not compatible with the regular SolidWorks software, nor does it allow commercial use. The DWGgateway 25 provides DWG compatibility tools for AutoCAD, so users open and convert files for different versions, which is something that is limited with the regular AutoCAD software. Genius Mechanics 26 is a mechanical design plugin for AutoCAD, AutoCAD LT or Inventor, all from Autodesk. Both products might convince users to not upgrade their AutoCAD software and possibly investigate the other software solutions by SolidWorks. The company also provides eDrawings 27 which is a free CAD viewing and publishing application. 21 22 23 24 25 26 27

http://www.alibre.com/xpress http://www.powershape-e.com http://www.solidedge.com/free2d http://www.solidworks.com/pages/news/3DSkills.html http://www.dwggateway.com http://www.geniusmechanics.com http://www.solidworks.com/edrawings

2.2 Different application versions, from free till expensive

• think3, the company who develops DesignXpressions, has a free 2D application, called free2Design 28 . While targeted to China and the Asian market, the software is available world wide. They claim that the offer is not only a free tool, but is also a community initiative, including forums, training, API development, surveys and industry information. • CoCreate provides a personal edition of OneSpace Modeling 29 without time limitations. It has a limited amount of parts in a design and the file format is incompatible with the commercial versions. • CAD Schroer 30 provides a free personal edition of Medusa, a mechanical design application. While Autodesk does provide AutoCAD LT as a cheaper 2D alternative to the regular AutoCAD, it offers no free version, unlike many competitors. It is remarkable that despite its several price increases and inherent limitations, LT still represents a large part of software sales for Autodesk. LT sells much more licenses than its bigger sister AutoCAD. Giving away AutoCAD LT would probably impact the whole Autodesk business model and is not likely to happen.

Conclusion The current increase of freely available versions of commercial CAD applications is remarkable. While they are not able to replace the full versions, they might provide an easier entrance into the gamut of software applications from a specific vendor. It is important to notice that free base versions are often provided to attract clients of commercial applications to the product range of a competing company. It is indeed a very large step to switch between design applications and having a free version might help people take the leap. The Novedge blog suggest some reasoning behind this trend31 . There is a trend of diminishing prices of commercial software, not only with CAD software. Trial applications last longer and are more capable, e.g. exporting is temporarily allowed or in a special format. A second trend is offering 2D solutions for free, as it is hard to compete with existing applications, such as AutoCAD anyway. And a third trend is to interest people in the more profitable 3D solutions of the company, by removing the investment required to switch to one of their 2D solutions. In the comments on this article, there is the interesting comparison with web browsers, which are currently freely available, even though only a few years ago, large companies invested heavily in the browser-war. In addition to the database, our own CAD-3D blog 32 has several links to free offerings of CAD, 3D and other applications or resources. 28 29 30 31 32

http://www.free2design.org http://www.cocreate.com/modeling pe landing.cfm http://www.cad-schroer.com http://blog.novedge.com/2007/02/free cad for ev.html http://cad-3d.sbuild.com

Chapter 2. Trends and evolutions in design applications

The availability of a free or cheap alternative to a commercial product is something to consider in the long run, especially since the market of CAD and 3D applications is quite saturated. Newer products do not often emerge, unless they offer something of novelty, such as SketchUp or Revit. And if they do, chances are that they will be bought by one of their large competitors, as one of the next Sections will discuss. While this is not a concern in our own research, at the current status of the prototype, this will be in the long run. Software developed through academic research projects is usually released either as expensive commercial software or as a free and Open Source download, often without support. This is a choice that has to be evaluated, should our own development reach a point were external release would be considered.

2.3

License subscriptions versus resistance to update

Recent years have seen a continuous pressure from software vendors to subscribe to a software application, rather than buying licenses and upgrades, when required. But this evolution is faced with considerable resistance by users to upgrade to newer software releases. A subscription is a licensing scheme where you have a fixed fee, payable in advance, which ensures the user to receive all new updates and releases. This is often accompanied with some additional promotions, such as access to additional subscriber-only content and extra goodies at user events33 . In general, this fee is somewhere between 10% and 30% of the total license price. The advantage lies clearly with the CAD vendor, who receives a steady income to pay the ongoing development of a new release, rather than having to wait for the release date to retrieve the update licensing payments. This is a form of advance financing. Many users, however, have a tendency to skip updates on a regular basis. In fact, with the classic update cycle of CAD applications, people usually skipped one or even two versions before updating to the latest release [cad06b, Article 353073]34 . Even with offices that have a subscription contract, when a new release is received, it might be stored on the shelves for quite some time. In larger offices, the IT-management usually prepares an office-wide upgrade to a newer release, which requires considerable effort in preparation and testing. It is only when an upgrade is adequately prepared that it can be installed and be made available for all users. At the same time, they might require additional training. As a result, even in the subscription scenario, many offices do not install every released version. In smaller offices, the step to a newer version might be easier to perform, e.g. when projects are not managed by different 33 At the Autodesk User Conferences, subscribers usually receive a different colored registration badge, making their status very visible to other attendants. There are also additional promotional items on offer, such as books or CDâ&#x20AC;&#x2122;s. 34 http://management.cadalyst.com/cadman/article/articleDetail.jsp?id=353073

2.3 License subscriptions versus resistance to update

people. But in all cases, there are risks involved with upgrading, since files might become unreadable in the previous releases of the software. Once a file is taken forward, the user often can not return to the previous release, in case of problems. It is often advised to finish at least the current project stage in the same release as it was started in. This is important when architectural project might take several months or years to develop, certainly when there are chances that the data has to be revisited in the future, where there is a large uncertainty over available software, formats and operating systems. It is advised to at least create archive copies in non-CAD formats, such as PDF and to keep at least a full set of plotted documents in a physical archive. It is also advisable to keep copies of the older software and operating systems available, e.g. on an older machine which has been replaced or even in an emulated system, such as Microsoft Virtual PC or VMWare Virtual Workstation. Samples of other customer remarks can be found at [cad06b, September 2006, Dialog Box]35 . In summary, offices will subscribe, but yearly update cycles are not easy to implement in offices that have to stay productive. An update is much more then a new software installation. It requires thorough updates for IT management, staff training and re-training, revising office templates and software workflow and sometimes unlearning current working methods. The result is that several offices choose not to install the software they have bought and rest productive in the older version. Others will try to tweak the latest release to re-enable the old methods, if that is even possible. To force users in a subscription scenario, some CAD vendors even introduce product retirement. When the user has an older version, at some point in time there is no upgrade path to the new release anymore. Autodesk in particular uses this system to retire applications after about three years36 . In addition, other methods exist to tie users to keep upgrading to newer software releases. • Newer software releases often change the file format. This is usually motivated by new application functionality, but not always. Autodesk AutoCAD release 2004, 2005 and 2006 have used the same DWG format, while release 2007 changed this format again. In some cases, however, there is no support for older releases. Not every software can export a scene in the format of a prior version. A good example is Autodesk 3ds max , which has never been able to save a *.max document to the format of an older release. One of the smarter users, Borislav “Bobo”Petrov37 , partly solved this with the BFF script38 , recreating the scene in the older version using compatible scripting commands. • Adding new features makes newer applications more appealing to users. Stopping the development of the older version, however, with no promises 35

http://management.cadalyst.com/cadman/article/articleDetail.jsp?id=370304 users can usually still upgrade from retired versions at a discount, when compared to buying a completely new license with the Autodesk Legacy Program, as explained on http://www.adskhost.net/10728/index.php . 37 http://www.scriptspot.com/bobo 38 http://www.scriptspot.com/bobo/darkmoon/bff 36 . . . although

Chapter 2. Trends and evolutions in design applications to fix program bugs, might even be a more convincing method to motivate an upgrade. â&#x20AC;˘ Apart from licensing fees, many applications are delivered with a maintenance contract, offering support from the company. This is sometimes required in a productive environment, where software problems have to be solved as soon as possible. This usually implies that the client uses the latest release.

2.4

Acquisitions and mergers of Companies

As with most markets, the players tend to conglomerate into larger entities. Many CAD companies have been acquired by competitors. This sometimes leads to a new momentum, but often these products disappear. Actual growth seems to be more and more related to acquisitions, rather than on enlarging the customer base through existing applications39 . Some of these acquisitions have far ranging influence on the CAD market.

IntelliCAD versus AutoCAD In early 1990s40 , a US software company named IntelliCAD developed the AutoCAD Data Extension (ADE) which was sold to Autodesk. The company was forced to be spun off, to avoid monopoly claims. Afterwards it was bought by Visio, who produced the Visio diagramming and charting software. Visio sold a perpetual source code license to the IntelliCAD Technology Consortium and also sold the DWG read/write API to the Open DWG Alliance, which later became the Open Design Alliance. Visio was sold to Microsoft, who still commercializes the Visio software today. This is summarized from [Gra04] as Figure 2.1. The free versions of the IntelliCAD software all lack the licensed modules from external companies, such as the solid modeling kernel, rendering and integrated programming. MarComp DWG API

ADE IntelliCAD

Softdesk

Autodesk

spinoff

BT IntelliCAD

DWG API Visio

source code

ODA

member of ITC

Microsoft

Figure 2.1: The complex history of IntelliCAD 39

http://www.baselinemag.com/article2/0,1540,2145265,00.asp collected from the IntelliCAD World Meeting 2004 presentations [Gra04].

40 Info

2.4 Acquisitions and mergers of Companies

The IntelliCAD Technology Consortium, which currently manages the source code of IntelliCAD has several commercial members, which can be retrieved from the IntelliCAD website41 . They provide a wide variety of CAD applications, based on the IntelliCAD system. The IntelliCAD Technology Consortium also provides ArchT, which is a dedicated architectural software, for use with IntelliCAD or AutoCAD.

Microsoft and Softimage and AVID Softimage|3D was originally an animation system running on SGI IRIX workstations. It was widely used by companies such as ILM for animation and effects in popular blockbuster movies, including Star Wars and The Abyss. During the 90s, Microsoft bought Softimage and ported it to the then released Windows NT platform. This was assumably a proof-of-concept to illustrate the viability of the NT platform and regular PC workstations for the entertainment and graphics industries, at a time where they were dominated by UNIX and SGI workstations. Soon after, Microsoft lost interest and sold Softimage to AVID, which was active in multimedia, especially in video and broadcasting, for which they had developed custom solutions of hardware and software. Since then, AVID created a new generation of Softimage, called XSI and currently has different flavors of the application. They provide a free game-modding version and three different commercial version, targeting the gamut from individual artists till larger visual effects facilities.

Nemetschek The German firm Nemetschek has a history of acquisitions, alongside there internally-developed Allplan platform. Allplan is a Building Information Modeling application, with different modules targeted at technical studies, such as HVAC and structural calculations. Their flagship product Allplan is widely used in Germany but never really caught on elsewhere. It has about 400.000 users. In 2000, Nemetschek became a major shareholder in Diehl Graphsoft, the former developer of MiniCAD, which has been renamed to VectorWorks. In the same year, the German visualization firm Maxon has been acquired, which develops Cinema4D, a widely used rendering, modeling and animation application. In 2006, Nemetschek acquired the Belgian SCIA, developer of scientific applications since 1974. At the end of 2006 Graphisoft, the Hungarian developer of ArchiCAD, is acquired too. With these acquisitions, Nemetschek has become the world wide number three in the AEC software business, following behind Autodesk and Bentley. 41

http://www.intellicad.org/members/memberlist.asp

Chapter 2. Trends and evolutions in design applications

It is assumed that the different product brands continue to be developed parallel to the other offerings. As can be read from [Khe06, News#2942 ], Allplan will continue to be focused on Europe, while VectorWorks and ArchiCAD have partly different markets. More info on the merger can be found in [New06, Article 2172]43 . The different companies keep an online history at their respective homepages: Nemetschek44 , SCIA45 , Maxon46 .

Autodesk buying Inventor, Revit and Alias Autodesk has a long history of acquisitions, from which three are discussed in more detail here. Firstly, on the MCAD front, Autodesk started with Mechanical Desktop (MDT), which is based on AutoCAD. Through the acquisition of former competing product, Inventor, Autodesk now offers two similar applications, but the focus is clearly on Inventor, which currently even includes MDT. There is a similar story to tell about Revit. Its history dates back from Sonata via Reflex to PTC. Two former PTC employees developed Revit, as an independent company Revit Technology Corporation. This company was finally acquired by Autodesk in 2002. At the same time, Autodesk had already developed Architectural Desktop (ADT), for which Revit was a direct competitor. Autodesk still distributes the two applications and is slowly targeting them to different markets. ADT is sold as AutoCAD for architects, while Revit is the BIM solution, where it becomes a complete platform, including Building, Structure and Systems. It is clear that most attention, at least in marketing, goes to Revit. The Canadian company Alias, which is best known for the Studio Tools car design software and the Maya 3D animation software, has also been acquired by Autodesk. The Alias history shows that this was not the first change of owners. The company Alias Research started in 1983. Wavefront Technologies was formed in 1984. They both merged as Alias|Wavefront in 1995, becoming a part of SGI. Alias became independent again in 2003, but was acquired a year later by Accel-KKR and Ontario Teachers’ Pension Plan. Then Alias aquired Kaydara—famous for character animation software MotionBuilder —in the same year and finally was acquired by Autodesk in 200647 48 . Figure 2.2 gives an overview of some of the acquisitions by Autodesk. At the time of writing, additional acquisitions had occurred, including NavisWorks, Skymatter Limited (known for Mudbox ) and Opticore. 42 43 44 45 46 47 48

http://www.aecbytes.com/newsletter/2007/issue 29.html http://aecnews.com/articles/2172.aspx http://www.nemetschek.com/en/nemcom.nsf/group.html http://www.scia-online.com/int/about scia.html http://www.maxon.net/pages/contact/history e.html http://www.autodesk.com/hp alias http://www.alias.com/eng/about/history/index.shtml

2.4 Acquisitions and mergers of Companies

Wavefront Technologies Alias|Wavefront Alias Research

Alias Kaydara Revit Inc. Autodesk Inc. Inventor

Buzzsaw

Figure 2.2: Fragment from acquisition history of Autodesk

Google and SketchUp In march 2006, Google surprised the CAD world with the announcement of the acquisition of @Last, the relatively small firm that developed SketchUp, which became extremely popular over the course of only six years. For non-commercial use, Google provides a Free version since may 2006, but this does not exchange files with CAD software and the licensing restriction makes this unusable for architectural offices. Only a few months before the Google acquisition, SketchUp provided means to create content for the popular Google Earth browser, which in itself was also an independent technology, called Keyhole, before Google took over.

Adobe and Macromedia Adobe Inc. who are most known for their DTP software tools Photoshop, Illustrator and Acrobat, acquired the webdesign oriented Macromedia in 2005, known for their Dreamweaver and Flash 49 products. This large merger surprised many design professionals. This is especially important since the combined products of both former competitors partly overlap and make up probably the majority of software products used for DTP and webdesign. At the time of writing it remains unclear if programs such as Adobe GoLive and Macromedia Fireworks will continue to be developed, when their direct competitors Macromedia Dreamweaver and Adobe Photoshop are widely used. At several times, Adobe has been said to enter the CAD market, but the only two products that might form a partial proof of this statement are Adobe Atmosphere and Adobe Acrobat 3D. The former was a 3D Webdesign application, which has since been discontinued, while the latter has only recently been released. It adds the possibility to store 3D models inside PDF documents, with technology Adobe acquired itself from TTF company. The last option seems to have some 49 Flash

was originally not a Macromedia product, but was called FutureSplash, before it was acquired in 1996.

Chapter 2. Trends and evolutions in design applications

potential, as it can form a companion solution rather than a competitor to existing CAD or 3D software.

Conclusions The trend of conglomeration is clearly witnessed in the AEC software industry as well. Many times people believe that an acquisition will be followed by merging of applications. In practice, however, this never occurs. Many of these applications have been around for a decade or more and are already complex enough to maintain as separate products. This leads to the conclusion that most companies are not capable of creating a single solution or platform, from design to manufacturing and building maintenance. At best, a company has a complete portfolio of different applications, so a potential client can be offered a full solution, albeit using disparate products. In some cases, companies even maintain former competing products and either borrow technology from the other product or target them at different users. When developing software for designers or architects, no one seems to be able to develop a single product that can be used throughout the whole design-buildmanage process. The different tasks are just too different and integrating this whole process into a single application would probably increase the complexity and reduce performance, usability and stability. As such, it makes sense to choose a more targeted approach, where purposebuilt solutions are created that collaborate rather then integrate everything into a single application. This, however, implies that data exchange will be possible and that is still problematic. Where the exchange of common geometry and drafting data appears to be possible and supported, the exchange of design data is problematic. This is discussed in Section 3 on page 97. Companies such as Autodesk do not merge applications that were acquired, but rather improve the interoperability between them. CAD models can be read in visualization applications and even referenced, so updates to the CAD geometry can be uploaded to the visualization scene as well, without the necessity to reassign materials or recreate additional geometry or animation settings. Eventually, it seems that to the user it would make most sense to utilize a common building database, with which all applications interface. Each application can retain its own specialized interface, but can effectively collaborate on the same model. The IFC format, which is discussed further on, is getting integrated into more and more applications, promising project collaboration between different applications. In practice, however, this format is used as a common intermediate format, whereas each application maintains its own, usually proprietary, format. The acquisitions of companies and their respective products seem to not have changed this approach fundamentally. When a design application targets architects, it has to take this context into account. There will probably never be applications that offer a complete solution from design till construction and lifecycle management. Even when companies

2.5 Software use in Architectural Education

bundle applications from their own portfolio, from which some might have been acquired rather than developed in-house, they always face the problem of data exchange. To be able to embed a single application into a productive work flow, it has to define its place and the possible exchange possibilities. This could be managed by enabling numerous file importers and exporters or by adhering to standard formats. However, all the current and sometimes historic limitations of these formats still apply. The next Chapter will discuss this problems into more detail.

2.5

Software use in Architectural Education

Since the knowledge and use of CAD and design software by architects is influenced by their education, it is interesting to briefly refer to results of a survey, collected from eCAADe conferences, as published in [Pen03]. The survey questioned the use of software and new media in European architecture schools. The objective of the survey was to see wether there was a discrepancy between new media use as displayed in conferences and the use of these media in the educational curriculum. With regard to our research, some of the results are interesting to mention here. The most widely used CAD application was, unsurprisingly, Autodesk AutoCAD, followed by Graphisoft ArchiCAD and Bentley MicroStation. Comparison between Europe and the rest of the world, based on the participants of these eCAADe conferences, showed only a difference in the bigger popularity of ArchiCAD inside Europe, which might be related to the fact that Graphisoft is a Hungarian company. The most popular modeling applications were Autodesk 3ds max, followed by auto路des路sys form路Z and McNeel Rhino 50 . Most schools seem to choose one of the better known commercial offerings, similar as the market for which they educate students. The choice of these applications, however seems more related to commodity, rather than on research insight. Since many commercial applications are available for a highly reduces price, there is no financial reason to not choose one of the better known applications. And forming students with industry-standard applications will certainly be welcomed by the industry in which they will search for jobs. However, as evidenced by publications in conferences such as eCAADe, some more experimental approaches seem to have found their way into the educational curriculum. Generative Components seems to be acquiring a fair amount of support with schools and animation and visualization applications have always been popular. 50 Strangely

enough, applications such as Autodesk Lightscape and Radiance were also mentioned under modeling software, for which they obviously are not suited.

Chapter 2. Trends and evolutions in design applications

2.6

References to common CAD and 3D applications in academic research

As a simple inventory51 , the number of references to some common CAD and design applications was counted in a few recent conference proceedings to see the relative importance of these applications with regard to academic research. The conferences shown were mostly focused on using digital technologies for architectural design, apart from DCC. The results are shown in Table 2.1.

Table 2.1: Number of references to common CAD and 3D applications

Application 3ds max 3D Studio ArchiCAD AutoCAD CATIA FormZ Maya MicroStation Nemetschek Revit Rhino SketchUp VectorWorks

Conference Proceedings CAADFutures ACADIA eCAADe 2001 2002 2003 0 0 0 0 14 10 35 6 17 13 8 44 1 17 1 0 4 10 15 2 7 12 9 12 0 0 0 1 0 2 0 0 6 0 2 0 0 0 0

DCC 2004 0 0 0 1 3 0 1 0 0 0 0 0 0

eCAADe 2005 16 8 15 35 9 5 10 1 6 29 6 9 4

Translating this table into a chart, displaying only the average reference counts results in Figure 2.3. A similar search for some of these terms was also performed in CumInCad [MT06]. This is a â&#x20AC;&#x153;cumulative index of publications about computer aided architectural design. It includes bibliographic information about over 7.400 records from journals and conferences such as ACADIA, CAADRIA, eCAADe, SiGraDi, CAAD futures and others.â&#x20AC;?The search in this article database reveals a different balance, as shown in Table 2.2. There are more references to classic CAD applications, such as AutoCAD, which was to be expected as the database covers a larger time period and is less likely to pick up more terms for recent applications or trends. This last search only retrieved terms that have been used in paper titles or in the abstracts, not in the full text of the papers, which might underestimate the numbers. 51 PDF-versions of the proceedings were used to derive some statistics (using a grep-tool). The search was not case sensitive, since many articles do not take the correct capitalization into account. . .

2.6 References to common CAD and 3D applications in academic research 93

Figure 2.3: Average software references in Conference Proceedings

Table 2.2: References to common CAD and 3D applications in CumInCAD Search in CumInCAD Application Count ArchiCAD 17 AutoCAD 117 BIM 4 CATIA 6 MicroStation 14 Revit 0 Rhino 5 SketchUp 0 VectorWorks 0

Chapter 2. Trends and evolutions in design applications

Interpretation of the results This short analysis has no real statistical value, since the acquired data are insufficient, but it helps in formulating trends, with at least some numeric founding. The large attention for Autodesk products reflects their strong market position. It was also expected that applications such as AutoCAD and ArchiCAD were referenced quite often, but what might come as a surprise is that general modeling applications, such as Maya, FormZ and 3ds max/3D Studio are referenced with almost the same frequency. Many universities use these applications in their educational curriculum, which probably influences the attention within research papers. Even more remarkable is the relatively high attention for CATIA, which is usually applied in high-end automotive or aerospace design. This is probably due to the increased interest in its application into architecture by the office of Frank O. Gehry, which is widely covered in both popular and academic media. Overall, there is a rather small amount of references to existing commercial applications. Apart from AutoCAD, most papers hardly reference commonly used design applications. Would this be caused by the assumption that these tools are taken for granted and they are seen as a commodity, rather then a research tool? The information from this brief inventory is too limited to draw any funded conclusion. It does, however, strengthen our believe that the thorough overview of CAD and 3D software in this doctoral research might be valuable.

2.7

Hybrid use of design applications

Applications such as Google SketchUp, Autodesk Maya and McNeel Rhino are becoming very popular in architectural offices, where they are increasingly integrated in the regular office workflow, alongside traditional CAD software. There is an increasing hybridization of applications, where especially CAD applications are gradually integrating typical features of DCC applications, such as advanced modeling, visualization and even animation. Even then, the usage of CAD programs in the early stages of design is limited. They are typically too complex or demand too much input for the level of information that is available when initiating a design. Dedicated modeling or animation applications do not force the user to provide an amount of detail typically required with CAD software, allowing the designer to evaluate design alternatives more easily. Only when the design has been formed conceptually, CAD tools will be applied, thus reducing their potential to design elaboration and administration. There are few 3D applications that enable CAD-like features into their feature set, though. Drafting and producing technical simulations is still limited to CAD software and sometimes to Desktop Publishing or DTP -software, such as Corel CorelDRAW or Adobe Illustrator.

2.8 Conclusion

As a result of a more hybrid use of different applications throughout the design and elaboration of a project, companies are starting to improve the exchange of mainly geometrical data between these applications.

2.8

Conclusion

What we can learn from these trends is the fact that there are many different applications available, for all budgets. An architectural practice which embraces digital tools often develops a workflow based on a hybrid use of several tools together. Even though the products of Autodesk are probably used most, no single product and not even a single company provides solutions for the full design process. The digital design process is thus not a smooth, integrated experience but rather a hybrid amalgam of widely differing applications, each with its own strengths and limitations. The question how design information can then flow between all these different applications becomes more important. This will be discussed in the following Section. For this doctoral research, it is important to see that it is not likely that a single software application can fulfill the role as a complete design solution. To be able to integrate any application into a hybrid workflow, it is important that the data structure is well thought out and that data exchange is a part of the solution. This doctoral research suggest a possible approach for such a central data structure, without claiming that it will replace the existing solutions. And some of the features in this structure are meant as propositions to improve the workflow in existing applications as well.

Chapter 3

Exchange of CAD Data and Building Data In a building project, a design is elaborated in several steps. From sketching, to modeling or drafting, the project evolves, often in different applications and with different amounts of detail. Throughout the whole building process information has to be exchanged between architects, clients, authorities, contractors and external consultants. Even if a large part of the data never leaves the office, chances are that the design has to be interpreted in different applications. This can be CAD, visualization and animation software, but also word processors, spreadsheets, databases and dedicated calculation software for tasks such as project planning, energy performance and stability simulations. There is no software that integrates the whole process into one application, so information has to be exchanged in some form. The worst case scenario is where all applications speak a different dialect and project data have to be re-created for each different purpose. Not all applications require the full information content, but all of them need at least a part of the projectâ&#x20AC;&#x2122;s data. Re-creation leads to unproductive copy work and introduces disconnected and contradicting versions of the design. This may lead to superficial work and project errors, which could become very expensive when discovered on site, if discovered at all. Some data formats are usable to exchange at least a part of the projectâ&#x20AC;&#x2122;s data. Most commonly, a subset of the geometry might be exchanged and in some cases, this is all that is required, such as in visualization. But in other cases, the geometrical representation or the design is insufficient and the actual CAD model needs to be exchanged. This not only implies the transfer of a project file to the other party, but making sure that both parties have control over the changes in a project and the permissions and responsibilities of the different actors are clearly defined. To enable this, a complete revision workflow has to be set up, including the possibility to have design versions accepted or reject in a review procedure. Creating a building model is one task, but passing on this model with all its embedded knowledge is another concern. 97

3.1

Chapter 3. Exchange of CAD Data and Building Data

CAD Data

There are a few file formats for CAD data which have become a de facto standard, even though they are strictly spoken proprietary formats for particular applications. They usually focus on the exchange of geometrical data. DWG/DXF This is the native format for Autodesk AutoCAD and is used by many Autodesk products, but also by several competing applications. This format represents the full drawing database, including geometry, annotation, blocks, layers and even additional data. Extended modules, such as Architectural Desktop, also store all data inside the DWG file. The format is directly dependent on the version of AutoCAD, so there are many different versions of the format as well. Typically, users of competing programs are not always able to read or write the latest version of the AutoCAD files software. DWG files support all the data a user can embed inside an AutoCAD project. This includes all geometrical 2D and 3D data, but also additional metadata and custom objects, such as those created in applications built on top of AutoCAD. Initially the DXF or Drawing Exchange Format-format was meant for the exchange of drawing data, but most competing applications currently support the DWG format. The use of DXF as a common CAD format has decreased and users commonly exchange DWG files between different applications. This is largely due to the availability of DWG programming libraries, both from Autodesk and from competitors. DGN This is the format for Bentley MicroStation and was a single format for a whole generation of MicroStation based software. In contrast to Autodesk, Bentley published its format as an open standard, but the company lacks the market penetration from its competitor. Conceptually, DGN files are comparable to DWG files, but technically they are completely different. Since the V8 generation of MicroStation, the format embeds the whole DWG format as well, allowing MicroStation users to generate DWG-compatible drawing entities in a MicroStation project. This is useful when design files need to be used by several parties, from which some might use AutoCAD and others MicroStation. As such, MicroStation can be configured to only generate valid DWG entities, ensuring a correct exchange with AutoCAD users. Competing CAD software usually supports DWG only as an exchange format, for which a translation step is required when importing and exporting.

The Open Design Alliance and the DWG format The Open Design Alliance(ODA)[Ope06] is a non-profit organization, sponsored by its members, which originally focused on creating software libraries to read

3.1 CAD Data

and write files in the DWG format from AutoCAD. The ODA was created as a spin-off from the IntelliCAD consortium, which originated from Visio, as discussed earlier. The ODA has reverse engineered most aspects of the several versions of the DWG format and its DWG libraries are widely used for different CAD applications. This is not without problems, not in the least from Autodesk itself, who are making big efforts to prevent the ODA to fulfill this complicated task. Evan Yares reported on his blog1 that the ODA not only faced technical difficulties but also legal limitations, buried in the End User License Agreement (EULA) of Autodesk software to create those libraries for the version 2007, which is the first version since releases 2004/2005/2006 to modify the drawing format2 . In September 2006 the ODA announced the availability of their libraries with added support for the 2007 DWG format3 , but at the end of 2006, Autodesk responded by filing a lawsuit against the ODA, as reported by Randall Newton 4 , accusing the ODA with trademark infringement with the DWGDirect 2007 libraries, which were developed to allow members to read and write DWG files using the 2007 format. The trademark concerns the TrustedDWG digital signature, which was meant to distinguish between DWG files that originated from Autodesk applications and files created with other libraries. By enabling the DWGDirect libraries to correctly insert this signature into the DWG files, Autodesk claims the trademark was violated. The trial is being followed in a blog on http://www.adskvoda.com/ . As a results, the ODA can still distribute its libraries, but had to remove the code to emulate the digital signature. Another concern is the DWG name itself. It has been in use since more than two decades, but in 2006 Autodesk applied for a trademark for the use of the word DWG. It is now listed with the other trademarks on the Autodesk homepage5 . Again, Evan Yares leads the discussion6 . At the time of writing this text, no trademark on the DWG name was assigned to Autodesk7 . The ODA expanded their original goal of documenting the DWG format and currently includes support for MicroStation files as well. In contrast with Autodesk, Bentley is a member of the ODA and provides and publishes the MicroStation DGN format. In an almost amusing announcement8 , Autodesk retired the AutoCAD-based Civil 3D, Map 3D, Land Desktop, Civil Design and Survey 2005 Releases earlier then planned in 2006. Not because these applications had been fallen out of use, but since they licensed code from competitor Safe Software to be able to load DGN files. This functionality was based on libraries of 1

http://www.evanyares.com remarks about the technical and legal difficulties surrounding the translation efforts can be read at http://aecnews.com/news/2006/03/28/1498.aspx and http://worldcadaccess. typepad.com/blog/2006/03/yares and newto.html . 3 http://www.tenlinks.com/NEWS/PR/Open deisgn alliance/091306 dwg.htm 4 http://aecnews.com/articles/2098.aspx 5 http://usa.autodesk.com/adsk/servlet/item?siteID=123112\&id=924623 6 http://www.evanyares.com/the-cad-industry/2006/4/24/ autodesk-tries-to-trademark-dwg.html 7 http://worldcadaccess.typepad.com/blog/2007/08/first-use-datet.html 8 http://aecnews.com/news/2006/04/25/1563.aspx and http://acecivil3d.blogspot.com/ 2006/03/2005-product-discontinuations.html 2 Other

100

Chapter 3. Exchange of CAD Data and Building Data

the ODA, from which Autodesk is obviously not a member. Autodesk is creating their own DGN importer from scratch, available for testing from the freely accessible Autodesk Labs 9 , albeit disregarding any 3D information. A MicroStation oriented blog10 reported many issues with this importer and exporter plugin.

What is wrong with the DXF format? According to Autodesk, the DXF format is the format to exchange drawings from AutoCAD, where the DWG format is the native format for AutoCAD and AutoCAD-based applications. However, in practice, the DXF format suffers from some limitations. Evan Yares wrote an opinion article11 explaining these limitations albeit his text is somehow biased to promote the use of the libraries from the ODA, obviously. Some of his remarks are repeated here. DXF as a format is not completely documented; ACIS solids inside DXF are encrypted; the files are generally much larger than their DWG counterpart; the numeric precision of coordinates is lower than with DWG; the user still has to make the translation from the working DWG file to export it into a DXF file; vertical applications such as ADT or MDT do not fully store their data in the DXF file. In practice, most applications and users avoid the use of the DXF format and rely on the direct exchange of DWG files.

Other formats Are there other CAD software formats that are widely used? Due to the large amount of AutoCAD and MicroStation users, no other native CAD format has become a de facto CAD standard in the same sense as DWG and DGN, but there are other formats in use for exchange of CAD data. IGES The Initial Graphics Exchange Standard is a format meant primarily for the exchange of accurate surface geometry. It is not as common as it used to be, but it has good support by design software. This has never been a common format for architectural design. SAT The format for the Spatial ACIS modeling kernel, supporting complex surface and volume data. This is the ASCII version of the format. There is also a binary form. The ACIS format is unitless at its core, but the file should normally contain a scaling factor, to define the real world size of a model unit. HSF & HMF The HOOPS Stream format and the HOOPS Meta format are both developed by Tech Soft 3D, which is not an application company, but a developer of an application framework used by several CAD companies. 9 http://labs.autodesk.com 10 11

http://www.eatyourcad.com/article.php?incat id=1175 http://www.opendesign.com/about/whtpaper/whynot.htm

3.1 CAD Data

101

They provide toolkits for the OpenHSF format, which supports streaming. The meta format contains the same information, but in an ASCII format. There is support for text, geometrical entities, display settings and a whole scenegraph. Application developers can also add custom metadata to the nodes or segments from the scenegraph. More info on HOOPS can be found in Section 19.1 on page 369. GDL This started as an internal format from Graphisoft for use inside their flagship product ArchiCAD, but it has become more independent. Its main attraction is the exchange of CAD library elements, for which they developed a script-like language called the Geometric Description Language (GDL) [NC00]. Instead of exchanging static CAD models, the generator script is stored, which means that a single GDL-script can be used to generate a whole range of object variations, based on user-editable parameters. Through the GDL-adapter, which is an AutoCAD plugin, GDL objects can also be integrated into AutoCAD or inside a web-browser. That said, the format is hardly used outside of ArchiCAD, despite it potential for parametric product databases. As a consequence, Graphisoft is phasing out the GDL-adapter, but still focuses on the GDL-explorer, which is an integrated GDL-viewer for use in web-browsers. The file extension of GDL objects depends on their purpose, but most generic items use the GSM extension. XVL This is a 3D publishing format, by Lattice3D, implying that it is not meant as a native file format for CAD applications, but as a highly compressed and optimized format for the exchange of CAD models with other applications. More info can be found in a white paper at the Lattice3D website12 . U3D The Universal 3D format is an effort by Intel and other companies to define another common format for the exchange of 3D models. It is slowly getting recognition, thanks to the ability to embed U3D formats inside PDF documents. Such documents embed an interactive model inside a formatted document. The printed version contains only an image, but when opened on a computer, the embedded interactive content becomes available. The latest addition to the Adobe Acrobat family is Acrobat 3D, which is an extended version of the Acrobat software with the possibility to embed U3D models in PDF documents. Other formats, such as 3DS or OBJ can be imported too, allowing the user to distribute documents to different parties, without the need for additional viewer software, apart from the widely used Adobe Reader. Many CAD applications already support the export of PDF documents with embedded U3D files directly, such as recent releases of Bentley MicroStation and Graphisoft ArchiCAD. 3DXML This is an XML-based file format from Dassault Syst`emes 13 , for the 12 13

http://www.lattice3d.com/whitepaper/whitepaper 030305.pdf http://www.3ds.com/3dxml

102

Chapter 3. Exchange of CAD Data and Building Data integration of 3D and PLM information inside other documents and applications. It is not meant to replace the proprietary formats from Dassault Syst`emes’ main CAD applications. Where the CAD format is used by the engineer/designer, the 3DXML format is meant for end users, clients and third parties.

JTOpen A format for the manufacturing industry which is gaining acceptance world wide. It is primarily targeted at the exchange of PLM data. The JTOpen format14 is maintained by the commercial PLM company UGS, which develops the format as an “open platform for visualization, collaboration and data sharing across the product lifecycle”. UGS has two major CAD-applications: SolidEdge 15 and NX. The former is focused on mid-range businesses while the latter is targeted at the high-end. The distinction between mid-range and high-end is left at the discretion of UGS, since it is mainly a commercial divide. On the cadalyst website 16 a qualitative review of the JTOpen format can be found. DWF The Design Web Format 17 is an open format from Autodesk, for the exchange of 2D and 3D data. The format compresses the geometry, to limit file size and facilitate online exchange. It is not meant for editing, lacking the full CAD data and accuracy. The format can be compared with the Adobe Portable Document Format (PDF), but optimized for CAD. However, Autodesk aggressively markets DWF against PDF, focusing on smaller file sizes with CAD documents. Most Autodesk applications can export this format, but a free Windows printer-driver can be used to generate DWF files from any application. Autodesk is also developing a web-viewer, which does not require any software to be installed18 in an open techology preview, called Freewheel. This enables plugin-free viewing, where the server will pre-render images from the drawing or 3D model. Many formats have been proposed to form a universal exchange format, yet most are still pretty much tied to specific applications, which hinders their support by competing products. It is safe to assume that the market dominance of both Autodesk formats DWG and—to a lesser extent—DXF still defines the largest part of existing CAD data exchange. These formats also represent the common file format used in free or commercial content libraries for CAD users. It is also important to mention that many of the exchange formats are more targeted at “Downstream”use, where the CAD model is stored in a proprietary 14

http://www.jtopen.com a part of the UGS Velocity Series, which contain CAD software SolidEdge, Finite Element Analysis software Femap and Collaborative Product Development Management software Teamcenter. 16 http://manufacturing.cadalyst.com/manufacturing/article/articleDetail.jsp?id=363959 17 http://www.autodesk.com/dwf 18 http://dwfit.com 15 Actually

3.2 3D Data

103

format, whereas the open format is meant for use in documentation, reviewing, marketing documents, websites and email. In some cases, an open format such as Adobe PDF is also a possible solution, as explained in a press release19 on the increased use of PDF in Nemetschek products. While PDF as such is created in the context of the DTP industry, its cross-platform and reliable support for fonts, colors and line weights can ensure a correct transfer of drawing data. E.g. when exchanging CAD documents in other formats, such as DWG, fonts that were used by the sender are not automatically included, leading to problems when reproducing the drawing. It is not always allowed to send fonts to other parties, since they might be copyrighted and commercially licensed.

3.2

3D Data

A set of 3D formats can be additionally used to exchange geometry between 3D applications. Most of them are also formats related to particular software, such as 3DS for the old MS DOS version of Kinetix 3D Studio 20 and OBJ for the older generation of Autodesk Maya, called Wavefront. They are still in use, because of the fairly basic layout of the formats, which makes them rather straightforward to support. Their main use is still the exchange of data for animation or visualization software. 3DS This is the format for the old MS-DOS version of 3D Studio. It supports polygonal geometry only, but retains basic material, lighting and animation information. OBJ This is the format for the old Alias Wavefront animation software. This format has support for curved geometry, which makes it better for the exchange of freeform surface models. VRML and X3D The Virtual Reality Modeling Language, is an open standard, developed for use in animation and web applications21 . This rather old format is still widely supported. Its successor, X3D might be more optimized and supports streaming, but it misses the wide support VRML has in current software applications22 . FBX One particular format to notice is FBX, the enhanced FilmBox and later Autodesk MotionBuilder format, which has become a new standard for the exchange of 3D data between DCC applications23 . This is of particular use for games and character animation, but less common in an architectural environment. 19 http://www10.aeccafe.com/nbc/articles/view article.php?section=CorpNews\ &articleid=344677 20 Now followed up by Autodesk 3ds max. 21 http://www.web3d.org 22 It is interesting to notice that many applications and many research projects still rely on VRML models to browse 3D geometry from a CAD application. Its old age did not prevent it to stay a de facto standard format. 23 http://www.autodesk.com/fbx

104

Chapter 3. Exchange of CAD Data and Building Data

Collada The format is an open Digital Asset Exchange Schema for the interactive 3D industry. It is a recent effort, originating from game developers, to set up a common and open format for the exchange of resources and assets between DCC applications and game engines. The acronym stands for a COLLAborative Design Activity 24 . Two trends are worth mentioning in this context. â&#x20AC;˘ Many commercial CAD companies refrain to publish their format specification and often modify their file structure; â&#x20AC;˘ These same companies develop writers and importers to enable the use of formats of their competitors, against which they seem to be protecting their formats.

3.3

Product Model Data

Apart from these common formats, there are two formats that are developed particularly for the exchange of product model data: STEP and IFC.

3.3.1

STEP

This is the ISO 1030325 STandard for the Exchange of Product model data [Owe93, BW91]. It was meant to be widely used throughout the whole industry, but for the building industry, there has been little support, if any at all, by any of the companies who produce software for architects. That said, the variations of STEP for the exchange of product model data between Mechanical Design software, are being used today and are supported by most applications. While there is no architectural software using the STEP format, the format was used as the basis for the development of the IFC format, which will be discussed in the next paragraphs. More precisely, the EXPRESS data definition language, which was developed for STEP is still used to define the IFC structures.

3.3.2

IFC

The Industry Alliance for Interoperability (IAI) was founded in 1995 from a group of US based companies, who where discussing the collaboration between different software applications, in the margin of the ARX development system for AutoCAD by Autodesk. It was decided to focus on developing a vendor neutral standard for software interoperability. They used the EXPRESS data definition language, that had been developed as an ISO standard, within the STEP project. 24 25

http://collada.org http://en.wikipedia.org/wiki/ISO 10303

3.3 Product Model Data

105

These developments resulted in the first release of the Industry Foundation Classes (IFC) in 1997, which is a format specification to describe a building project. Together with the format, a certification process has been established, to be followed by software developers claiming compatibility with a certain release of the IFC specifications. The organization is currently named International Alliance for Interoperability, using the same acronym as before [Int06]. Even though it is evolving rather slow, due to it having to go through an extended procedure, the format gained support by most key players in the BIM market, such as Graphisoft, Bentley, Nemetschek and Autodesk 26 , even though Autodesk left the IAI temporarily. What distinguishes formats such as IFC from others is the content that can be exchanged. Instead of the exchange of geometry or graphical entities, the objects themselves are stored. However, each application has its own set of object definitions, which might or might not be supported by the IFC specification. When a building model is saved into the IFC format, chances are that the file does not contain each feature that was available in a particular BIM application. That said, at least a common set of building elements will be exported and restored as parametric building elements and not only as pure geometry. When imported from an IFC file, building objects retain their building semantics. This was not possible before the IFC format was developed, unless a developer was willing to write application plugins that reverse-engineer proprietary building model formats, which is a very difficult task. A good introduction to the concepts if IFC can be read in [Khe06, see IFC Feature http://www.aecbytes.com/feature/IFCmodel.htm ]. IFC files are not only meant for use in building design applications. Several applications, such as Solibri, NavisWorks, Constructor and Estimator, can cooperate with BIM software, through the use of IFC files, as discussed in [Gol06]. Though the IFC supports the description of a building project, not every information is readily kept inside this format. An IFC-compliant approach in the context of exchanging additional information can be read in [Yan03]. In that project, additional attribute data, which was not available in the IFC format, was successfully embedded using the techniques provided by IFC and the EXPRESS language. A building model was created in ADT. The additional information was managed with custom Visual Basic routines. When the model was published as an IFC document, it could be transferred to an online server, where it was successfully queried in an online form, using Java. The IAI maintains an overview of different tools and viewers for the IFC format on their website27 . There is also additional information on IFC on the Data Design System website28 . Beware that many of the tools to utilize IFC documents 26 For

a more complete overview of different applications with their respective support of the IFC specifications see the following website: http://www.bauwesen.fh-muenchen.de/iai/ ImplementationOverview.htm . The main IAI homepage is preparing a database to search such applications, but that was not available at the time of writing. 27 http://www.iai-international.org/software/ToolsforIFCdevelopers.html 28 http://www.dds-bsp.co.uk/IFC.html

106

Chapter 3. Exchange of CAD Data and Building Data

are commercial. From the free offerings, many are provided as Windows-only binaries, which might hinder the usage of IFC in other environments, where Open Source and cross-platform solutions are required.

Using XML to exchange building data IFC was set up before the wide acceptance of the eXtensible Markup Language (XML). Recent developments have added an XML-based IFC scheme (ifcXML), alongside the Express-based IFC format. There are additional XML-schemes for the description of building data, such as aecXML, gbXML and others. A qualitative overview and critique on these schemes can be read in [FBW00], discussing the use of XML and interoperability in building modeling. While the article questioned the validity of XML as a carrier of building information models, other developments have shown that it is possible. Our own data structure is also successfully using an XML-based format to contain the whole building model, including all relations.

3.4

Exchanging information without CAD software

While it may seem that the key solution to data exchange would be either wide support for different file formats in an application or adherence to agreed upon standard file formats, there is a third path to follow, which might be valid in many cases. As mentioned before, formats such as PDF or DWF are downstream formats. They are not as accurate or complete as the original CAD documents and they are usually not usable for further editing, but they serve a purpose of file exchange. These formats can be thought of as digital printouts, to be sent to other parties. They can be used for visual inspection, redmarking, printing or even as archived plotting documents. They can contain graphical information that can be measured with a precision that was not possible with paper-based documents, even though they might not be as accurate as the originating CAD documents. Such measurements are usable in quantity estimations or regulations inspecting. But they can also serve a purpose of providing searchable documents. Textual information, such as labels and annotation, but also attribute information and other metadata can be retrieved. Text search tools can be used to execute queries on these files, in a similar way as a database query. The â&#x20AC;&#x153;Beyond the Paperâ&#x20AC;? blog29 provides some examples of available search technology. While this blog focuses on the DWF format mainly, the techniques are generically applicable in many cases. Noticeable examples include Docupoint Discovery30 and the DWF Text Search article31 . Another 29 30 31

http://dwf.blogs.com/beyond the paper http://dwf.blogs.com/beyond the paper/2006/11/docupoint disco.html http://dwf.blogs.com/beyond the paper/2006/09/search.html

3.5 Cross-application exchange and the online database

107

article that was linked from the previous blog discusses techniques to query CAD content with web searches32 . What makes this compelling is the possibility to retrieve information from lightweight and optimized exchange formats, with structured searches and without the requirement of having CAD software installed. This is especially important as it allows many of the parties involved in building projects to improve their access to the content.

3.5

Cross-application exchange and the online database

While it is almost impossible to construct a complete mapping between all applications and all file formats, it is possible to generate summaries, between selected popular formats and selected popular applications.

Tabular Overview As a summary, an overview table of the possibilities of CAD data exchange between some of the most popular design applications and some of the commonly used file formats can be retrieved at the EatyourCAD website33 . This website presents some CAD applications and file formats. The value of this table lies in the additional version information, indicating which versions of applications can exchange which versions of the file formats. However, in doing so, the table becomes quickly outdated, since recent applications are not included. There are also a few minor omissions, assumably since the table is created by someone with mostly MicroStation and AutoCAD experience. Based on our own database, a shortened but slightly corrected version of this table is shown in Table 3.1. This gives an up to date listing of common BIM applications and some important formats. Table 3.1: Compatibility Matrix between common BIM software Software Allplan ArchiCAD AutoCAD Arch. Bentley Architecture Revit Architecture VectorWorks Arch. I = Import E = Export â&#x2C6;&#x2014; = External plugin 32 33

BIM IFC I/E I/E I*/E* I/E I/E I*/E*

DXF I/E I/E I/E I/E I/E I/E

CAD DWG I/E I/E I/E I/E I/E I/E

DGN I/E I/E I/I/E -/-/-

http://www.stress-free.co.nz/web searching of cad content http://www.eatyourcad.com/article.php?incat id=918

3DS -/I*/E I/E -/-/I/E

DCC STL -/-/-/E I/E -/-/E

WRL -/-/E -/-/-/-/-

108

Chapter 3. Exchange of CAD Data and Building Data

This indicates the good support for the IFC format with BIM applications and the rather limited support for DCC formats, which are used for visualization.

Schematic Overview Based on the database, as discussed in previous Sections, a more schematic overview of file formats and applications can be displayed. Figure 3.1 displays some of the formats used to interchange data between some popular CAD applications. DWG

AutoCAD

SAT

MicroStation

IFC

IGES

STL

ArchiCAD

obj

DGN

VRML

AutoCAD Architecture

3ds

DXF

Revit

Figure 3.1: Data exchange between CAD applications What can be derived from these CAD applications, is the wide support for DWG and DXF but the rather limited support of DCC formats. This is sometimes required for visualization purposes or also to import freeform models into the CAD environment, especially polygonal geometry. A similar scheme is displayed in Figure 3.2, where the exchange between some popular DCC applications is displayed. This illustrates the reasonable support of CAD formats and the good support for the old formats, such as 3DS or OBJ . In many cases it is problematic to go back and forth between applications, unless only the geometric mesh is required. There are many other applications, with sometimes limited data exchange support. However, in practical cases, conversion programs can be used as an intermediate tool. Typical examples include Okino Polytrans, RightHemisphere Deep Exploration or the shareware program 3DWin. They are all included in the database. It is possible to combine the two schemes, which also adds additional conversion possibilities of file exchange between CAD and DCC applications. This is illustrated in Figure 3.3.

3.5 Cross-application exchange and the online database

109

DWG

3ds max

Lightwave

IGES

FBX

LWO

Maya

3ds

Cinema4D

STL

DXF

VRML

obj

Figure 3.2: Data exchange between DCC applications

DWG

AutoCAD

Lightwave

3ds

LWO

Cinema4D

DXF

3ds max

IGES

MicroStation

DGN

STL

AutoCAD Architecture

IFC

Revit

ArchiCAD

SAT

obj

Maya

VRML

FBX

Figure 3.3: Data exchange between CAD and DCC applications

110

Chapter 3. Exchange of CAD Data and Building Data

Even with only a limited selection of applications and formats, the scheme gets overwhelming. At the same time, this scheme covers a large part of the current file exchange routes, at least within the context of architectural modeling and visualization. However, in many cases, users are only interested in a subset of these exchange routes, e.g. querying the route to go from application A to application B. When all this information is included in the applications database, such routing can be generated quite easily with database queries and thus made visible on the applications website as well. Limitations and Remarks What is missing in the schemes displayed here, is qualitative information. While it is possible to e.g. convert an AutoCAD document to a 3DS file, it is not displayed which information is effectively transmitted or lost. When a visualization export needs to create renderings from an architectâ&#x20AC;&#x2122;s CAD model, triangulated geometry and material assignments are all that is required. In many cases, the visualization user will replace the CAD materials with more elaborated materials from the visualization software. If on the other hand, a MicroStation user needs to exchange 2D drawings with an ArchiCAD user, mesh geometry is irrelevant and a drawing format needs to be chosen. Exchanging the drawing using the 3DS format would yield no usable 2D information. The database structure has an additional layer of qualitative information, associated with the different file formats, allowing to have an automatic filtering, based on the desired exchange scenario. But for specific exchange scenarios, experience is required to know the most optimal data exchange route. It might even be beneficial to pass through a third application, which might act as a conversion tool, intended or not, as mentioned above. The Render Study, on our website, collected a wealth of experience for the exchange of a CAD model with visualization software. While other studies could be created, they are time consuming and difficult to update with new application releases. It is hoped that further elaboration of the database might turn it into a knowledge base of file exchange and application information, between applications from different market areas. While the underlying structure has been set up, the web interface is not fully completed and the database content is not completely filled in for all applications and formats. It is hoped that this enormous effort could one day be solved with some form of community portal, where contributors, using or developing the different applications, could enhance and complete the information.

Chapter 4

Academic Research on Architectural Design Applications Introduction This Chapter will give a brief overview of different academic research projects on CAAD and Building Modeling.

Research organizations on CAAD Many research results on CAAD are communicated through a collaborative framework of associations and conferences, world wide. This doctoral research references several articles and publications that have been presented mainly through the different conferences organized by these associations. As such, this is the most important academic source of information for this research. CAADRIA is the association for Computer-Aided Architectural Design Research in Asia. This association organizes a series of yearly conferences1 . CAAD Futures is a foundation for the promotion of CAAD, primarily promoting research and organizing a bi-annual conference2 . eCAADe is the association for Education and research in Computer Aided Architectural Design in Europe3 . The eCAADe organizes a yearly conference and also maintains an active mailing list. In addition to academic research interests in CAAD, the organization also focuses on the use of CAAD in education. SIGRADI is the Sociedad Iberoamericana de GrÂ´ afica Digital (the Iberoamarican Society of Digital Graphics). They also host an annual conference, targeting architects, designers and artists, so not strictly academic in nature4 . 1 2 3 4

http://www.caadria.org http://www.caadfutures.org http://www.ecaade.org http://www.sigradi.org

111

112

Chapter 4. Academic Research

ACADIA is the Association for Computer Aided Design In Architecture and is the North-American counterpart of previous organizations. In addition to an annual conference, the association is focusing on the use of computers in architecture, planning and building science. They also focus specifically on education and design creativity5 . These organizations organize conferences separately, but they maintain active collaborations and it is common for members to visit the events of associated organizations. Although the main focus of these organizations is CAAD, the research themes of these conferences display a wide interest range. While many of the themes of interest for the conferences and publications fall under a CAAD heading, this text will narrow it down, mainly to Building Information Modeling and Conceptual Design.

4.1

Sketch Design

With regard to conceptual design, there is a strong interest in Sketching, to incorporate the act of manual sketching into a digital form. While there are certainly many interesting approaches, they are usually less concerned with defining a building information model. Many of these projects focus mostly on the creation of 3D geometry. An interesting example is Structural Sketcher [Pra04, PAdVvW05]. This is based on drawing techniques, rather than on modeling methods. In this thesis, the interaction mechanics with a custom manipulator, called the Kite, was elaborated and compared with common design applications. While the use of manipulators in DCC software has become rather common, many architectural design applications do not often utilize their potential at full. Elaborations such as the Structural Sketcher can help improve their understanding. Manipulators will be discussed in the Chapters on interaction with building data.

4.2

Virtual Reality

In CAAD conference proceedings, there are numerous references to Virtual Reality applications. Many institutes apply these techniques both into their research and into their curriculum, for integration into design studios. While many attempts have been made to use Virtual Reality software and hardware, these are primarily visualization applications. While they serve their purpose in evaluating architectural design, the actual models are usually created elsewhere, e.g. in CAD or 3D modeling software. In the context of conceptual design, most interest lies in the application of modeling techniques directly inside the VR environment. Some of these research projects are actually combining sketching techniques with VR. 5

http://www.acadia.org

4.2 Virtual Reality

113

Examples of Sketching and Virtual Reality Sculptor is an application for spatial modeling [Kur98] 6 , developed at the ETH Zurich. This is a design application, focusing on fast modeling of 3D models, interactively and focusing on application in a Virtual Reality context. EsQUIsE Prototype of an application for the recognition of sketch gestures and annotation. The manual operations are translated into an annotated 3D model of a building [RPS05, JL04] 7 . DDDoolz Conceptual shape and volume creation application, for the early stage of the design process[dVA02]8 . In this system, an approach to unrestricted modeling is described. Starting from a simple cube, it can be copied freely, using simple drag and drop methods, without any GUI interference. While the scope of such a system is obviously limited, its concept proves to be easy to understand and readily applicable in a design exploration.

Interpretation Sculptor and DDDoolz explore freedom while designing in a 3D space. The generated model could be anything, from a building to an abstract sculpture. They both formulate approaches to release the user of user interface constraints, claiming for smoother integration into the design stage. While it is clear that ease-of-use will be required for design tools, there is an additional effort required when translating the abstract model to a BIM model. This is apparent with most modeling oriented approaches. Commercial applications such as SketchUp have the same problem. They manage to appeal to designers for their modeling freedom and for their flexibility or general applicability, probably since they do not take building constraints into account. On the other hand EsQUIsE tries to embed more information about the building into the generated model. It does so be starting from a data input method that translates the traditional drafting on the drawing board into a novel data capturing solution, digitizing the sketches into a more structured model. Other approaches include [EB95], [JWS99], [Ste99], [Do00]. [Ste05] further elaborates on the mixture of architectural design, sketching and virtual reality, applied in an urban environment. The application into an urban context places certain constraints on the system, but at the same time ensures usability of the design result into further analysis. For this doctoral research, it is important to distinguish between different possible approaches. On the one hand, the sketch tools present design freedom, by removing constraints and by focusing on geometric modeling rather than on 6 7 8

http://www.arch.ethz.ch/â&#x2C6;źkurmannd/sculptor/sculptor frames.html http://www.arch.ulg.ac.be/Lucid/Projects EsQUIsE SMA.php http://www.ds.arch.tue.nl/Research/DDDoolz

114

Chapter 4. Academic Research

information modeling. BIM software, on the other hand, follows the reverse approach. A content-rich building database is created, embedding constraints and relations and additional metadata, but often at the cost of limited applicability in the early design stages. A mixture of the two approaches might provide the right balance between modeling freedom and information structuring. The digital building model that is elaborated in this research is essential, to capture design information and whenever possible design decisions. It is from within this context that certain limitations, especially with regard to limitations in modeling freedom, have to be understood.

4.3

Representations

In [Ach97], the relation between knowledge and representations is elaborated. Graphic representations are at the same time encodings of the information that is represented. This thesis researches how the encoded design information could be reconstructed from the representations. A discrete set of graphic units is identified in a case study from different schematic drawings, to make a structured overview of generic representations. Another academic project involving the use of representationsâ&#x20AC;&#x201D;developed by researchers at the Technische UniversitÂ¨at Darmstadtâ&#x20AC;&#x201D;is GraCAD or Graphbased tools for Conceptual Design in Civil Engineering[SGB00, SSB02]9 . In a graph, the main entities are called nodes, which can have metadata in their attributes. Relations between nodes are represented by the edges in the graph. Starting from a graph model, the building program is translated into the listing of functional requirements. They are decomposed and used to generate a basic room layout. This layout is adjusted and check against rules. The final result can then be translated into a CAD model. The research also involves a PROgrammed Graph REwrite System or PROGRES, which is a system to rewrite a graph, according to specific domain knowledge. In that system rules are triggered to check the graph against constraints in the design. The importance of representations can not be underestimated. A Representation is more than an output document derived from a design. It is more than a formatted report generated from a database query. It is a translation of an abstract concept into a tangible graphical form. Representations are functioning as an interface to the underlying design. The design activity of an architect occurs mostly through a representation. In the elaboration of this doctoral research, it will be discussed how different representation types are required to enable the design application to follow the design throughout different Scale Levels and Design Phases.

4.4

Building Information Modeling

While the term Building Information Modeling might have been mostly supported by commercial software vendors, it seems to have been accepted by 9

http://www.es.tu-darmstadt.de/index2.php?page=709

4.4 Building Information Modeling

115

academic research as well. The research on digital building models has been active for at least two decades and is still continuing. In academic research on BIM, many different projects have tried to define a model to describe a building or a design. Overviews and reviews can be found in [ES95], [Gal95], [Ekh01]. Some of these projects have been compared and evaluated by Ann Hendricx in her Doctoral research [Hen00, Chapter 2]. Despite the fact that both academic research and commercial software development are clearly convinced of the potential of using a digital building model, there is not a single structure on which all parties agree upon. While the evolution in commercial CAAD seems to slowly converge into more or less the same direction, focusing on BIM and IFC, which will be discussed in following sections, academic research projects have had many different strategies. Different research groups have different interests and while they all try to describe how a building can be virtualized, some focus on manufacturing or design, on the spatial or the semantical structure, while others describe buildings from a different background, such as product modeling. Hendricx made a distinction between two groups or generations of building models. The first group includes different approaches. The General AEC Reference Model (GARM) [Gie88] was created in the context of the develoment of STEP [Owe93]. The RATAS [Bj¨ o94] as described in [Bj¨o92]. [ES95] discusses the Engineering Data Model (EDM) and the Generic Building Model (GBM), which is based on EDM. And finally the House Model of de Waard. A second generation contains projects such as BAS◦ CAAD [Ekh01], SEED [FCF94] 10 , KAAD, VEGA, BCCM and COMBINE2 [Aug95]. Since they are discussed into detail in the research of Hendricx, their description is not repeated in the current text. However, it is interesting to mention some additional developments, as encountered on recent conferences on CAAD. One such example is the B-processor 11 , [ALK+ 07] which is being developed at the Aarhus school of Architecture, in Denmark. This is an Open Source application for the modeling of buildings, where the modeling is supported by the inherent linking of enclosed spaces, to ensure a coherent spatial model. It uses the Java programming language. Another approach can be found in the TAD Designer application (The Architect’s Desktop), which represents the whole building as a recursive structure, using fractal methods [Sab07]. This allows the building structure to be tailored to the project, while at the same time proposing an approach to refine the model up to the desired detail level. Most data and structure is not fixed, but rather inserted as custom metadata. The application is actually an interface around a scripting language called ARDELA. 10 An 11

online archive for the SEED project is still accessible at http://www.seedling.org http://www.b-processor.dk

116

Chapter 4. Academic Research

Both examples are interesting in their approach to define the whole building structure with a fairly simple to understand structure. While the B-processor is an Open Source application, the TAD Designer software is currently being promoted as a stimulator for an Open Source Architecture, that is, to promote the exchange of design solutions, utilizing the software as a data exchange profile12 . Currently, there is also the emergence of oscad [TJ07], which stands for Open Source CAD. This is a collaboration between different research institutes, including members from Harvard School of Design and MIT. While the online website was set up for the sharing of the source code13 , it is currently not containing any usable downloads. However, based on the involved research partners, it might be interesting to see how this project will evolve.

4.5

The Design and Building Methodology Research Group

This Section discusses some of the research work that has been executed in the Design and Building Methodology research group at the Department of Architecture, Urbanism and Planning of the K.U.Leuven in Belgium. Selected other projects related to this doctoral research are briefly discussed. One of the ambitions within this research group it to improve the design process with digital tools. Some of the research subjects are digital photogrammetry, Case-Based Reasoning, daylight simulation, design rationalization, cost control, sustainability and building information modeling. The latter is the main research field for this Doctoral Research, but it is assumed that future research could interconnect with other research fields, e.g. to investigate cost control methods from within a digital building model.

4.5.1

Conceptual Scheme

The main concept for the integrated design environment is described in [Neu92], but since it is important for this research, the main conclusions are repeated in this section. The conceptual foundation for this environment has been laid out in the scheme of Figure 4.114 , with different Design Phases and Scale Levels, together with appropriate tests at different levels. Design Phases The scheme distinguishes between three major Design Phases. The Sketch Design Phase evaluates a basic design, usually for the architect or for approval by the client. The Preliminary Design Phase is used to communicate with the 12

http://tad.sabufrancis.com http://code.google.com/p/oscad 14 Edited from the original figure by H. Neuckermans. 13

4.5 The Design and Building Methodology Research Group

Figure 4.1: Conceptual Model for CAAD

117

118

Chapter 4. Academic Research

building authorities and other stakeholders. The Construction Design Phase is used when communicating with the building contractor on site. Scale Levels There is also a distinction between three major Scale Levels. â&#x20AC;&#x153; Each level is composed of entities of comparable size or importance, requiring a similar treatment in the design process.â&#x20AC;? The Masterplan Scale Level describes the site and the main building blocks. The Block Scale Level focuses on spaces or rooms inside a building block. The Space Scale Level handles the separate physical building elements, such as walls, floors or openings. In theory we can extend them with higher and lower-scale levels, such as an Urban Scale Level or a Material Scale Level. Grids Within this model, it is assumed that design entities are positioned on grids. These grids are adapted to the different Scale Levels and have different mesh sizes in the vertical direction than in the horizontal direction. Tests at appropriate levels A designer can perform evaluation tests in these different Design Phases or Scale Levels. The tests are adapted to the Design Phase or Scale Level. As such, a rough test with very limited parameters can be executed early in the design process, while a more elaborate test could be performed in a later Design Phase, when more detailed information is available. Intelligent Zoom During the design process, the model evolves. The display of the model is not merely zoomed, but the model representation should adapt to suitable display scales. When a designer looks at a construction up close, the system actually needs to display a higher amount of detail, while the display of an overview of the whole building can be simplified, not only for performance reasons but also to maintain the correct level of overview. Menu oriented choices To aid with the transformation of building elements into correctly detailed construction objects, a menu or wizard system is proposed, giving the designer a guided list of possible choices, adapted to the active scale level and design phase.

4.5 The Design and Building Methodology Research Group

4.5.2

119

CORE Object Model

The Conceptual Scheme was translated into the CORE Object model [Hen00], which is a theoretical model to describe a building design project. The development of this model did not use any of the building models from other academic research groups. This was motivated by Hendricx for several reasons: • Most research projects do not elaborate on methodology. • The data in these models often do not allow dynamic behavior of objects. • Although most of these projects understand the importance of non-physical objects such as Spaces and Activities, they all handle them differently. Therefore it was not acceptable to choose one of them as a clear “winner”. The CORE Object Model, as developed by Hendricx, forms a theoretical framework not relying on a rigid data structure. It is especially targeted at the design of a building model in the evolving workflow of an architect/designer. This model forms the starting point for this doctoral research. It is not taken for granted, since further elaboration and implementation might lead to adjustments, optimizations or simplifications. It allows, however, to focus on the desired feature set and functionality, rather then on reinventing yet another framework. The development of the CORE Object Model made use of MERODE [DS94] [SDVD99]. This is an Object Oriented Enterprise Modeling method, which has been developed at the Department of Economics at the K.U.Leuven, Belgium. The name stands for Model driven, Existence dependency Relation, Object oriented DEvelopment15 . This method helped to define the basic class structure and relationship-diagrams. Figure 4.2 displays a small part of the Entity Relationship Diagram (ERD) from the CORE Object model. It defines a Project as a collection of Elements, which can contain both Graphical Entities and CAAD Entities. The CORE Object model makes a clear distinction between the conceptual and the graphical information for a particular element. Figure 4.3 indicates that CAAD Entities generate a graphical representation. But the scheme also allows Elements with only Graphical Entities or Elements which have CAAD Entities that are not represented graphically. The graphical representation, using lines, surfaces or solids, will be automatically generated by the conceptual entities, which contain the real data. Each conceptual entity is an abstract object, such as physical element, space, masterplan block, grid. . . Each has a name and ID and provides basic functionality for linking and making a hierarchy. By assigning a certain type to this conceptual entity, its real functionality is chosen, such as Wall or Floor for Physical Elements and UserSpace for Spaces. The type contains the instance-specific 15

http://merode.econ.kuleuven.be

120

Chapter 4. Academic Research

Project 1 0..* Element

Drawing Layer

Graphical Entity 1

1 0..*

Drawing Layer Link

Local Coordinate System

CAAD Entity

Representation Link

1 1 0..* Dependence Link

Figure 4.2: Core of the Entity Relationship Diagram for a building project

mesh or solid

Element

lines and fills

Graphical Representation

Object "Name & ID"

Conceptual Data generates

"Physical Element" of type "Wall" with Composition "SolidBrickWall"

Figure 4.3: Separation between conceptual and graphical information

4.5 The Design and Building Methodology Research Group

121

information, such as size, length, height or control points, together with the behavior of this particular kind of object. By choosing a composition, information that is shared between different elements can be added, such as its internal set of material layers, as displayed in Figure 4.4. Physical Element "Wall" with ID:27

Physical Element "Wall" with ID:28

Type: "Simple Wall" From x to y

Type: "Curved Wall" From x to y Radius z

Composition: "Cavity Wall 30 cm"

Physical Element "Wall" with ID:29

Type: "Simple Wall" From x to y

Composition: "Brick Wall 14 cm"

Figure 4.4: Different types can share the same composition

4.5.3

Integrated digital modeling including daylight and insolation testing for architectural design in the sketch design phase

The Conceptual model and the CORE Object model have been further elaborated in a research project, funded by the K.U.Leuven Research Fund16 . This research project supported the initial phase of this doctoral research. Object Model Based on the Conceptual Model and the CORE Object Model, the main data structure was set up. A subset of the CORE Object Model has been implemented to be able to further investigate the functional performance of the data structure. The project also included a reflective phase to adapt and improve the proposed object model. Phase Transitions & Scale Transitions This project described the desired functionality of transitions between Design Phases and Scale Levels. Test for Daylighting Together with the data structure and the transitions, one of the evaluation tests has been elaborated in detail. The test for daylighting focused primarily on the optimization of a daylight simulation on annual basis, through the development of an optimized radiosity algorithm with Southwell relaxation. This has been 16 Reference

OT/2000/18

122

Chapter 4. Academic Research

finalized in the doctoral thesis [Gee03], which is briefly described in Section 8.2.1 on page 241. The final simulation test, however, was not integrated into the main design environment, due to time constraints. Database Another goal that was set in the OT project, was the description of the building project into a database system, allowing it to be queried and partly manipulated independent from the main design environment. Instead of exporting the project into a separate file, the project data consists of a database which can be manipulated from different positions. The design environment can be used to model a building project, but at the same time, additional interfaces can be added, based on regular database access. This research task has not been elaborated, due to budget constraints. Conclusions At this point in the text, only an overview of the particular project was given. The actual research results form the basis of the data structure and prototype as discussed in the rest of the text.

Conclusion These Chapters provided an overview of the current state of CAD and 3D in an architectural context. It was deemed important to provide an extensive overview of commercial applications and current trends, to give insight into the direction the CAD industry is evolving. Collecting information about different applications, but also insight about their companies and discussions on the exchange of CAD Data are aspects that can place the discussion on design software for architecture in a wider perspective. It is especially valid to involve technologies and applications outside the architectural domain, as a comparison and sometimes as a prediction of future developments that might occur in the field of architectural design applications. The overview of academic research on CAAD and BIM was left rather brief, since the text on the CORE Object Model handles some of these projects more extensively. It is interesting, however, to learn by browsing the content of conference proceedings on CAAD research, that the evolution of the commercial BIM applications and the ISO efforts on the establishment of IFC as a data exchange format, have been accepted by many researchers as a given. In many cases, researchers assume an approach where the building model itself is created by the architect in common BIM software, from which an IFC document is generated, which will serve as input for information retrieval processes. While this seems to indicate the acceptance of this format in both commercial and academic environments, it also points to the conclusion that many evaluation and simulation tools are applied as post-design calculations. Approaches from academic research seem to emphasize that Building Information Modeling is best supported by a series of collaborating solutions, exchanging a common model. This model could be based on the IFC format, as it seems to be accepted by most involved parties. While many current architectural design applications are more and more integrating features for simulation and evaluation, no single application is accepted as a complete design environment. While this might be a pragmatic approach, it is not trivial. Different applications and building models are only partially compatible and the Data Exchange is still real problem. In most cases, what is translated is a static but structured model, accurately describing a building as an assembly of components. However, much of the effort to embed design decision information into the model is not retained. This doctoral research does not mean to degrade these efforts, but will focus exactly on approaches to apply BIM in an early design context and to investigate methods to embed relations between design entities directly in the model. There are certain mechanisms that are usable from within a design context to create 123

124

Chapter 4. Academic Research

more structured building models, especially with regard to the coherence and synchronization of that model over different Design Phases and Scale Levels. In future research, it seems natural to extend the current research project with additional methods for data exchange, such as IFC import or export, which might make such as system fit into the wider architectural design pipeline. The current focus, however, is the development of the data structure underneath this building model. The next Chapters will elaborate on the concepts of the elaborated data structure and will then discuss the implementation of a prototype, which illustrates some of these concepts.

Part II

Concepts: A Data Structure to support a digital building model

125

Concepts introduction The next chapters discuss the concepts that have been developed throughout this research. The focus is on specifying the requirements and functionality for a building model, to better support capturing design intent and transitions. The building model, which represents a building project, requires a custom data structure. To generalize the concepts, this structure is not dependent on existing CAD applications nor on specific graphical kernels. The data structure will be used in a prototype application, where different representations form an interface for the designer. Through the creation of building elements and their relationships, the architect will translate a design in this environment, which provides means to investigate the design on different Scale Levels and throughout different Design Phases. The integration of evaluation tests provides valuable quantitative feedback throughout the design process. While the end user of such an application is the architect, the focus in this research is primarily on a more technical level. How can a data structure be suitable in a design situation? What requirements are there to such a system? What methods can be used for this functionality? Some of the goals include the desire for a flexible data structure, capable of storing entities with their properties and their relations with other entities.

An Integrated Design Environment for Architecture? The Conceptual Model [Neu92], which forms the basic framework upon which this doctoral research is executed, suggests the development of an integrated design environment for architecture. According to Mitchell [MC94] and Junge [JL95], an integrated design environment is not by definition a single application, but the collaboration between different applications, hardware and people of the design team where the project data are shared. A vertically integrated design environment is structured around the consecutive Design Phases, whereas the horizontal integration defines the different involved parties. However, as illustrated in the first part of this research text, currently no single solution exists which captures the whole design process. Most designers use an amalgam of applications, each suitable for different purposes. At the same time, academic research on BIM no longer aspires to develop such an environment either. On the one hand, several researchers focus on the main 127

128 workflow between designers and the construction industry, using out-of-the-box BIM software and IFC files. On the other hand, other research teams will specialize to solve isolated problems, such as energy performance, 3D modeling or online collaboration. While the actual development of an Integrated Design Environment for Architecture is too ambitious for a doctoral research project, we strongly believe that supportive mechanisms for such an environment are still desired in the design process. The next Chapters will thus explore how a data structure can help these integrations and what additional functionality will be useful for the support of different Design Phases and Scale Levels, based on the Conceptual Model. By starting with an open and flexible data structure, exchange of design project information will be facilitated between different involved parties. The application prototype, which is built upon this data structure and functionality layer, has been named IDEA+, reminiscent of the long term aspiration of working towards such an integrated design environment for architecture. The â&#x20AC;&#x153;+â&#x20AC;? in this acronym is motivated by the additional value of integrating evaluation tests within the early stages of the design process.

Chapter 5

The Data Structure Based on the proposed CORE Object Model [Hen00], a data structure was developed, as the initial implementation of a chosen subset of this model. The intention was not to complete the model, but mainly to explore and illustrate the concepts. Elaborating a data structure helps to evaluate the initial CORE Object Model and to chose a usable range of design entities, which are essential during design elaboration.

5.1

The structure of the digital building model

The digital building is modeled as a collection of design entities which capture information about the design. In contrast with regular CAD software, these entities capture architectural information rather then purely graphical or geometrical information. This is a trivial requirement for any BIM application.

5.1.1

Project

All design entities are embedded inside a single Project. A project also contains additional information about the design, such as site information and comments.

5.1.2

Elements

A Project consists of Elements. Elements form the basic building blocks to describe a design project. They are created and modified and form the translation of the architectural design into a digital building model. Elements are mostly containers for other entities. As such, Elements do not carry that much information. To the end user, however, manipulation usually occurs through these Elements. They are created, selected and removed. When they are selected, their embedded entities are presented to the user to be modified.

5.1.3

CAAD Entities and Graphical Entities

The design entities, embedded inside an Element, are CAAD Entities and Graphical Entities. 129

130

Chapter 5. The Data Structure

The CAAD Entities contain architectural information, while the Graphical Entities are usually generated from the CAAD Entities to represent this information. It is also possible to create Elements with only graphical entities. They serve as purely visual entities and might be used while sketching or exploring the design. This is displayed in Figure 5.1.

Element contains

CAAD Entity

contains

generates

Graphical Entity

Figure 5.1: The structure of an Element

CAAD Entities The CORE Object Model makes the distinction between Physical and nonphysical or Conceptual Elements. Common BIM software mostly focuses on Physical Elements, such as walls or floors. These are the elements that represent objects which are built by a contractor on site. These elements have a direct physical realization and represent an actual cost to the building owner. This cost is related to both the material costs, the realization costs and the costs in use. The non-physical elements group anything else that is of value in the project, but which has no direct physical representation. They are called Conceptual Elements. They are real design entities, from the point of view of a designer, even though there is often no physical counterpart nor a directly related cost involved. Typical examples of conceptual elements include spaces, activities and relations. All these entities are important enough for the designer to include them in the main project data. Graphical Entities While the CAAD Entities are usually sufficient to capture all design information, they can not be represented as such. When a specific graphical representation is required, the CAAD Entities will be ordered to generate Graphical Entities. These Graphical Entities can be lines, arcs, circles or curves, but also text labels, dimensions and filled regions. While they are usually only 2D in nature, there is no reason not to support 3D graphical entities as well, such as boxes, extruded contours or freeform geometry. Even then, it is also required that a Graphical Entity can be created independently. While the actual design has no real need for user-created graphical entities, the data structure enables Elements to contain independent Graphical

5.1 The structure of the digital building model

131

Entities. They are helpful for annotation, such as text or dimensions, and for additional graphical markup, such as line work, arrows and filled regions. While they are not representing any cost or any tangible entity, architects still rely on them to convey information about a design.

5.1.4

Library Elements or Shared Entities

Inside a project, several design entities have common parameters. There might be multiple walls, having the same structure and the same material. It would not be beneficial to define multiple but identical materials for different walls. Different CAAD Entities can reference the same Shared Entity. Typical examples include materials and element compositions. This is illustrated in Figure 5.2. This graph presents the data structure, as it was described thus far, from the viewpoint of an end user. It is not a complete display of the actual implementation.

Project

Elements

Physical Elements

Shared Entities

Conceptual Elements

Figure 5.2: Project structure Shared Entities are usually quite generic, resulting in their usability in many different projects. The contain entities such as Materials, Compositions, Activities and Representations.

5.1.5

Physical Elements and Types

As explained above, CAAD Entities can be categorized in Physical and Conceptual Elements. Physical Elements contain type and style information. The information specific for one type of object is described with the Physical Element Type. This defines the behavior of a Physical Element. Walls and Floors are examples of Physical Element Types. Each wall will behave similar, even though it has particular properties, such as size and position. The further categorization of Physical Element Types is defined in the CORE Object Model and is derived from the BB/SfB classification system. A partial elaboration of the structure of Physical Element Types is displayed in Figure 5.3.

132

Chapter 5. The Data Structure

Physical Element Type

Skeleton Element

Beam

Planar Element

Column

Wall

Floor

Roof

Figure 5.3: Physical Element Types

Each Physical Element Type instance contains different data, but all instances of a certain type follow the same structure and have the same behavior. All walls behave similarly, but each wall has specific data, such as height or length. The stylistic information, on the other hand, defines the characteristics which many entities have in common. All walls have a certain structure. This is captured in the Physical Element Composition. When a Physical Element references another Composition, its topology does not change, but the typology or style does. Switching between Compositions will not move the wall or modify its height. The wall might have a different appearance as the material layers, which are contained in layered compositions can be different. Since this Composition can be shared between many different Physical Elements, it has the characteristics of a shared element or a Style. The Composition is thus a Shared Entity, indicating that Compositions can be used by different Elements or even different Projects. It makes sense to define a catalogue or a library of Compositions.

5.2

Template Entities or External Object Library

While not elaborated in the data structure, there is the desire to define some entities inside a Library. A Library is a catalogue of template elements. When the end user instantiates elements from the Library, they have already many of their characteristics prepared. In an architectural office, it is very useful to define common library elements, from which instances can be generated in a project.

5.3 Grids and working planes

5.3

133

Grids and working planes

Grids A Grid is a common concept in design applications. Not only CAD software, but also Desktop Publishing and Image Editing software use grids to help the layout and alignment of graphical entities. In most situations, grids help while editing or drawing, but they usually serve as a visual clue and nothing more. Even though grids are only a visual aid, they are usually combined with a magnetic raster, forcing cursor movements to be restricted to the coordinates that are precisely on the grid points. Such a â&#x20AC;&#x153;Grid Snapâ&#x20AC;? can be optionally enabled, so the grid and the magnetic raster can function independently. A grid in architectural software gives an important visual clue about the scale of a design. Since the view on a design is not fixed, its size has no direct scaling reference. Zooming in or out shows the model at an arbitrary size and only the grid lines or dots define a scaling reference for the user. In the data structure, a Design Grids is an actual design entity. Design Grids can have a grid spacing or grid module in function of the active Scale Level. This is usually a horizontal XY spacing, combined with a separate vertical Z spacing. On the Masterplan Scale Level, this Z spacing can be aligned with Floor Levels, while at the lower Scale Levels a smaller spacing is advisable, based on ergonomic dimensions. This is usually much smaller than horizontal dimensions, since the human body is more sensitive to small height differences than to size differences of length or width. The Design Grids have separate settings for the different Scale Levels and are meant to fit into each other, not allowing spacing dimensions of a lower Scale Level to conflict with the higher Scale Levels. There are two possible approaches. The system could provide separate grid entities to be used on the difference Scale Levels. Through the connection of their Reference Points, they can be anchored. Another approach is including different grid spacings in a single grid entity. This will ensure that the grid will be represented differently on the different Scale Levels. At best, these modules allow for a hierarchical dimension coherence. Table 5.1: Suggestion for common spacing dimensions of Design Grids

Scale Level Masterplan Block Space

Design Grids Grid Size (mm) Grid 600/900 MasterGRID 300/600 BlockGRID 100/300 SpaceGRID

Module XY M1xy M2xy M3xy

An example of a hierarchic Grid is displayed in Figure 5.4.

Module Z M1z M2z M3z

134

Chapter 5. The Data Structure

Figure 5.4: Illustrating a hierarchic Grid

Working Planes A Working Plane on the other hand is an aid to generate a 3D coordinate from movements of the cursor, which is inherently only a 2D screen position. The mouse position is translated into a direction line, which intersects with the working plane and thus uniquely defines a single world coordinate. The working plane is usually set to the horizontal XY-plane, with a Z-coordinate equal to zero. It makes sense to adjust the working plane while modeling, based on the underlying objects. When a cursor hovers over another element, an intersection can be calculated to either define the intersection point or to define a temporary working plane based on the selected entity. This approach allows the user to model or draw on existing elements, without the need for manual adjustments to the active coordinate system or the active working plane. This approach is used more often in recent CAD or 3D applications, accelerating the drawing or modeling operations and diminishing the commands to set up active working planes. Both Google SketchUp and Autodesk AutoCAD apply such a technique, the latter only since the 2007 release, called the Dynamic UCS. Autodesk 3ds max provides an Autogrid option while modeling, which has the same effect.

5.4

Floor Levels

Most buildings have different floor levels or stories. This increases the complexity in the modeling of a building. While a simple building element is usually placed on a particular floor level, it actually interacts with other floor levels. In common 2D techniques, derived from drafting, buildings are drawn floor by floor. Whenever there are connections to other floor levels, however, they are displayed. Elements on a level below the current one, but visible, will be drawn as projected lines. Elements above the current floor level will sometimes be drawn or suggested, e.g. the edges of a roof or the axis of a beam. From the viewpoint of a designer it seems remarkable that a concept as common as a floor level is often not fully supported in architectural design applications, as illustrated with a few examples from common BIM applications.

5.4 Floor Levels

135

Floor Levels in BIM applications Autodesk Architectural Desktop In ADT, there is no direct feature to define floor levels. The system of referencing files inside other files, which is known as XRefs inside AutoCAD, is used to link several floors together. The design is effectively split into separate documents, in a way that the full building model can only be seen in additional assembly drawings. This system was discussed in Section 6.1 on page 144. Overall, ADT presents a very complex system and is not without conceptual problems. • To be able to define a section through the full building, the section has to be defined in a View where all levels can be accessed. But this does not include the graphical symbol of the section in the plan views, such as the line and the text label. They have to be drawn separately, which makes them unconnected. It is also required to manually regenerate the section after changes to the building model. • It is impossible to see parts of an underlying floor level inside a void or through an opening in the floor, such as the lower part of a staircase, when working in a Construct. Placing them as Elements on several floor levels does not construct a correct building model in the elevations, sections and perspective views. When the user wants to draw using a lower level as an overlay, it needs to be referenced into the active Construct. Alternatively, an additional Element, such as a graphical column grid, can be defined and referenced in all Constructs. But then it also appears in all views, which might not be the intention. • Only since the release of ADT 2006, it has become possible to eliminate the horizontal lines between floor levels in sections and elevations. When walls on different levels and thus inside different files connect, they are merged according to their used materials. Graphisoft ArchiCAD The digital building in ArchiCAD is constructed floor by floor. It is possible to split larger projects in seperate files, but there is a real relation between the different floor levels. The plan view in ArchiCAD is a 2D window, which displays one particular floor level at a time. When the user opens a 3D window, the full building model can be displayed. There are seperate views to display sections and elevations. It is also possible to generate detail views from the main building, which can be annotated if required. An important design aid is the Ghost Story, which enables any chosen story to be visible in a greyed out display mode on the other levels. It can also be set to always display one level below the active floor level. Building elements, such as stairs and floors can be shown on other levels than the one on which they are created. This display can be context sensitive, so the

136

Chapter 5. The Data Structure

symbol display of a stair can be different on another level. This allows to model the element only once, on the relevant level, but have it influence the drawing on other levels, when required. Walls can also extend over several floor levels, which was not possible in versions before release 10, but this also poses new problems. The problems are mainly related to the fact that the 2D drawing is usually not a cut through the 3D model, but is a symbolic representation. It is not possible to show several floor levels or several 3D views at the same time, but when defining a plotting or printing layout, it is of course possible to assemble any combination of views and drawings on one or more sheets. The Virtual Trace system from ArchiCAD 11, however, improves the possibilities of making cross references. A user can choose to display views inside other views. It enables to display a facade next to the floorplan or a section next to a section view. This helps the designer to check consistency in the design and to control the alignment and the position of elements from views that would otherwise not be visible at the same time. The floor level system of ArchiCAD is easier to use than that of ADT and the overview over different levels is better, but it has other limitations. Even though the whole system is organized around these floor levels, there is no direct support for split levels. Changing floor levels is also possible, but the building elements are not automatically adjusted when a floor height is modified. Their position is corrected, but the height of a wall stays fixed. Autodesk Revit Revit uses an approach that seems similar to ArchiCAD at first sight. The Project is divided in separate floor levels and building elements are drawn level by level, but there are important conceptual differences. Walls can also extend over any combination of levels but their base and top are actually connected to floor level lines, which allows them to adapt when these floor levels are modified. The positioning of windows and doors inside walls relates them to a particular level. The whole model is not really split, but the floor levels are used as reference levels. Even then, the 2D view is a conceptual drawing, only displaying the openings and element that are visible on that level. The system provides a good balance between modeling freedom and clean drawings that follow architectural graphics conventions. It is also possible to align elements on different floor levels to each other and this alignment becomes a permanent constraint.

Conclusion Is there an approach that is both flexible and logical? There is no single solution that performs best for all desired scenarios. When the building is regarded from

5.5 Layers in a digital building model

137

the facade, it makes sense to model the exterior walls as continuous elements, spanning multiple floor levels. But the same building when looked from the inside, might be better structured when subdividing the walls floor by floor. And even if the elements are split, the elevations need to be displayed as continuous elements and load bearing walls need to be aligned over several floor levels. At the same time, regardless of the chosen approach, the positioning of windows and doors is typically done with regard to a particular floor level, since that defines the height of sills and thresholds. Lightweight separation walls are placed floor by floor and independent of the placing on other infill walls. At the same time, a continuous wall will be adjacent to several spaces. If the designer starts modifying spaces on a specific floor level, the coherence of the structural design should not be disrupted. The CORE Object Model provided an approach of subdividing walls by their finishes, using Surfaces, which can be linked to Spaces with a Surface Finish Link. This is a possible approach to have continuous space dividing elements, such as walls and floors, which keep the connection space by space using their finishing. Another approach is having the complete finishing information stored inside the Space object, since that is how it is usually managed by the architect. But this conflicts with the earlier statement that Spaces are by definition immaterial and bear no material or other physical entities. This is a motivation to insist on using the Surfaces to store this information, allowing them to be real physical entities, which link to Spaces for a coherent Spatial model.

5.5

Layers in a digital building model

Do we need the almost obligatory Layers? Layers1 can be regarded as sheets of calque, which are placed over a drawing. In CAD, layers act as a structural subdivision of the project data. They have been, for a long time, the only way to structure a CAD drawing. In a drawing environment, a line might represent a wall, the edge of a floor slab or a ventilation duct, based on its graphical properties. These graphical properties are managed by placing drawing entities on layers or by setting the graphical properties on an object-by-object basis. However, it is a common approach to define most graphical attributes as being derived from the layer on which an object is placed. This usually ensures better drawing integrity and the visual properties can be globally altered, instead of on individual drawing entities. Entities on different layers obtain different meaning. This has been and still is the most widely used approach to embed information about a project in a drawing. The graphical attributes of drawing entities are thus used both for visualization and drawing structuring. 1 Layers

or levels, as they are referred to in Bentley MicroStation.

138

Chapter 5. The Data Structure

Examples of the use of Layers In CAD drawings, it is common to use layers to give graphical entities a function. This can be the function of a building element, such as the layer for exterior walls or annotation functions, such as a dimension or text layer, sometimes divided into different output scales. Another example is using layers to make the distinction between different phases in a building project. The entities that exist and need to remain are thus separated from elements that need to be demolished and the new elements. Others use layers to make a distinction between floor levels, although it is even more common in 2D CAD drawings to draw floor levels, elevations and sections in juxtaposition, just like on the drawing board. A last approach is dividing the project into separate drawings, each following the same layer structure. Through referencing techniques, these separate drawings can still be grouped together as if they were part of the same drawing. This is the XRef or External Reference technique in AutoCAD or the Modules in ArchiCAD2 . The application Autodesk Architectural Desktop has features to define a Layer Standard so it is possible to configure the system to conform to the ISO standard, as discussed further on. The Layer Key Style enables automatic assignment of layers to drawn elements and also provides filtering based on the different fields. It must also be said that this is a rather complex system. It is hard to set up, while architects often lack the time when projects are facing deadlines. In a large architectural practice, templates have to be maintained by the CAD manager or the IT staff, to force their use when many people might work on the same project. Even then, it does not prevent a drawing to use two layer standards interleaved, which leads to unstructured drawings. Experience teaching ADT to architectural students, has witnessed several occasions where students used the default ADT templates for some drawingsâ&#x20AC;&#x201D;especially when starting a new drawingâ&#x20AC;&#x201D;and the prepared templates provided by the teacher for other drawings. The element styles were set up correctly, but the placement of elements happened using another layer key, which undermines the whole drawing structure. The CAD application Nemetschek VectorWorks provides a partial improvement to structuring drawings by not only supporting layers but also classes which give one additional and independent attribute to store properties. This diminishes the total amount of required layers in the application, but it has another, rather unexpected, result. Classes are often used as layers in other software and layers as used to define floor levels, when constructing a 3D model. When exchanging VectorWorks drawings with other CAD applications, usually through DWG or DXF files, it is common to translate these classes into DWG layers and ignore the VectorWorks layers. The Dutch CAAD application Arkey also adds additional properties, giving the mostly drawing oriented application more structure. This diminishes the required amount of layers considerably. 2 ArchiCAD

actually supports both modules and XRefâ&#x20AC;&#x2122;s.

5.5 Layers in a digital building model

139

As a last example, Autodesk Revit effectively works without layers, but relies on element attributes instead. When the user exports DWG files, to exchange data with other parties, layers are generated, based on these attributes. This illustrates the possibility to remove layers in BIM software, provided the building model and the design entities have enough structure. The ISO Layer standard Because of the importance of layers in CAD, they have become the natural way of exchanging information about a design. This has lead to the ISO 13657 Layer standard [BLK97]3 . The standard describes the naming convention to be used for layers in CAD software. This is displayed in Figure 5.5. Several properties can be distinguished from the layer name, such as discipline, building phase and function. The function of the element is probably the most important property to set, when assigning a layer to the element. A layer name is thus a set of attributes which all entities on that layer have in common.

Figure 5.5: Illustration of layer naming convention from ISO 13657

How to manage projects without using layers? A critical look at layers and why they are used can be helpful. Layers are nothing but an index into a long list of properties. When adhering to the ISO standard, drawings need to include large amounts of layers, which makes it very hard for the user to keep an overview. To assign a single property, such as the function of the element, the user has to choose an appropriate layer and thus choosing all other properties as well. With layers, all properties of an entity are set at once. The major problem is the usually large amount of layers, which makes it difficult for the user to choose an appropriate layer for a particular drawing entity and which increases the chance of mistakes. Even though CAD applications provide control methods, to lessen the chance of elements ending up on the wrong layer, the user can still place drawing entities on a wrong layer, willfully or by accident. This leads to errors and misinterpretations. A line that is meant to represent a wall, but that is placed on the layer of electrical appliances makes no sense in the digital building model, yet can be easily overlooked by users. Even the 3

http://www.itcon.org/1997/2/paper.htm

140

Chapter 5. The Data Structure

use of colors and line types does not prevent such mistakes. While professionals are usually able to interpret such drawings correctly, there is an evolution to automatic drawing interpretation, which will increase the chance of errors when drawings are interpret automatically, without human intervention. The major advantage of layers is providing metadata for elements. The ISO standard clearly defines several lists of important properties, but combines them all in one code, which is the layer name. The approach that is chosen in the data structure, with regard to layers, is to separate these metadata as actual attributes that belong to building elements. Instead of placing an element on a specific layer and consequently giving it a property such as phase01 floor02 wall exterior, its attributes are defined separately. A wall object receives the exterior type, is assigned to building phase 01 and is put on the second floor. In both cases, the same information is stored, but in a more operational way. With real attributes, selections can be filtered or elements can be queried based on their real properties. It could be argued that sophisticated string-search methods could derive all this information about elements from the layer-names, but it seems better to give the elements these properties directly, instead of relying on complex and error-prone queries. When all the suggested parts of the layer names from the ISO standard become actual element properties, layers are not required anymore. A minor benefit in the use of Layers, is the simplicity of assigning them to elements. The user selects the desired elements and then selects or re-selects the correct layer in a listbox. The directness of this operation should not be underestimated, because complexity is what usually causes errors. Users often forget to set the current layer, prior to drawing an element, which is not always easy to see on a computer screen. Once some of the drawing entities end up on a wrong layer, the whole system falls down and the drawing or the building model becomes unreliable. Coloring, line weights and line types help to distinguish the assigned elements and temporarily hiding and showing layers can help discover errors, but these seemingly simple operations are almost impossible to perform once the layer count reaches real world layer scheme sizes. It is not unlikely to have drawings with more than 100 layers and cleaning up a wrongfully structured drawing might take almost as long as drawing it again from scratch. If output documents need to be compatible with existing CAD applications, it is an almost trivial task to derive a layer name from the building elementâ&#x20AC;&#x2122;s properties. Such a system can even support multiple layer standards with the same building elements. This is yet another advantage of a structured building information model.

5.6

Classification & BB/SfB

The choice of building elements and their hierarchical logic in the CORE Object model is based on the specifications of the BB/SfB classification system [DNHS90]. This provides a classification for all common building elements.

5.6 Classification & BB/SfB

141

This system is the Belgian translation of the CI/SfB [RJC76, CIB86] and is managed by Professor Frank De Troyer 4 . It is a generic approach to structure building data. These specifications describe a method to classify building products, activities and building elements with a code.

Figure 5.6: The BB/SfB Logo, depicting different fields This code is built as four fields, which are actually the translation of codes from five tables (Figure 5.7).

Built Parts & Building Parts

Building Process

Built Parts

Elements

Materials

Process

according to building program

according to function

according to form and material

- management - material - activities Characteristics Performance Requirements

Table 0

Table 1

Table 2 & 3

Table 4

Figure 5.7: Five tables translate into four fields Based on the BB/SfB system, it is possible to write a hierarchic representation of common building elements, as will be shown in Figure 12.9 in Section 12.9. This is an extended version of Figure 5.3. One advantage of using this classification mechanism is that every single element receives administrative information, such as class, function or category, by specifying its building code. This frees the designer from the need of maintaining a layer-mechanism or a very rigid class structure and gives the application the possibility to filter the elements to make selections or when generating a representation. 4

http://www2.asro.kuleuven.be/asro/english/home/FDT

142

Chapter 5. The Data Structure

A disadvantage of this classification mechanism is that some objects could be classified in more than one way. By automating most of the code assignments, a design application can try to avoid ambiguous coding. Since the classification functionality exists for every building element, the system has to know little about the implementation of the specific classes to be able to manage them. Based on their classification code elements can be filtered for representations or selections. In the discussion about layers, in Section 5.5 on page 137, the extraction of layer information based on the classification code was already discussed. The conclusion was to leave layers out of the data structure and only introduce them in the export process.

5.7

Conclusion

This concludes the main overview of the data structure. This Chapter explained which elements are contained in a building project and how they are related. Some key concepts in common CAD and BIM applications were also discussed to explain their use and how they are managed in this data structure.

Chapter 6

Representation of building information Introduction A two-dimensional plan and a 3D model are both insufficient to fully represent a digital building model. They are both valid representations of the underlying model, but can not completely cover all the information such a model can capture. The building model, which is managed by the designer, does not have an unambiguous and complete representation. Both a 2D drawing and a 3D model can be derived from a building model, but they also form the two most important access points to that model. Working on a design happens mostly in a graphical form, through drawing or modeling. These two representations form an interface to the model. The designer interacts with the building model through these interfaces. It is a goal for any BIM application that the different representations of the underlying model are at all times coherent. Some applications clearly mark certain representations as being derived from the model and thus read only. Should the user which to edit these representations with regular drafting techniques, it becomes a drawing which is unconnected to the model. Other solutions, however, manage to make all representations equally important and interactive. The user can freely choose in which representation to create elements or to modify existing elements and all other representations will adapt automatically. In fact, each modification occurs through the underlying building database and all representations are regenerated from the single building model. This is an important distinction with traditional CAD software, where drawings and models are created directly. The correlation between different views in such an approach is not maintained by the application but by the user. This Chapter will first explain Representations and their limitations in BIM software. The next step will be an overview of representation types and their differences. Finally, the chosen approach in the data structure is explained. 143

144

6.1

Chapter 6. Representation of building information

Representational limitations in BIM Applications

There are several commercial BIM applications available. This Section tries to focus on conceptual differences and on current limitations in these applications. It is then easier to position the research efforts of the data structure and present possible solutions for some of these limitations.

Autodesk Architectural Desktop (ADT) At the core of ADT lies the Display System, where the different AEC Objects have different available representations. These AEC Objects, which comprise all architectural entities that ADT adds to regular AutoCAD, are parametric objects. They have components or subparts. These components can have several properties and can reference materials. Depending on the chosen representation, these components will generate common AutoCAD drawing entities, such as lines, hatches and solids, and place them on a particular drawing layer. A Display Configuration defines the characteristics of a certain representation, such as the drawing scale or the view type. The representation of AEC objects thus depends on the active Display Configuration, the current View Direction and also the chosen Display Scale. This Display Configuration can be directly chosen in a viewport. Examples of default Display Configurations include High Detail, Low Detail, Presentation and Screened. On the global level, there are different Display Representation Sets. They define which representation of a specific AEC Object should be used for a particular Display Configuration. This can be used to filter the display of objects, allowing them to be hidden if required. The management of all the Display Configurations and Display Representation Sets is handled by the Display Manager, displayed in Figure 6.1. As an example of the use of the Display Manager, the wall AEC Object will be configured. At the object level, this type of object has predefined Display Representations, such as Graph, Model, Plan and Plan High Detail. Within the Display Manager, the Display Representation of the AEC object will be connected to particular Display Representation Sets. As such, for the wall example, in the Plan Set, only the Display Representation â&#x20AC;&#x153;Planâ&#x20AC;? of the wall is made visible. Most AEC Objects have a Plan and Model Display Representation, while only some objects have a Graph Display Representation1 . These Display Representation Sets are then connected to a particular View Direction in a Display Configuration, so the Top View Direction in this configuration will display the Plan Representation Set, while the different Side View Directions will display the Section Elev Set. The Default View Direction, which is used by all 3D views, will call the Model Set. 1 It is thus perfectly possible to configure the system to display the 3D model of the wall in a Plan Display Configuration.

6.1 Representational limitations in BIM Applications

145

Figure 6.1: Display Manager in ADT At the same time, AEC Objects carry global and local Display Styles. The default, global Display Style defines which parts of the object to show, called the components, and with which graphical settings, such as layer, color and linetype. Particular Display Styles can override the global style and adapt it. This is used to let individual styles control how all AEC Objects that share this style will be displayed. The management of the available Display Styles is handled by the Style Manager, shown in Figure 6.2. Different Styles will have to be defined for the project. They can be set up in template files or imported from other files with the Style Manager. Continuing the example of the wall, the user can define a new Wall Style, which inherits the global Display Style. The user can then override the style for the different Display Representations. This will typically involve at least an override of the Display Style for the Plan Display Representation. The different components, which are defined and configured in the Wall Style, have to receive Display Properties. Components include the linework and hatching for the different available composing layers of the wall, but also cut geometry, for the geometry above and below the cut plane. Some components are only available in the Plan Display Representations, while others are dedicated to the Model Display Representations. When the user overrides the Style for a particular Display Representation, such as Plan, the Display Properties of the different components can then be configured. This is shown in Figure 6.3. These Display Properties define all visual output properties for the components, such as visibility, layer, color and linetype. It is also possible to link components to materials, in which case the other settings are invalidated and the Display

146

Chapter 6. Representation of building information

Figure 6.2: Style Manager in ADT

Figure 6.3: Display Properties for a particular Wall Style Override in ADT

6.1 Representational limitations in BIM Applications

147

Properties of the Material are inherited. A common configuration would be to define the components to be displayed in a Plan Representation with layers, setting the color and the linetype to the â&#x20AC;&#x153;ByLayerâ&#x20AC;? setting, while at the same time setting the components to be displayed in a Model Representation to inherit the Display Properties from the assigned material. The wall will thus reflect the used materials in the 3D views and use common hatching in the plan view. This is illustrated in Figure 6.4.

Figure 6.4: Display Representations for a particular Wall Style in ADT With the Display System and the required styles set up, which can take a considerable effort for the user or the local distributor, the actual modeling and drafting can begin. ADT relies on common AutoCAD techniques for drafting work, including the use of layers, XRefs 2 and Layouts. The layouts are also known as Paper Space, which is an environment for the layout of plot sheets, in contrast to Model Space, where all actual drawing and modeling occurs3 . To define the overall configuration of a building project, including information about floor levels, ADT provides the Project Navigator, where the full design is prepared. See Table 6.1. At the Project level, floor levels and divisions are defined. The former define horizontal subdivisions while the latter provide vertical subdivisions. These Floor Levels, however, only define a reference elevation height. They are used when assembling other drawings, to define their vertical position. The actual building elements, which belong to these floor levels, are drawn in Constructs and Elements. Constructs and Elements are drawings with building elements and graphical entities. Any architectural object from ADT and any 2 External drawings are referenced in other drawings. An assembly of drawings can be made without duplicating drawing content. 3 Although many AutoCAD and ADT users ignore Paper Space and finish all drawings exclusively in Model Space.

148

Chapter 6. Representation of building information

Table 6.1: Project Structure in ADT Part of Project Project • Building Model • Reports Constructs • assigned to level and optional division

Contains

Defines

• Elements > Constructs > Views > Sheets • Levels and Divisions

Levels Divisions

• Building Objects

• Referenced Elements (preferably no constructs) Views • general • detail • section/elevation Sheets • sheet drawing • sheet • sheet view • sheet sets

• referenced constructs (elements need to be inside constructs) • annotation (tags, schedules, dimensions)

• Construct Hierarchy

• referenced views • annotation (title blocks, tags, schedules, dimensions)

• full plot layout • title blocks • drawing numbering

6.1 Representational limitations in BIM Applications

149

graphical entity from AutoCAD can be used. The difference between Constructs and Elements is the notion of uniqueness. Each construct is only used once in the full design. This can be a complete floor level or a part of the building that is unique, such as a staircase or a facade. Elements are parts of the building that can be repeated identically, such as a standard office layout or a nursing unit in a hospital. It can even be a full floor level of a high-rise building, provided it is repeated identically on several places. Constructs can contain or reference Elements, but not vice-versa. They are also linked to a certain floor level. Views define the next level in the project structure. A Viewâ&#x20AC;&#x201D;at least in the ADT terminologyâ&#x20AC;&#x201D;is a new drawing, which references Constructs and possibly Elements and which can also contain additional architectural and graphical entities. It is usually not meant to host new building entities, but administrative entities, such as annotation, dimensioning, text, building sections, labels and schedule tables. A View defines a Scale Level and sets a specific Display Configuration, forcing the referenced constructs to be represented specifically. When a view is defined for a specific plan representation, it references all Constructs and Elements on a chosen floor level, but also defines a display scale, which influences the generated graphical representation of most building entities. A plan view defines a Top viewing direction, which enables the 2D representation for these building entities. If the user creates a model view, on the other hand, the Constructs and Elements of several floor levels might be referenced, also for a certain display scale, but now for an isometric or elevation view. It is only in such a view that the full building model is assembled. When the user needs to define a building section, this has to be done from within the view, since the constructs for the individual floor levels do not have access to other floor levels. There is nothing preventing the user to place multiple floor levels in one drawing, but in that case there is no support to display individual floor levels, while hiding the others, unless they are placed inside blocks and then placed on a separate layer that can be hidden, but then the system is as complex as in the separated drawings. The full Project system is taken one step further through the definition of Layout Sheets, which are output pages for printing or plotting. On these Sheets, Views are referenced, which are already set up for a certain scale and display setting. Figure 6.5 displays how a layout sheet can contain references to views, which can contain references to constructs, which can contain references to elements.

Additional characteristics of the ADT system â&#x20AC;˘ A multi-layered wall4 is defined as a Wall Style, where the different layers, called components, can have their own material assignment, thickness, offset from the Baseline, but also possible vertical offsets from the top or bottom of the wall. 4 Floors

with multiple layers have only been introduced in the 2007 release.

150

Chapter 6. Representation of building information

Layout Sheet

viewLevel1

view3D

viewSection

constructLevel1

constructFacade

elementGrid

elementFacade

viewLevel2

constructLevel2

Figure 6.5: ADT Layout Sheet using references • ADT also features Multi-View Blocks, which extend the common blocks concept by grouping several blocks into one, providing a specific block depending on the view direction. Since release 2006 there are also Dynamic Blocks which for the first time allow a more parametric behavior of blocks during scaling. Before this release, blocks could only contain static geometry. • Sections and elevations can be derived from the 3D Model. A section can be regenerated after modifications, allowing synchronization between model and drawings. • ADT lacks real floor levels, but uses the XRef technique in the Project Navigator. The biggest disadvantage is the lack of connections over different floor levels. This problem is slightly improved by the possibility of editing a reference “in-place”, so changes can be made while having other drawings directly available as a reference. This is apparent when an elevation is generated, since the lines between walls on different floors are still visible. This is improved in ADT 2006 and newer versions, where volumes can be merged in the generated drawing if they connect and use the same material. Prior to this release, elevations were not of an acceptable output quality without manual corrections in the generated drawings. The overall complexity of the ADT system cannot be underestimated. This can be illustrated by the realisation that many ADT customers configure it to work as generic AutoCAD and mainly use it to make 2D drawings without applying the full potential of building information modeling. This realisation was confirmed by a local reseller and it is also a common request in online forums and newsgroups, where ADT users demand how to launch ADT as plain AutoCAD

6.1 Representational limitations in BIM Applications

151

. Autodesk has listened to this requests, since recent installations of ADT place a shortcut to launch the software in this plain AutoCAD configuration. Graphisoft ArchiCAD The main interface is a 2D drawing, which is shown floor by floor. Most modeling happens by placing building elements in this plan view, but at the same time, the full 3D building model is automatically created. At any time, the user can open the 3D window and continue working in that environment. Changes all happen through the building elements, regardless of the active view type. Sections, elevations and 3D views are automatically regenerated, although there is the option of breaking the link between a generated drawing and the model, but this violates the main BIM concept. • Wall connections are cleaned up when the baseline of walls connect. To connect multi-layered walls, priorities can be set up, giving control over which elements to split to let other layers pass through. This is illustrated in section 7.4.3 on page 204. • Symbols are Library Elements in ArchiCAD, which are parametric objects. They are usually script based, so they can be regenerated at any time. The script does not contain actual geometry but creates it using the Geometric Description Language or GDL [NC00]. Such a script can contain parameters, so the same script can be used to generate a wide range of possible variations. Scripts make the distinction between 2D and 3D, so the plan representation of a library element can be a symbolic graphic and at the same time be represented as a full 3D object in the 3D view. An ArchiCAD project contains a reference to the library object—which is stored as an external file—and to the values of the parameters. This allows the library to be updated, reflecting changes in all projects that reference these elements. Library objects are thus shared between projects. • A section or an elevation is derived from the 3D model and is updated automatically. It can be enhanced with additional 2D line work or annotation, which has no connection with the 3D model. Based on the used materials, elements can be merged in these drawings, allowing for clean drawings with much less requirement for additional drafting. This is important, since the user would otherwise have to remove these lines from elevation drawings. • Walls, floors and roofs can have multiple material layers, which are shown in the 2D views, when elements are cut. The 3D model still displays them as one layer. There is no possibility of offsetting edges of individual layers inside such a composition. 5

html

http://knowingwhatyoudontknow.blogspot.com/2006/06/state-of-architectural-world.

152

Chapter 6. Representation of building information To correctly connect different elements, priorities are set, which define how intersecting layers make room for layers with a higher priority.

• Solid Element Operators (SEO) have been added since ArchiCAD 8 which allow for a form of parametric behavior between elements. Using SEO, a floor slab can create a real cut through a wall or a wall can be trimmed by a roof, allowing for cleaner drawings and correct volume measurements. Since these operators are parametric, they are updated when the elements are modified. This was not possible with other modeling tools such as the direct trimming of walls with roofs, which did not contain an actual connection between these elements. The representation model of ArchiCAD is pretty complete, but connections or relations between elements are almost non-existent, apart from intersection cleanup and the Solid Element Operators. Scripted entities, in particular, live in a vacuum in ArchiCAD. They have no connection with other entities and can thus not influence other objects. They can take the scale of the view into account, allowing for simplified representations on a rough scale, while displaying more detail on smaller scales. This is comparable to the concept of the “Intelligent Zoom” , as discussed in [Neu92]. The script of these objects is rerun whenever the object has been modified, or whenever one of the global parameters on which they depend is modified. It is also possible to make new parameters available, when certain parameters are toggled on, e.g. the settings for a sill or tablet are only available when a window effectively enables this option. Navigation inside ArchiCAD. ArchiCAD provides several hierarchic navigation windows. They are grouped in the Navigator window and in the Organizer, which will be discussed in the following paragraphs, but there are hierarchies in several other places. The Navigator is displayed at the right side of Figure 6.6. The Organizer is an extended version of this dialog, displaying two hierarchic views together, to help the user in organizing the different output documents. This is shown in Figures 6.7 and 6.8. Both the Navigator and the Organizer provide four ways to display the structure of an ArchiCAD project. Project Map displays the different available representations, containing stories, sections/elevations, details, 3D, element schedules, project indexes, lists, info and help. Some of them can be seen at the left side of Figure 6.7. View Map displays the different defined views 6 , which is not the same as the Project Map. The user defines views by choosing display settings, a layer combination 7 , dimension settings and a representation scale. The user can 6 This

is the term ArchiCAD uses. snapshot of which layers are visible. One project contains one set of layers, but multiple layer combinations. 7A

6.1 Representational limitations in BIM Applications

153

Figure 6.6: The Navigator in ArchiCAD define a custom hierarchy by creating folders and grouping views in certain folders. There are some preset folders, which have additional properties. The amount of levels is not limited, but by default there is one for the folders and one for the views. This is shown in Figure 6.7. Layout Book shows output sheets 8 . The Layout Book, displayed in Figure 6.8, contains layouts, which in their turn contain sheets or groups of sheets. Each sheet can contain multiple drawings. The drawings reference the views or they reference external documents in different formats. The same hierarchy also contains sheet masters, which are stored page configurations for different sheet sizes or with different colophons. Publisher Sets display a complete set of output documents, defined from the layouts or directly from views. With this window, the user can define one or more documents to be published in one operation. This can be in the form of plotted sheets, a multi-page PDF document or a set of drawing files, possibly as a hierarchical interactive web site. One project often contains multiple Publishing Sets. An example is shown in Figure 6.8. There are other hierarchies available, notably when defining schedules or when adjusting properties of elements. There is no single building hierarchy however, apart from the division of the building model into stories. Before release 10, the building model was strictly divided into stories, where each element was placed 8 Since ArchiCAD 10, the functionality of the former standalone PlotMaker application is integrated inside the main ArchiCAD application.

154

Chapter 6. Representation of building information

Figure 6.7: Project Map and View Map in ArchiCAD

Figure 6.8: Layout Book and Publisher Sets in ArchiCAD

6.1 Representational limitations in BIM Applications

155

on a certain story and its visibility was dependent on its home story, although elements could be visible on other stories. Since release 10, elements can be represented over different stories in a more flexible way. Autodesk Revit In Revit, every single view is a representation of the building data. 2D Drawings, sections, elevations, plot layouts and 3D views are all directly connected to the building model. This is also true for schedules. Relations between elements are enabled through the constraint system. Alignments, offsets and distributions are not only drawing aids, but can be embedded in the drawing, usually by enabling a lock on temporary dimensions. The model can actually be updated through editing these dimensions. This system follows the concept of parametric modeling applications from the Mechanical field. Every modification automatically updates all related representations. In Revit, the Project View as illustrated in Figure 6.9 is shown by default. This view displays all different available representations inside the project. They contain stories, elevations, 3D views, sections, lists, families and output sheets. This preset and fixed set of top-levels divides the project according to the different representation types. Underneath each type, all available views are automatically added. To switch between representations, the user needs to go through this treeview.

Figure 6.9: Project View in Autodesk Revit

156

6.2

Chapter 6. Representation of building information

Overview and definition of representation types

This Section gives an overview of different types of representation that are relevant in architectural design applications.

6.2.1

2D Plan representation

Properties of a 2D Plan representation Traditionally, a 2D drawing is the default means of communicating between the designer, the client, the authorities and the contractor. Even though more and more design software allows the designer to work in 3D, the design often starts and ends with 2D information. A typical example is the inevitable napkin sketch, be it in a digital form or not, that is elaborated into technical drawings for the realization on site and, depending on the building program, for the management afterwards. In Belgium, the WTCB 9 provides a report with an overview of Graphical Symbols for use in Building documentation [WTC98]. Other countries have similar standards, such as the National CAD Standard (NCS) in the USA, but no world wide graphical conventions exist. Even though a plan representation is, by definition, looking down from a slice through the building on eye-level, we cannot simple slice through a 3D model and assume that this will suffice. An example from a traditional 2D drawing is shown in Figure 6.1010 . • Elements that are visible underneath the eye-level are shown, using a thin line. The section of elements is drawn with a thick, continuous line. The section is enhanced using hatched or shaded contours. • Some of the elements which are invisible from the section will be represented as well. Examples include a beam above the current floor level or the contours of a roof window, a floor opening or other bigger structures. The contours of the part of a stair that extends above the section plane is usually drawn. For all invisible elements, a thin dashed line type is typically applied. • Many items are shown symbolically or the graphical representation is enhanced with additional graphics. This can be the opening line of a window or a door, arrows clarifying moving parts or conventional symbols such as slope directions and connectivity information, e.g. for electrical appliances. 9 “Wetenschappelijk en Technisch Centrum voor het Bouwbedrijf” or the Belgian Building Research Institute 10 Architect: Pascal Van Dooren, Belgium, 1997

6.2 Overview and definition of representation types

157

Figure 6.10: Extract from a 2D plan drawing â&#x20AC;˘ Some elements are only represented symbolically. Not only to allow faster drawing, but more importantly for a more legible document. Examples include sanitary installations, Heating Ventilation and Air Conditioning (HVAC) components, electrical installations, furniture and also most doors and windows. Representing these objects with more details distracts from the drawing and does not add additional information that is required at this point. In fact, most information about these elements can not be found on the drawings at all. The main dimensions are shown, but the other data can only be retrieved in the bill of materials. â&#x20AC;˘ Most annotation is extremely important for the drawing, but is only symbolic or textual, such as dimension lines, text labels, height levels or references to other drawings. Labels are sometimes attached to other entities, providing additional information, such as notes or construction instructions. â&#x20AC;˘ There are several elements that are simply not shown in a drawing: most sills, thresholds, curtains and other accessories are usually only visible in detail-drawings or in the textual information, but they are still necessary in all quantity and cost estimations. A 2D drawing is thus a conventional representation of the reality. Vertical sections and elevations are interpreted in a similar way. They are partly derived as a projection or a slice through the building volume, but retain a substantial amount of symbolic and textual information. Before a more recent

158

Chapter 6. Representation of building information

widespread use of color in printing or plotting, most material information was only visible in the form of hatching and annotation. Historic drawings contain even less technical or detailed information. The drawing served as a mental preparation for the master-builder, who managed most of the process in person, on site. The main goal of a 2D drawing is passing on accurate11 information. Advantages of a 2D representation Even though there is a tendency to prefer 3D solutions over 2D solutions in current research and applications, the advantages of a 2D Representation should not be neglected. • The act of drawing closely mimics the traditional design activities on paper, from the drawing board, when compared with 3D modeling. • The designer is directly creating the output document and has total control over the amount of detail, the representation conventions and the symbols used. • These are still the common documents for requesting a building permit or even to ask a quote from a contractor for a price. • Even with the rise of digital communication, most document exchange in a building process is still paper-based. Projects that are managed digitally, using online project management platforms are still the exception. Apart from the drafting qualities of a 2D representation, there is also the importance of the architectural sketch, which has been and still is mainly a 2D effort. Different research projects prove that there is still academic interest in developing approaches to combine manual drafting and sketching in a digital context. Good examples are EsQUIsE [JL04], which uses video capturing to interpret sketches, and the work of Maher [MBG+ 06] where a 2D sketch environment is augmented by a 3D world. Problems with a 2D representation However, a 2D Representation is not without problems. . . • The 2D drawing does not contain sufficient information to fully describe a 3D building. Certain corners or details are simply not visible in floor plans, sections or reversed ceiling plans. • It is extremely difficult and error-prone to derive 3D information from 2D drawings. Most element connections cannot be solved automatically. Even when a drawing is accompanied with detail drawings, a 2D drawing needs interpretation and thus possible misinterpretation. 11 A drawing is quite inaccurate. The small size and the printing or copying process results in deformations and a lack of accuracy. People are not supposed to measure a dimension on a drawing. The dimensions are either read or calculated from other known dimensions.

6.2 Overview and definition of representation types

159

â&#x20AC;˘ It is difficult to represent freeform building elements in a 2D drawing. Some simple curves can be accurately described in 2D provided the curved surface is parallel to the drawing plane. Double curved surfaces are not represented correctly at all in a flat drawing. That said, most building projects are mainly orthogonal and can be represented quite complete with pure 2D documents. Most buildings have been and are still built without any form of 3D representation at all. Even though each building is per definition 3D, many architect successfully continue using traditional 2D techniques for design and communication. Sections which are drafted are often using the elevations and floor plans as references, to ensure that elements are positioned correctly in all drawings. While there is not actual 3D model created in this process, the architect mentally manages the actual building and merely translates this model into drawings. Figure 6.1112 displays a layout plan for a small residential project. The different elevations, some sections and the drawings for the floor levels are drawn with 2D drawing tools. No 3D model was used. However, this type of drawings is still widely used in current architectural practice.

Figure 6.11: 2D Drawing for a simple residential design As discussed earlier on, the studies of Maher [GM06, MBG+ 06] showed the value of both the 2D and 3D design methods. In these studies, the exploration of abstract design concepts motivated the use of 2D sketching techniques, whereas 3D was more used for the elaboration of these concepts. 12 Architect:

Pascal Van Dooren, Belgium (1997)

160

Chapter 6. Representation of building information

It is safe to conclude that 2D methods and representations still have their place, both in the design process and in design communication. The necessity of most authorities to provide 2D documentation is not bound to be modified shortly. It is expected, though, that over time, the use of integrated digital building models will increase, aided by the evolving digital design applications.

6.2.2

3D Model representation

Properties of a 3D Model representation While most current buildings are documented using purely 2D drafting methods, it is beneficial to create the building as an actual 3D model. In that case, instead of drawing how the actual building would look when projected, geometry representing the building entities is created and positioned. A building will thus be represented using geometrical 3D objects. These are usually variations on prisms, boxes, extrusions and Boolean operations to create voids. Even though a building is technically speaking an assembly of physical objects, no digital model will include each and every single object from a real building. A 3D Model of a building is necessarily a simplification of the full building. Depending on the purpose of the 3D Model, the focus shifts from representations of the material surfaces, primarily for use in visualization, to the main volumes of common building elements for quantity calculations or simulations. Geometric Modeling It is quite common for CAD applications to utilize a solid modeling kernel, such as Spatial ACIS or UGS Parasolid . These kernels have extensive support for extrusions or sweeps and also Boolean operations, which are usually sufficient for the modeling of most building shapes. It is less common, however to have support for full freeform geometry, such as NURBS, in architectural CAD software. This is usually not a problematic limitation, since most buildings can be adequately described with flat and orthogonal geometry. Whenever an architect chooses a design with organic volumes or blobs, the project is usually modeled in other applications, such as McNeel Rhino or FormÂˇZ. Advantages of a 3D Model representation The physical building can be represented as an assembly of 3D volumes. This can be used to derive elevations and perspective views, by simply adjusting the viewpoint and camera projection. â&#x20AC;˘ Relative simple extraction of volumes and other quantities. â&#x20AC;˘ Deriving a section through the model can be easily done, using clipping planes 13 This can often be performed in realtime by modern graphics 13 Removing

all geometry that falls outside a certain viewing volume or frustum.

6.2 Overview and definition of representation types

161

hardware. However, clipping alone is insufficient to create the required graphical layout for use in architectural drafting. Cut geometry should be represented by a thick continuous line, while the clipped volumes are filled in, with hatches or solid regions. At the same time, non-clipped geometry is projected onto the clipping plane, using a thin line and using a hidden-line algorithm to hide all invisible edges. Whether transparent surfaces, such as glass, are displayed as opaque or not, is not predefined. In fact, the graphical creation of a 2D section or elevation has always been the result of graphical expertise, to display accurate information, but in a legible way. â&#x20AC;˘ Modern graphics hardware, combined with a reasonable amount of memory is sufficient to display these models fluently on CAD Workstations or even on a common PC or Macintosh. This can even include material properties, such as texture mapping and transparencies, usually through the support of OpenGL or Direct3D hardware acceleration.

Figure 6.12 displays a 3D model that has been used to generate a section. The part of the 3D model that is displayed in wire-frame is not shown in a 2D drawing, although some elements might have to be shown in the drawing as well.

Figure 6.12: Section through a 3D model to generate a plan

162

Chapter 6. Representation of building information

Problems of a 3D Model representation The main limitation is the need to model everything that should be visible or extracted from the model. • The model has a limited level of detail, which is usually fixed. Stepping through a more detailed building phase can require the remodeling of the complete building. This immediately suggests the need for a parametric generation of building model geometry. • Deriving operational 2D drawings from a 3D model is not trivial. It is simple to clip 3D volumes with a section plane and many programs support this even in realtime, using the graphics adapter’s support for clipping planes. But to generate an adequate architectural drawing requires either modeling additional geometry to generate the necessary 2D line work or requiring an additional and unconnected drawing stage. It is also not trivial to generate a plan representation which is not a direct projection of 3D geometry. • Even though the architect needs to add additional annotation and line work in a design, the 3D model is usually not built with this amount of detail. The construction detail is usually not modeled, but represented with an additional detail drawing. Many construction accessories are never modeled. Such a detail drawing is an informative scheme, used as an information source at the construction phase. This results in the absence of actual quantities of many construction components, although they might be estimated based on calculated volumes from fully modeled entities, using average ratio’s. • To make a full 3D model of a building, using a solid modeling kernel, requires a huge amount of data and thus computer memory to keep track of not only the geometry, but also the complete modeling hierarchy and modeling history. The largest hurdle is not the display of the final geometry but rather the constant modifications on the building model, requiring continuous regenerations of this geometry. It can be argued that for simulation or calculation purposes, there is still the possibility to derive quantities of missing geometry based on the dimensions of related elements, such as floor perimeters and wall lengths. This is apparent for wood skeleton constructions, where the architect designs walls as solid volumes, while they are in fact constructed as individual elements. Some CAD applications actually generate complete construction models from the general design model. The major limitation is probably the derivation of 2D drawings, as sections or projections from the 3D model, which requires the model to contain full geometry for every drawing element. In architectural practice, all 3D building models are further elaborated with additional 2D linework.

6.2 Overview and definition of representation types

6.2.3

163

Hierarchic representation

Introduction A Hierarchy represents a certain order and certain dependencies. Hierarchies can be found at multiple levels, from the organization structure of most countries and economies over classification systems to computer systems. This section will discuss the value of a hierarchic representation in the context of a digital building model. However, before discussing hierarchies in a building model, hierarchies in other applications are illustrated, to immediately understand some advantages and disadvantages of hierarchic representations.

Transformation stack in 3D Modeling Many 3D modeling applications have the concept of parenting. By assigning a parent element, the currently selected element becomes its child and it stays attached to the parent by a transformation stack. This local coordinate systemâ&#x20AC;&#x201D; usually a 4 Ă&#x2014; 4 transformation matrixâ&#x20AC;&#x201D;is expressed as a relative transformation with regard to the coordinate system of the parent. Elements which lack a parent will have their transformation expressed in the world coordinate system. This is apparent in two ways. When a parent is selected, its children become selected too and when the parent is transformed, the children get transformed as well. Such a hierarchy is extremely important in 3D modeling and animation. This can be easily illustrated with Figure 6.13, which displays the animation of a simple solar system, using Cinema4D. A few spheres represent the planets that orbit in a circular path around the central sun object. Instead of calculating the Cartesian coordinates of each element in turn, a transformation hierarchy is defined. The earth sphere becomes a child of the sun sphere and the moon sphere becomes a child of the earth sphere. When the sun is rotated, the earth will automatically rotate around it. When the earth is turned around, the moon will orbit around it. There are some things to consider to make it a little more realistic, but the concept is clear. The rotational position of elements is inhibited through a hierarchy of transformations. A second example are the hierarchic rotational movements of a skeleton, where the rotation of the upper arm causes the lower arm to rotate with it, which in its turn causes the wrist and the hand to follow along. Even when ignoring the complexities of a realistic moving skeleton, where both forward kinematics and backward or inverse kinematics and joint angle restrictions are taken into account14 , the importance of a hierarchic model is clarified. 14 The discussion of the concepts of character animation are far beyond the scope of this work, but they are supported by most 3D Animation applications. It would still be interesting to apply the concept of a control geometry, such as bones, to deform a geometrical representation of a building, for an exploration of freedom in building modeling.

164

Chapter 6. Representation of building information

Figure 6.13: A simplified hierarchic solar system, modeled in Maxon Cinema4D While both examples are used in the context of enabling more control over animation, a transformation stack is used in most CAD and 3D modeling applications, even in static scenes. When a building is positioned onto a terrain, it can be placed inside a hierarchy. The elements inside the building can also be placed as children underneath the room in which they reside. Most 3D software deliberately uses the term parenting, where elements are attached to a chosen parent. This creates the hierarchy. Similar techniques are used in mechanical and product modeling, where hierarchies are used when creating assemblies. Most parts inside a machine or complex product are not floating around in space, but are attached to other entities, using bolts, hinges or other connections. There is a very specific hierarchic order in their assembly. Headings and outline levels in a text processor When defining a document using a hierarchy of headings and paragraphs, a document receives structure. Even though most people do not apply the style feature in their word processing application, most applications support this approach. In such a document, a chapter could be the top-level distinction, followed by subchapters or subsections. This is apparent in LATEX[Lam94] documents or even in simple HTML documents, where the application of these style properties are usually enough to define a structured document. With both systems, the actual visual properties of the document are defined externally, in style documents or cascading style sheets (CSS-files) respectively.

6.2 Overview and definition of representation types

165

Figure 6.14: Displaying document structure in WinEdt editor The simple act of separating the document content from the style characteristics enables many automatic operations, from which formatting is only the first, but most visible one. In such a structured document, automatic numbering, automatic indexing and referencing become rather trivial tasks, freeing the user from manually maintaining the desired structure and thus obtaining consequent layout, with less chance of stylistic errors. An interface for a Hierarchy When we want to manage hierarchies in a software application, the usual GUI widget is the Tree-list, which is a list of possibly indented strings. The representation of a folder structure on a hard disk is the most commonly used hierarchic interface in most graphically oriented operating systems. The Windows Explorer (Figure 6.15) and the Mac OS Finder (Figure 6.16) display the content of a hard disk or even the whole computer in a hierarchic way, depending on the userâ&#x20AC;&#x2122;s display settings. The different folders on the different disks are shown as child nodes indented from their parent. No matter what operating system, be it the one and only root level in Linux or Unix or the â&#x20AC;&#x153;My Computerâ&#x20AC;? folder in MS Windows, with underlying disks and folders or any other combination, the inherent hierarchical organization of the disc structure is chosen as the interface for the user. That does not imply that a hierarchy is the best approach or the easiest concept to grasp by the user. Alan Cooper devotes an entire chapter in About Face [Coo95] [CR03] to hierarchic interfaces and compares their power for developers against the complexity for the end user. He mainly argues that deeply nested hierarchies often cause the user to loose the overview. Whenever the nested levels go too deep, users find it harder to find their way around such a system. This is quite noticeable in recent incarnations of the Windows or Macintosh

166

Chapter 6. Representation of building information

Figure 6.15: The Windows XP Explorer displaying the structure of a disk

Figure 6.16: The Mac OSX Finder displaying the structure of a disk

6.2 Overview and definition of representation types

167

Operating Systems, where the hierarchical view is still available, but hidden by default, as shown in Figures 6.15 and 6.16. Needless to say that this only helps when the user has no need to navigate through a large hierarchy, which is often a problem in the organization of a disk structure. Repeatedly clicking the UP button fails to give much insight into the underlying structure nor does it make the user find the correct place quickly. A hierarchy is thus a very usable and important method to display a structured organization, but its usability is inversely proportional to the amount of hierarchic levels. Displaying and hiding parts of a hierarchy Most systems that display content in a treelike view, allow the user to open or close certain nodes, by clicking a small icon in front of the text. This can be a plus or minus-sign, as seen in in Microsoft Windows and most Linux or UNIX Window managers, such as KDE 15 , Gnome 16 or others. In Mac OSX it is a triangle pointing right or down. This important feature makes a hierarchy manageable and diminishes the amount of elements to display, thus reducing scrolling. Rearranging a hierarchy Some applications allow the user to adjust the hierarchy by dragging and dropping nodes in the treeview directly, to place a child underneath a new parent. This is not a trivial operation, but its interface metaphor is so simple that it is immediately understandable for the user. A good example is the structured Objects view in Maxon Cinema4D. This is a 3D animation application, where the hierarchy represents not only the transformation stack, but also many other operations. Some operations are represented by nodes, for which the operandsâ&#x20AC;&#x201D;usually other elementsâ&#x20AC;&#x201D;are placed underneath the item. Others require the operator to be a child from the element on which the operation is applied. A child has only one parent A hierarchy can be rather complex. In most cases, hierarchies allow a child to only have one parent. This makes things easier to implement, easier to visualize and easier to manage by the user. But at the same time, this limits certain hierarchies completely. Imagine a hierarchic description of a building. In a naive first attempt, the building can be divided into stories, rooms can be placed onto the stories and building elements attached to the enclosure of the room. Even when ignoring 15 16

http://www.kde.org http://www.gnome.org

168

Chapter 6. Representation of building information

Figure 6.17: Hierarchic object structure in Maxon Cinema4D rooms that span several stories, such as an elevator shaft and ignoring splitlevels, there is still a major obstacle in the connection between the rooms and their enclosing elements. Walls can enclose many different rooms and floors might be part of one room above the element or be adjacent to several other rooms below the floor. In a real building, the building model can not be fully described as one tree-like hierarchy, where children have only one parent. When Alexander [Ale65, Ale65] concludes that â&#x20AC;&#x153;A city is not a tree17 â&#x20AC;? a similar reasoning occurs on the level of a single building. A mathematical treerepresentation assumes each child to only have one parent. However, as illustrated in the city diagrams, the different children have more complex relationships than being simply a part of an enclosing parent structure. Without these interconnections, they loose a part of their value and meaning. If rooms are only a part of the floor on which they reside, they can not be connected to the room above in a tree structure, while they might be related in the design. A hierarchic representation will not be the one and only way to represent a design for a building (or a city). This complicates the choice for a simple, usable hierarchic tree representation. Precisely for that reason, it might make sense to opt for a Winged Edge data structure18 where each enclosing element is split into half-size elements and both halves can be adjacent to different spaces. At first thought, a Winged Edge data structure might be the perfect candidate when modeling spaces and their enclosing elements. This advantage is countered 17 Partly incomplete, but visible on http://www.patternlanguage.com/archives/alexander1. htm and http://www.patternlanguage.com/archives/alexander2.htm 18 http://www.baumgart.org/winged-edge/winged-edge.html

6.2 Overview and definition of representation types

169

by the difficult navigation in such a structure. It implies that every wall, floor and other enclosing elements will be split up according to the space they connect with. [Kal89] describes the Hybrid Edge Model which is based on both the Winged Edge model from Baumgart and the Split Edge model from Eastman. It can be applied in geometric modeling with extended support for directional and adjacency information. An alternative solution, which was proposed in the CORE object model, is the availability of surfaces which will form a link between a physical element, such as a wall or a floor, and the space with which they connect. This surface element can contain the material properties that are appropriate for the finish of the planar element, that still contains the main construction information. This makes sense, since finishes of building elements are usually decided upon on a space-by-space basis. A hierarchy is never alone E-mail programs, word processors, CAD and 3D applications all display hierarchies in some way or another, but always in combination with other representations. Sometimes the hierarchy is only an entry into a major subdivision of the content, where additional views display other representations for the selected node in the main hierarchy, such as graphical, textual and iconic views. There are almost no applications for which the hierarchy is the only representation and this is not required either. This section motivates its importance, but will not assume that other representations can be omitted. The data structure that is developed in this doctoral research defines a property system which is hierarchic. Objects have properties and they can contain other objects. This implies a hierarchic object structure and is translated into hierarchic files, when the project is written to disk. It is thus logical that this hierarchy will be used in some way in the representation of the digital building model. However, as suggested in the previous discussion, the hierarchy is not a perfect tree. Objects can reference other objects and they can become dependent on other objects, even though they might belong to different objects. The hierarchic representation will only be able to be a partial representation of the building model. Applying a hierarchic representation to a building model In the context of building models, where the model serves as a spatial model, containing building blocks, floor levels and rooms, it seems appropriate to introduce a building hierarchy. The Scale Levels from the conceptual model are a hierarchical scheme of building entities, which are interconnected. In a traditional CAD system, it is usually possible to define hierarchies through the application of nested files and nested or grouped library elements. One file can host another file, which in its turn can host additional files. The referencing possibilities in CAD systems allow a nested stack of files.

170

Chapter 6. Representation of building information

At the same time, elements can be put in an assembly. This can be a group, for hierarchies that only occur once or in blocks or cells when multiple instances of the hierarchy are likely to be required. The nesting of groups or blocks presents a similar result as the transformation stack in a 3D animation system.

Project Masterplan Block 1 Space 1 Space 2 Space 3 Masterplan Block 2

Space 4 Space 5

Figure 6.18: Example Hierarchic Scheme Representation Some applications provide an interface to such a hierarchy. Google SketchUp introduced the Component Outliner in version 5 and Autodesk Maya has had an outline view for quite some time. In the interface to a building model, a similar approach can be followed, but there are different possibilities: • The different view types in the application can be defined as a hierarchy. To the user, all views are part of a hierarchic tree structure, where detailed or partial views can be located underneath an overview. They can be categorized according to the view type, to give additional structure. • The drawing output can be presented as a hierarchy. The assembly of a set of project drawings can be organized underneath entries for the different building phases. Each phase contains a set of plot sheets and each sheet can contain several drawings, pictures, tables and plot sheet annotation, such as a title block. • Last, but definitely not least, the building model itself can be organized in a hierarchy. One building project can be represented with several hierarchies, each focusing on different functionality aspects and requirements of the building project. In an example from a functional view on the project, the top level is the project, containing typically the elements from the Masterplan Scale Level, such as Masterplan Blocks and the Site. Each building block contains floor

6.2 Overview and definition of representation types

171

levels, which contain spaces or rooms. At the same time, the building block is realized with the common building elements, which enclose the spaces. Other possible hierarchies include structural and technical systems, such as power provision or sanitary equipment, which are often organized in a hierarchic structure. A hierarchic representation in the prototype The current implementation offers an automatic display of the digital building model, based on the hierarchic nature of the elaborated property system. The generic widget to display the properties of any entity in this system lends itself easily to a display using a tree structure. The whole building model can be displayed from the Project properties. This gives a tree filled with nodes containing the basic properties. For each property that is a list, such as the Elements or the Materials, the items in the list are displayed as children of the list. Should thise children contain additional lists, their children are displayed as well. However, the implementation faced additional practical problems. In the case of References, the referenced entity is displayed as well, sometimes leading to a recursive call of the display function. This had to be stopped, otherwise the application would end up in an infinite loop. The recursion depth of this display method had to be limited. That said, without any additional effort, this system will display the correct hierarchy at all times, as illustrated in Figure 6.19

Figure 6.19: Hierarchy in property panel Through the nature of the XML-based file format, this same hierarchy is also

172

Chapter 6. Representation of building information

present in the generated files when storing the project, as shown in the listing in the Appendices. Conclusion As illustrated in the application overview, most BIM applications usually provide a combination of hierarchies for view types and drawing output. To manage the set of output documents, most applications have a publishing workflow, where a set of sheets is assembled, which can store different drawings and other output results, such as listings. This is typically organized in a hierarchic dialog. But the hierarchical organization of the building model itself is usually lacking, or limited to a simple hierarchic structure of floor levels and sometimes zones to subdivide larger buildings.

6.2.4

Schematic representation

Concepts One of the visual schemes of particular interest for an architect is a diagram. Instead of making a graphical representation of elements according to their size, each element is represented by a block inside a diagram. The relations between elements can then be represented as lines or arrows between these blocks. A small set of block shapes, line types and arrow styles allows for a semantically rich representation of a potentially complex set of data elements. Even though this visual representation is a very valid, partial representation of a design, we see very little use of it in architectural CAD-software. In contrast, a schematic or diagram type of interfaces can be found in applications as varied as Microsoft Project and Visio, Demicron Wirefusion, Cycore Cult3D and most notable in 3D animation software. Applications such as Autodesk 3ds max and Maya, Softimage|XSI and SideFX Houdini all have a schematic representation as one of their view types, where all available relations between elements can be managed. An overview of these applications is given in Section 1.13 on page 63. Application to architectural software It makes sense to provide such a representation in an architectural design application, especially for the management of spaces. We might be interested in depicting the relations between spaces, combined with circulation and visibility in a schematic diagram. It would even be interesting to define the whole building program schematically, by defining a set of requirements and a proposal of a scheme, where the layout of the diagram allows to query the design with regard to adjacency, circulation schemes, visibility and connectivity. The main reason of the suggestion for a schematic building representation is the additional information it can provide to the user. Depicting relationships is by definition easy to do in a schematic representation, while it is at the same time rather difficult to

6.2 Overview and definition of representation types

173

manage in a mere 2D or 3D representation. You could draw lines to connect the 2D or 3D objects, but this will possibly confuse the user, rather than clarify the project structure. Use of colors and icons could partially represent relational information in such a graphic representation, but the inherent commodity of visualizing relationships in a schematic view makes it a preferable option. Building elements can be described as a combination of alphanumeric data and geometrical elements, but we should also take relations between building elements into account. Many elements are not independent entities and their characteristics depend on other elements. There are several types of dependencies in a building model. In [Hen00] the notion of existence dependency is explained, where the distinction is made between elements being completely dependent on other elements and elements having a relationship on a level of equality. It is also possible to describe geometric relationships, where connections, alignments, distributions and offsets can be defined between elements. Modifications in the relationships can modify the building model. A simple schematic representation of spatial relations in a building project is shown in Figure 6.20.

Offices 1

Offices 2

Meeting Rooms Hallway Sanitary

Reception

outside

Figure 6.20: Displaying Spatial relations in a Schematic Representation A more low-level example is shown in Figure 6.21, where a common connection between two floors, supported by a wall and supporting the upper wall, is displayed graphically and as a diagram of connections. The connections can be extended with the adjacent spaces, with possible opening elements and with accessories. Using a Schematic Representation in a design application The data structure which is being developed in this doctoral research provides means to create links between design entities. However, when representing

174

Chapter 6. Representation of building information

Figure 6.21: Displaying Connections in a Schematic Representation the digital building model in the regular graphical views, these links are not displayed. They are visible from the properties panel, but not in the viewport. While it would be technically possible to create additional annotation for use in the graphical preview, this will at the same time clutter the application interface. A better solution was found by defining an additional representation type for schematic views. They will not generate the regular graphical entities, but represent each element as a single box or node. The position of these nodes is initially based on the center point for an element, which is usually the average position of their control points. However, when generating this representation, an additional rendering step will traverse all links and display them as annotation lines. The different link types will then be shown graphically, indicating which entities have been connected. The current implementation is an initial elaboration, disregarding some of the links for which the access methods were not decided upon at the time of writing. However, several solutions and several ideas have been established. â&#x20AC;˘ Each Element will be represented as a single node. These graphical nodes will maintain a reference to the ID of the Element, to be able to graphically select and retrieve the Elements from the project. This enables the regular editing options, such as the display of the properties and the highlighting. â&#x20AC;˘ Translating an Element will actually translate a symbolic point. This is an additional coordinate which is disregarded in the regular representations but is used in this schematic representation. â&#x20AC;˘ Additionally, the schematic view looked at an approach to display all nodes as non-scaling graphics, while custom linetypes displayed arrows between the entities. It is possible to use an external algorithm to lay out the different nodes according to their connectivity. Programs such as AT&T GraphViz 19 are well suited to 19

http://www.graphviz.org

6.2 Overview and definition of representation types

175

lay out nodes, using different layout algorithms for directed and undirected graphs [GN00]. It is possible to generate an input file for the dot program from GraphViz and to parse the generated output document. This output document will contain the coordinates for all nodes and for their connection arrows, allowing for a well balanced overview. An initial test program to retrieve this information from dot-output was created during the development, but this was not integrated into the current prototype, due to time constraints. As such, the schematic represenation is mostly a way to display these representations. However, by coupling a reference to the actual connection within the connection geometry, it is possible to retrieve the connections and edit their properties. It is also possible to immediately see the effect of creating relations between entities, which is hard to visualize in a regular graphical representation.

Figure 6.22: Schematic Representation from prototype, displaying different link types This Representation type has proven to be potentially very valid in a design application, although its implementation is not trivial.

6.2.5

Tabular & Textual representations

Architects often need to summarize information from a building project in tabular format. Examples include quantity takeoffs, the bill-of-materials, listings for several kinds of building elements, administrative forms for statistics, heating calculations or stability calculations. These listings are often considered as output and they require a fair amount of calculations. They are in most cases elaborated separately from the building model. In a BIM context, most applications nowadays allow some custom listings to be generated from the building model. As a further improvement, there are even possibilities to update certain building data directly from the tabular â&#x20AC;&#x153;outputâ&#x20AC;?, thus promoting the listings as an additional interface to the building model data. This is precisely what we strive for with a tabular representation: providing an interface to the building data.

176

Chapter 6. Representation of building information

While it sounds obvious that editing a number in a list might also modify the element from which this number was calculated, it is not always a trivial task. Imagine the adjustment of the composition of a wall, by increasing the thickness of the isolation layer. This will be reflected in all connections involving walls that reference this composition. A listing could be extracted as a text file, but that bears no connection to the original data. In a custom application, however, it is straightforward to add metadata to entries in a list, so the originating element and property could be retrieved, but this is only possible for data that are used directly. Anything that is calculated or summarized in such a listing, has no direct connection to the original element anymore. Editing one entry in a list might also trigger several other places in the global list to be updated. We might look at this task as a detail-view in a database query. The list can be interpreted as a form, resulting from some query. Adjusting fields in the form will update the data and a subsequent call of the same query will show the updated listing. With a bill-of-materials (BOM) representation, a distinction is required between output that is derived directly from the project data and output which is retrieved from an external database. Long textual descriptions, which are found in the BOM, are usually not added as data into the building entities. The building entities are mainly used to see which text fragments should be collected from the central text repository. What could be added to building entities are project-specific notes, such as assembly descriptions or site instructions. They can reference the originating elements, allowing the interpreter of these texts to clarify the instructions with the graphical output, such as the blueprints. Another common textual representation is a quantity estimation. In architectural practice, this is often created separately from the CAD model, in a spreadsheet application. In a BIM context, it should be possible to derive this estimation directly from the building model data. This long and detailed listing would ideally reflect the real building elements and in an integrated environment it is preferable to be able to edit some properties of the building from within the extracted listing. However, one important consideration has to be taken into account. Not everything that is estimated is modeled. Many entries in a quantity estimation are calculated from experience, from ratios or as fixed amounts, depending on the project size. The building practice in Belgium sees the quantity estimation as a task of the architect, to help initial cost estimations and to inform the contractor, before making a price estimation. However, the estimation is usually only given as a non-binding informational document. The contractor is held liable20 for the provided quantities rather than the architect. Even then, it is in the interest of all involved parties that this estimation is done accurately, reflecting the real quantities as close as possible. There is another question, related to this quantity estimation. In common building practice, where the quantity estimation is performed manually21 , there 20 This is at least the common practice in the Belgian context. This can be entirely different in other countries. 21 . . . in the sense that the quantities are written piece by piece in a spreadsheet, rather than being generated from the project.

6.3 A hybrid representation scheme

177

is a habit of subdividing the lines of information into retraceable calculation steps. When the volume of one particular wall is calculated, architects usually write this out in a few lines. They could include the brute volume as the product of length, height and width and then subtract the volume of the different openings. And when the wall connects with a sloped roof, the triangular volume is often calculated in an additional line. This is to inform the interpreter about the followed calculation method. However, in a computer generated listing, there is usually no need to subdivide these calculations and the result is displayed immediately, from volume or area calculations inside the building model data. The volume of the wall is given directly. To derive a listing that is more related to the manual calculation is not always possible and it can be questioned if it is even desirable. It enables the checking of calculations for simple volumes or surfaces, but sometimes, especially with complex volumes, it is more convenient to provide the end result, such as the connection of a sloped and curvilinear wall to a sloped roof. Manual approximations might not always give the correct result, even though the difference might be small. The implementation of such textual or tabular representations can take the format of an interactive textual interface or a static output listing. The former would allow the possibility to adjust some of the building data from within the BOM or the quantity estimation, while the latter is much easier to support in the prototype application. However, the result of allowing the textual representation to act as an interface to the project data has another important repercussion. The user will assume that this listing is synchronized with the building data at any time and thus expect realtime updates. This can potentially slow down the application considerably. It is thus important that an integrated design environment makes no false promises with regard to the user about the functionality of such a representation.

6.3

A hybrid representation scheme

Instead of being limited to typical 2D and 3D Representations, the prototype application that is being developed presents the user with a choice of representations. The digital building model thus has to be represented with different views, each displaying a part of the project data in an optimized form. This is illustrated in Figure 6.23. The CORE Object Model uses a purpose-built scheme of building elements, both physical and conceptual and describes their interrelationships. All representations, such as 2D drawings, 3D models or Schematic Views are generated from the main project data. Figure 6.24 shows how one central building model can form the core from which all different documents and other representations are extracted. It is important to mention that extraction of drawings is not unidirectional . The 2D Plan Representation, the 3D Model and the other representations actually form an interface to the internal building model. The user interacts

178

Chapter 6. Representation of building information

2D Drawing

3D Model

Physical Building

Digital Building Model

Schematic View

Textual View

...

Figure 6.23: Relation between a Building, a Building Model and Representations

Figure 6.24: Illustration of a Building Model

6.4 Conclusion

179

with the building data through these representations. Changes occurring in one of the representations have to be translated into changes of the project data, so all representations can be regenerated correctly. A second remark that can be made is the fact that the digital model can not be a complete faithful duplication of the physical building. This motivates the dashed line in Figure 6.23, which separates the building from its digital model. The important goal is storing enough information to be able to generate other representations and to make informed queries on the model. Another development goal was to avoid making the digital model dependent on limitations inherent in a graphical engine or modeling system. The actual geometrical engine used to represent a digital building model is largely irrelevant. A graphical representation is only an aid to get access to the building data, even if this is probably the most important interface to the building model. Modifications of building elements are triggered from the representation and often involve modifying relationships between elements, which in their turn force an update of the graphical representation.

6.4

Conclusion

The different applications that have been discussed in this section each have their advantages and disadvantages. ADT is complex, but contains all the power and customizability of AutoCAD. Revit follows an extended parametric approach, where relations and constraints can be embedded in the building model. ArchiCAD is more user friendly and is focused on BIM only, but it lacks the extended customizability of ADT and the parametric relations from Revit. In short, each application has its merits and this research is no place to announce the best application. In the context of the development of the data structure, some lessons can be learned. • The prototype should allow multiple representations, which are all linked to the same building model. All modifications to objects should automatically occur in all other representations. • The prototype should present the user with architectural concepts, rather then with generic CAD methods. • The provided building elements should not be isolated objects, but they need to interact and connect with other objects. The architect should have means to insert design decisions into the project data, allowing the model to adapt itself to design modifications. • The data structure should enable structurally correct connections between elements, helping to create valid sections through the project and to generate accurate estimates of all material quantities.

180

Chapter 6. Representation of building information

Not all of these propositions are solved in the current implementation. While this is still the goal for this research subject, it is a quite large task and can not be solved in a single research project. However, even when only elaborating specific aspects of the data structure and prototype, they can help to gain insights into CAD applications that are more supportive for the architectural design process.

Chapter 7

Transitions between Scale Levels and Design Phases Introduction The design of an architectural project is a process. Throughout the design process, the architect will refine, elaborate and rethink the design in an iterative sequence. Based on previous design experience, on project characteristics and on feedback from different involved parties or evaluation tests, the design will be constantly adapted, refined and hopefully improved. One of the improvements that is proposed, compared to existing CAAD applications, is the support of Transitions. The design environment should support the design throughout all Design Phases and Scale Levels. This is of particular importance in the early design stages, where the architect explores the design over different Scale Levels, either going from the generic to the detail or viceversa. At the same time, when the design evolves over different Design Phases, the model should not be started all over again. The architect might change back and forth at any time within the same design project. It only makes sense not to force the designer to work on different models or in different applications. It is therefore of utmost importance that the design environment allows the design to follow along this exploration.

7.1 7.1.1

Definitions Scale Levels & Design Phases

This section tries to explain the meaning of Scale Levels and Design Phases and their respective effect on building elements. Since a design is elaborated over many Design Phases and Scale Levels, it seems only logical to allow the design model to follow these transitions. These definitions are based on the Conceptual Model for CAAD [Neu92]. A conceptual description of gradually adding detailed information to an initial building design can be found in the â&#x20AC;&#x153;BB/SfB Report Câ&#x20AC;? [DNHS89]. 181

182 Chapter 7. Transitions between Scale Levels and Design Phases Scale Levels We can distinguish between different Scale Levels, which vary from the large scale of the Masterplan, over the mid scale of the Blocks through the small scale of the Spaces. On each of these Scale Levels, we manage different building entities. This is clarified in the following overview. Scale Level: Masterplan On the Masterplan Scale Level, the focus lies on the building blocks. These are massive volumes which represent a part of the building which acts as a whole. There is no specification of openings or materials, nor is there information about the floorplan layout. These elements, however, store general information about the amount of floor levels, so basic volume and area calculations can be performed. The Masterplan is formed by the collection of different building blocks on the site, together with general information about the site itself. It is also valid to define circulation and main structural concepts on this Scale Level. The main structural and functional decisions can be incorporated as attributes of these Masterplan Blocks. The subdivision of Masterplan Elements in individual spaces does not usually belong to this Scale Level, but if the feasibility of the Masterplan depends on it, the Masterplan Blocks will be elaborated in greater detail. This occurs on lower Scale Levels and the results can then be incorporated to increase the information level of the elements on this Scale Level. The Masterplan is displayed on a large scale, typically 1:1000 till 1:200, depending on the size of the project. Scale Level: Block On the Block Scale Level, spaces are elaborated. A Masterplan Block is subdivided in building floors and individual spaces. The main volume is split up with vertical and horizontal elements. No further information is given about the general performance and characteristics of these elements, regarding fire safety, acoustics or thermal requirements. The Block level is displayed on an intermediate scale, typically 1:200 or 1:100. Scale Level: Space On the Space Scale Level, we manage building elements. These elements define boundaries between spaces and can be space delimiting or space servicing. Most of the building elements are tangible entities, which have a directly related manufacturing and placement cost. These Physical elements, such as walls or floors, are specified and described on this Scale Level and they contain information about their composition. Openings in elements are specified and structural elements are created. All these elements are further elaborated in following Design Phases. The scale is typically 1:100 or 1:50, though this may depend on the building size. Scale Levels might be extended with higher and lower levels. When elaborating the Scale Level above the Masterplan, this is the Urban Scale Level, discussing

7.1 Definitions

183

groups of buildings on a city scale. At the other side of the available Scale Levels, a detailed Material or Element Scale Level is introduced, looking at building materials and construction details. These fine scale construction details are often used in product documentation by manufacturers and are usually prepared independently from an actual project or rather from generic building situations. They can be incorporated into an actual design project, but might as well be only referenced as additional resources. They are usually adapted to the specificities of the Project. These additional Scale Levels are usually only relevant for some building professionals, such as urban planners or construction firms and do not usually influence the architectural design. Consequently, these Scale Levels are not considered here, although an attempt is made to define the system generically. Note that the names of the Scale Levels are chosen by the design elements of a higher scale level, in which the elements of interest are embedded, e.g. on the Block Level these are the Spaces while on the Space Level the Physical Elements are described. The Conceptual Model also describes evaluation tests which are relevant for each Scale Level. A cost calculation test should be available for all Scale Levels, but its elaboration and expected accuracy is different for the different Scale Levels. Design Phases The design process can also be envisioned as a sequence of Design Phases, which are different, consecutive stages in the elaboration of a building project. Througout these Phases, additional information about the design and different requirements are collected. Phase SD: Sketch Design This is the initial elaboration of a design. It is a schematic phase, with limited detail, to explore the possibilities of the project. This phase is used to evaluate major design decisions and it has the widest impact on the final design. Building elements are represented as simple elements, without any details about their actual construction or internal composition. The major concern is the layout of the plan, with decisions about block and room sizes, including proposed areas or dimensions. The volume and size of the building is defined and the amount of floor levels. Typical examples are volume studies, which usually occur on the Masterplan or the Block Scale Level. There is less interest in technicalities and even the thickness of walls or floors might be disregarded in this phase. That said, it is still important to be able to perform a rough cost estimation to check the design with the available budget. This will not be a full simulation, but rather an estimation based on ratios. When spaces are defined, it is possible to calculate these ratios, which express the quantity of elements relative to floor areas. If the design only provides information about the main building blocks, ratios are derived from average ratios for similar projects, if available.

184 Chapter 7. Transitions between Scale Levels and Design Phases This is the phase where all major concepts are elaborated. The architect might choose a volumetric composition or a main organizational navigation structure. These concepts can still change during this Design Phase, but at the end of this Phase, they have to be finalized. It should be avoided at all times to let the design differ from these concepts in later Phases, since it would probably require to retrace many design decisions and possible force the project to be started again from this initial Design Phase. Phase PD: Preliminary Design This phase finalizes all major design decisions and leads to the required administrative documents, usable for a building permit and for the communication with other external parties. This includes documents for fire safety consults, for building subsidies and for intial consults from structural and technical engineers. The architect will specify construction and materials. The composition of a cavity wall and element thicknesses are examples of the additional detailed information that is available in this phase. This might involve structural and technical choices, such as the type of truss and the chosen isolation material. The accuracy has increased and the composition of building elements is specified, since they are required for the document outcome. Possible evaluation tests are main energy performance1 , area calculations and other tests, which are usually required in the process of acquiring a building permit. Phase CD: Construction Design When the final construction details are defined, the project reaches a phase where the design has been clarified sufficiently to continue its realization in the construction phase. This is the phase where the documents as required for the bidding process are defined and the invited contractors make their estimations, based on the building drawings and specifications, the bill of materials and the quantity takeoffs. Sometimes, in projects where the design team and the builder are one and the same, the construction process might be of importance in the earlier phases as well. In a digital environment, it could be argued that these documents are not required anymore when the information exchange happens through a full digital building model, but today this is still the exception. Building elements require the correct dimensions, composition and construction details. We can extend the Design Phases with additional phases. In a prior Programming Phase, the building project is set up as a series of requirements, formulated in terms of area, volume and budget. Two post-design phases can be 1 Energy Performance in the phase of a building permit is defined by governmental regulations and might be different from the actual calculations required to construct the final building installations.

7.1 Definitions

185

introduced as well. The Use Phase focuses on the management of the building by the owners. This is the focus of Facility Management (FM). At the end of life of the building, assuming no renovation work occurs, a Demolition Phase can be considered. It would also be beneficial to introduce a post-occupancy evaluation Phase, where the project will be investigated according to its design goals and project requirements. All these phases, however, are not elaborated in this research. The post-design phases do not usually belong to the tasks of the architect, while the pre-design Programming Phase is mostly managed as textual listings or even with dedicated software, such as the recently released Trelligence Affinity. We assume that for a large part, the proposed system could be extended in a similar fashion, but this has not been tried nor proven. Design Phases are not Scale Levels In Design Phases, the design evolves chronologically, but the elaborated set of design entities will stay the same, throughout the design process. Each additional step adds information. Elements are further and further specified throughout the design process. In Scale Levels, the focus level changes. There is no pre-specified order to follow in the design process. Smaller residential projects might never require another Scale Level then the Space Level, with the actual physical building entities, where on the other hand, larger projects will usually require planning on the level of the Masterplan. Each Scale Level presents the designer with different entity types. But the different Scale Levels are not independent from eachother. Exterior space enclosing elements directly relate to the skin of the building and thus the Masterplan Blocks. Changes on one level will have implications on the other levels as well.

7.1.2

Transitions

Throughout the design process, the architect switches between different Scale Levels and Design Phases. These transitions are elaborated in this section. In a Scale Level Transition the scope of the building changes. This is often a top-down approach from the global level in the Masterplan to the specific details in the Space Level. It is, however, perfectly valid to adopt a bottom-up approach, testing and validating construction details and scaling up to incorporate them into a global building system, which influences the decisions on the Masterplan Scale Level. This might be the strategy for a construction company standardizing its construction process. The design is allowed to be initiated at any Scale Level, so the architect can freely explore other Scale Levels during the design process. In a Design Phase Transition, on the other hand, the chronological order of a design is followed, from conceptual planning to the construction phase and possibly further. Although the order of these Phases is chronological, the reverse transition has to be supported for design exploration and feedback. Evaluating

186 Chapter 7. Transitions between Scale Levels and Design Phases the design in a more detailed phase might lead to adjustments to be performed back in the Sketch or Preliminary Design Phase. When exploring a design, switching to higher Scale Levels might also trigger a transition to an earlier Design Phase. It is generally not necessary to look at the Construction Design Phase from the Masterplan Scale Level, since the level of detail which is inherently available in the Construction Phase would hinder the overview on the Masterplan Scale. In practice, the user could initiate the transition in two steps, ensuring that each transition step is fully executed before the next step is requested. Since none of these steps are allowed to remove information about the building model, the user should not hesitate to freely explore the different Scale Levels or Design Phases in any desired order.

Structuring transitions Figure 7.1 is a generic scheme to display all possible Design Phases and Scale Levels. Design Phases are placed horizontally, with the arrow pointing to the right indicating the chronological order throughout the design process. The Scale Levels are placed vertically, with the arrow pointing both ways. …

…

… MP … Block … Space

Figure 7.1: Generic scheme with all Design Phases and Scale Levels This scheme displays the Scale Levels and Design Phases defined in the previous section, but leaves room for additional levels and phases. Some of the cells are colored light or dark grey, to indicate that some combinations of Scale Level and Design Phase are more common then others. This suggest that very detailed Scale Levels are unlikely in early Design Phases, while global, large Scale Levels are usually of little meaning when the design reaches the final Design Phases. At the same time, the scheme does not prevent any specific combination of phase or level. The scheme of Figure 7.2 displays the proposed three Scale Levels and three Design Phases in the Conceptual Model. The arrows indicate all twelve possible transitions. This is the model that underlies the data structure, although the

7.1 Definitions

187

generality of the first scheme would ideally be supported, to allow the introduction of additional phases and levels when appropriate. It is assumed that a single transition does not change the Design Phase and the Scale Level at the same time. A transition involving multiple transition steps can always be derived as the compound result from individual direct Phase-to-Phase or Level-to-Level transitions.

Design Phase: Sketch Design

Design Phase: Preliminary Design

Design Phase: Construction Design

Scale Level: Masterplan

Scale Level: Block

Scale Level: Space

Figure 7.2: Overview of common transitions

Can this scheme be simplified? In general each transition might be performed in both directions. We can categorize our transitions in two families: â&#x20AC;˘ the transition from one Design Phase to the next for one particular Scale Level; â&#x20AC;˘ the transition between different Scale Levels in the Sketch Design Phase. This explains why no diagonal arrows are displayed in the schemes. When looking back at the definition of Scale Levels, it can be noticed that they are formulated mostly in terms of the Sketch Design Phase. As a thought experiment, it seems interesting to investigate the result of restricting the representation of the Masterplan and Block Scale Levels to this first phase. A transition between a Space Level and a Masterplan Level in the construction phase is rather uncommon. The next diagram, displayed in Figure 7.3, therefore limits the possible transitions to four significant transitions, instead of the twelve initial possibilities. At the same time, the Design Phase transitions have lost their two-way arrows. This is not to indicate that there is no way back, but the data in the building model can only go in one direction. The elaboration in the following paragraphs indicate a solution to support both the free exploration and prevent the loss of design information. This scheme still indicates two transition types, displayed horizontally and vertically in the diagram. But is the mechanism for these transitions also different? Figure 7.4 reformats the scheme into a sequence of five chronological design stages, each stepping into more detail. This scheme first contains the three possible Scale Levels in the Sketch Design Phase and then continues with the

188 Chapter 7. Transitions between Scale Levels and Design Phases

Design Phase: Sketch Design

Design Phase: Preliminary Design

Design Phase: Construction Design

Scale Level: Masterplan

Scale Level: Block

Scale Level: Space

Figure 7.3: Limiting the scheme with most significant transitions

other two Design Phases. Most architectural design applications focus on the last two stages and hardly provide any support for the first three.

Design Phase: Sketch Design Scale Level: Masterplan

Scale Level: Block

Scale Level: Space

Design Phase: Preliminary Design Scale Level: Space

Design Phase: Construction Design Scale Level: Space

Figure 7.4: Simplified transitions scheme with five chronological stages (not retained) Even though this scheme simplifies the initial proposal, it is not retained, since it lacks an important quality available in the initial scheme. The freedom to step up or down the Scale Levels and back and forth between the Design Phases, in any order, at any time, has to be retained, even when a transition is only performed for a limited set of aspects. It also wrongfully assumes that all transitions follow the same logic, which is not the case. This will be elaborated further in this text.

7.1 Definitions

189

Bottom-up versus top-down? Some projects will follow mainly a top-down approach, by going from a general volume study to a detailed building model. This is common when the design concept is translated in a volume model and in where the overall appearance of the building, the demarcation of the outdoor space, the compactness or the expansion possibilities have a significant importance. In this top-down approach, the overall choices are mostly defined during the Sketch Design Phase on the Masterplan Level and, to a lesser extent, on the Block Scale Level. This global design is then further refined, but the main concepts have been decided upon from the larger Scale Level. Sometimes the designer will choose the reverse approach, in a bottom-up sequence, by going from the details to the main building volume. This can occur when the designer starts from a constructive building system or from a certain solution for a building detail and assembles it into a whole. Or it might be a project where certain room configurations are elaborated first and then assembled into a bigger arrangement, such as in hospital design. To conclude, most projects do not follow a strict linear path throughout the different Scale Levels. This often happens when the designer is working on a project and starts making notes or sketches to try certain configurations or solutions. This might be the proverbial napkin sketch or a more ordered sketch book, that is placed beside the computer. This note taking is usually not logged or added to the project data. It is an important design task however, often leading to the elaboration of several construction details to try and solve a design problem on a larger, less detailed scale. In building practice, these notes are usually not stored in any way and are usually even deleted. The result is that many design decisions are not properly documented at all. Attempts can be made to formalize such design making process , but the effectiveness of such a process is dependent on the integration within the core design environment. Just like the documentation of a programming project is only effective when the documentation is written directly in the source code2 , from which it can be extracted, documenting the design process itself is expected to be effective only when it can occur simultaneously with the design activity. The prototype that is elaborated in this doctoral research intends to let the designer freely explore the design project throughout all available Design Phases and Scale Levels. To be able to store design information within the project, the data structure proposes some mechanisms that create stronger relationships between design entities, such as the storage of links between entities and the connection of entities through Reference Points. By not only storing the design entities, but also their internal relationships inside the project data, the design concept can be document more than what occurs in most current design applications. This system is integrated into the prototype and does not require an additional, separated documentation or annotation step to document the design. The freedom to elaborate the design over these different Design Phases and Scale Levels implies allowing transitions back and forth and thus also allowing the designer to go back to less detailed stages. 2 E.g.

using the Doxygen system ( http://sourceforge.net/projects/doxygen ).

190 Chapter 7. Transitions between Scale Levels and Design Phases

7.2

Transitions in BIM software

Before the approach of managing transitions is discussed, it is useful to explore how existing applications cope with transitions. Some of these applications already support aspects of transitions, but there are certain limitations that might disrupt the workflow for the architect. This is illustrated with examples from three current BIM applications. Autodesk Architectural Desktop The software utilizes a Display Manager to allow customized representations for individual AEC Objects. The generated graphic entities provide support to allow the display of different Design Phases, with a scale dependent geometry. This is done by defining Style Overrides which define how the Style of an element will behave for a particular Display Configuration 3 , as shown in Figure 7.5. low detail

med. detail

high detail

Figure 7.5: Display Settings in Architectural Desktop Apart from the regular physical building elements, Spaces can be modeled as a design entity. A space contains information about a floor and a ceiling, which makes it a good fit to add finishing information to a room, independent of the actual structure. A Space Boundary contains information about the vertical enclosure and it can be converted to walls, but these walls carry no connection with the original space. ADT supports modeling at a Masterplan Scale Level so volume studies can be performed. These volume studies use Mass Elements, which are primitive parametric volumes and Mass Groups which form an assembly of Mass Elements, with the added possibility of defining Boolean properties on particular elements. A building volume can thus be created from a combination of shapes, profile extrusions and Boolean operations. This model can be sliced, using Slice Markers, to generate floor levels and calculate floor areas. The linkage between Mass Elements, Mass Groups and Slices is parametric, meaning that the user can update all elements to help design exploration. If a split-level floor structure is required, it is best to model them in separate Mass Groups, to allow the different Slice Markers to only cut the relevant volumes. 3 The

section on Representations on page 144 elaborates these terms in more detail.

7.2 Transitions in BIM software

191

The software also has means to convert a massing model into a set of building elements, using the option of generating actual floor and wall from a sliced Mass Group. Unfortunately, this is a one-way approach. Once the model is converted, there is no link between the original Mass Elements and the generated building elements. Additional modifications of the design will not be reflected to other elements. This is a pragmatic, realistic approach, although it is regretful that the link between the volume study and the resulting objects is non-existent. The result of this conversion process is shown in Figure 7.6. Masterplan

Block

Space

Figure 7.6: Scale Level transition in Architectural Desktop To conclude, ADT supports Design Phases and Scale Levels fairly well, but the support of Scale Levels transitions is limited to a one-time top-down transition. Graphisoft ArchiCAD The representation of design elements can be influenced by the display settings but also by the display scale. On the one hand, display settings can trigger visual indications, such as reference lines for walls and handles for text or images. Display settings can also trigger output properties, such as hatch patterns, fills and line weights. This is illustrated in Figure 7.7.

Figure 7.7: Example of Display Settings in ArchiCAD On the other hand, through the nature of the GDL-scripted elements, building objects can be programmed with scale sensitivity. The display scale, which is disconnected from the zoom level, allows texts and dimensions to always be

192 Chapter 7. Transitions between Scale Levels and Design Phases drawn at their regular point size, but more importantly, allows library objects to take a different representation when this display scale changes. There is a Zone tool, to model spaces and they can be connected to enclosing building elements, but exploration of different Scale Levels is not possible. When drawing a Zone independently of walls, they cannot be connected. When defining a Zone through an automatic connection with walls, the Zone itself can be updated after modifications to the walls, but manual modifications to the Zone disconnect it from the walls. Additionally, the update process has to be executed manually, which introduces the risk of Zones not reflecting the actual room sizes. These two options illustrate the reasonable support for different Design Phases, but Scale Levels are hardly supported in ArchiCAD. Autodesk Revit Through the support for display scales and detail levels, different representations are possible. The use of massing tools also promises support for Scale Levels. This software allows the user to define a mass model and translate this into building elements. The massing tools allow the user to define a freeform building volume, with a combination of Solid Forms and Void Forms. The faces of the mass volume can be transformed into building elements and floors can be generated inside the mass model. After changes in the mass element, the remake command can optionally fit building elements back to the mass, albeit loosing custom modifications to these elements. It is neither possible to adjust the mass model through the building elements; only the reverse is supported.

0 00 10

10 00 0

Figure 7.8: Example of Scale Level transition in Revit Revit thus supports both Design Phases and Scale Levels, but limits the transitions between Scale Levels. In practice, the Masterplan Scale Level will usually be abandoned once the building elements are further specified.

Motivation to support transitions in a building model Even though the support4 of certain transitions in BIM applications can be noticed, this doctoral research proposes a more elaborate support for bi-directional 4 . . . usually

only in recent releases of these applications.

7.3 Transitions in the prototype

193

transitions. In their current state, the existing applications limit free design exploration. It is not possible to switch back and forth between Scale Levels and modify the design, while maintaining a coherent building model. The architect expects adjustments of the mass model to be translated into an adjustment of the building model and vice versa, if possible. Modifying the amount of floor levels in a building block is a good example. While this is not expected to occur in the Construction Phase, it might be an essential part of project exploration and experimentation in the Sketch Design Phase. Another example is the adjustment of a roof on the Space Scale Level, which should be reflected in the associated Spaces and Masterplan elements as well, as shown in Figure 7.9.

Figure 7.9: Example of adjustments on a Masterplan Block Increasing the height of a building volume can either mean adding additional floor levels or enlarging the height of the floor levels. The Masterplan Block in IDEA+ supports both adjustments, while ensuring the coherence of the block. The support for transitions between Design Phases in these applications is better, since they can be largely solved through representation settings. As an example, a part of the design information for a wall is contained in the position of the the endpoints and in the chosen composition. These aspects will not be modified by choosing another representation, although the graphical output will be different.

7.3 7.3.1

Transitions in the prototype Design Phase Transitions

Switching between Design Phases does not add or remove entities. It merely changes the type of an element and possibly chooses another composition. This is illustrated in Figure 7.10. Suppose a physical element of type Planar Element is given. This might be specified into a wall type, such as SimpleWall, which only requires a start point and an end point. The CORE Object Model [Hen00, p.103] allows the modification of a physical element, by changing its type to a completely different one. The data structure indeed allows any possible change, although the application

194 Chapter 7. Transitions between Scale Levels and Design Phases

Sketch Design

Prelim. Design

Constr. Design

Representations

2D Planar Element

TXT

No Composition

Wall

Wall Brick Wall

Cavity Wall 30cm

Figure 7.10: Transition from one Design Phase to the next for one particular Scale Level will need to limit this to meaningful options only, preferably by allowing the user to choose from a list of valid types. When the planar element has been converted to a Wall, a composition has to be chosen, which sets the materials used by the element and the overall thickness. Although the initial intention was to define default settingsâ&#x20AC;&#x201D;including material assignment and thicknessâ&#x20AC;&#x201D;with the transition, it seems to contradict the responsibility of the architect. The system will not be able to decide such a choice and it is better to delegate this decision to the architect. Instead of a default, it might be wiser to set it to an empty Composition, indicating that the architect still needs to decide which actual Composition will be chosen. The current implementation actually defines this default, but as a convention, the default could be treated as a non-assigned value, which would give the same result. It will require a representation clearly indicating the empty status, though, such as non-hatched and white. In a practical context, it would probably not be feasible to do this for every single element, which still needs to be filled in. In that case, a routine should be made available that lets the designer take decisions for larger sets of entities at once. Different elements can share the same composition, but the type contains the topological information that uniquely defines the element, such as its position or height. This can be regarded as the parameter data for the instanced element. By choosing a type and setting its parameters, the designer adds additional information to the Physical Element, without really changing it. In the next step, the transition from the Preliminary Design into the Construction Design, the type is still a Wall but the composition will change. These steps in the transition mimic the usual workflow from a designerâ&#x20AC;&#x2122;s point of view. The reverse transition, which is depicted in Figure 7.11, is not obtainable by

7.3 Transitions in the prototype

195

merely undoing or reversing these type and composition changes. Switching back from a Wall to a Planar Element would mean a loss of information, because the types contain instance-specific data. The designer will add information, but will obviously not want the system to remove this information, unless the designer explicitly removes the entities carrying the data. However, when the representation level is changed to show another Design Phase, elements will seemingly switch back to a more simple type. Because generating graphical entities for that particular representation will draw these elements differently, this happens automatically. A complex wall that is shown in the Sketch Design Phase can be represented as a surface without thickness, even when the wall element itself contains this information. As such, in the eyes of the designer, the reverse transition is achievable without losing information. Sketch Design

Prelim. Design

Constr. Design

Representations

2D Wall

TXT

Wall Cavity Wall 30cm

Cavity Wall 30cm

Figure 7.11: Reverse Design Phase Transition

7.3.2

Scale Level Transitions

The second type of transition is between Scale Levels. In a top-down approach, the designer might start on the Masterplan Scale Level and design complete buildings and lay out the structure of the site. By switching to the Block Scale Level, the Masterplan Block â&#x20AC;&#x201D;possibly represented by a primitive volumeâ&#x20AC;&#x201D;will be hidden but not deleted. Separate spaces are added into the design, such as different rooms or building stories. The side planes of the volume will generate Planar Elements, which are flat surfaces without further specification. The existing space will be linked to these planar elements, so changes in layout will affect both the Planar Elements and the Space. When the designer switches to the Space Scale Level, these Planar Elements are replaced by walls and floors and thus obtain more information. The reverse transition, following a bottom-up strategy, poses a problem. It is necessary to provide means to go back and forth between these Scale Levels,

196 Chapter 7. Transitions between Scale Levels and Design Phases

Figure 7.12: Transition between different Scale Levels

without losing the valuable information from the lower levels. Therefore it is no solution to change the walls and floors back to simple Planar Elements. The solution lies in the representation. It can generate a more simple set of graphical entities, by omitting thickness or openings from the detailed elements with their specific compositions. When switching back to the Masterplan level, it is possible to ignore floors and walls and their thickness and only represent the contour of the building block as a union of the different spaces. An evaluation test, such as a cost calculation on the Masterplan Scale Level, can thus generate a more detailed result, when all the information of the underlying levels has been set up, compared to performing this test in a top-down strategy, where no information about lower levels is known. The same test generates different results when Scale Level Transitions have already occurred from a lower to a higher Scale Level. The reason is that Masterplan Elements have access to more accurate information when elements on the Block or Space Scale Level have already been created. These elements can provide more accurate cost estimation data, which can be used, in their turn, by the elements on the Masterplan Level.

7.3.3

A wizard-like approach

The transition of one phase or scale into another and the possibility of a reverse transition cannot be a fully automatic process. An application supporting these transitions can provide a wizard, where the architect is presented choices, allowing the translation of design decisions into the technical realization of a project. One of the difficult choices the system cannot automatically generate is the positioning of elements, when thickness is entered. This will be illustrated further on, in Section 7.6 on page 234.

7.4 Mechanisms to support transitions

7.4

197

Mechanisms to support transitions

The following Sections elaborate the key mechanisms provided by the prototype to support transitions. They are in some cases based on functionality that is being used in other applications, but not always in the field of BIM software.

7.4.1

Grid of Reference Points, Lines and Volumes

Introduction and definitions The topology of building entities is partly described by their geometric dimensions. The aspects of these geometric characteristics which are most defining for the entityâ&#x20AC;&#x2122;s layout can be described by Reference Points, Lines or Volumes of the entity. Reference Lines can be used to control the positioning and topology of columns, beams or walls, while Reference Volumes are suitable for staircases, elevator shafts or duct zones. Reference Points can be seen as anchors or pivot points, which lock an element to a geometric position. References When describing a building entity, it is usually referred to by its major dimensions, such as length, width, height, area or volume. Most building entities can be conceptually simplified, by ignoring some of these dimensions. This is possible since one or more of the dimensions of building entities are often at least an order of magnitude smaller than the other dimensions. A chair might have a certain size, but the designer merely positions the chair as a fixed size element on a certain place in the project. It can be called a Positional Element. For columns and beams we might ignore two of the three dimensions. We call them Linear Elements. The thickness of a wall is often more than a factor 10 smaller than its height or length, while a similar reasoning can be followed for floors and roofs. These are Planar Elements. At the same time, some elements can only be described with their full three dimensions. These are Volumetric Elements. The simplified representation of these elements, acting as a carrier, will be called a Reference. The importance of these references, since they have enough information to describe and position the element in a first approach, such as during the early design stages. The less-significant parameters and dimensions can be reduced to attributes of the entity or can be manipulated through its Composition. References can thus be points, curves, surfaces or volumes. This approach helps simplifying the topological structure and possible interactions with most building elements. In this discussion, the focus lies on linear and planar references mostly.

198 Chapter 7. Transitions between Scale Levels and Design Phases Axis lines An Axis of a linear element is closely related to the Reference. An axis is a simplified representation for a Planar or Linear element. The axis line of a wall is positioned in its center and thus defines elements in a symmetrical way, as shown in Figure 7.13.

Figure 7.13: Position of an axis line

Reference lines However, symmetry is not valid for all elements. Imagine positioning the exterior walls of a building. When thinking in terms of positioning them with regard to required distances from the sites border, the line might lie on the outside. This will be managed by the Reference Line, as shown in Figure 7.14.

Figure 7.14: Reference Line To remove the ambiguity, the axis line for a wall will always be positioned in the middle of the element, while the Reference Line can be positioned freely. Relating Axis lines to References With linear elements, a Reference Line will be used. By placing this Reference Line on a relevant position for the designer, axes and References can be related. The axis of a wall is always the central, symmetric line. This is fixed for all elements. However, the designer can choose to place the Reference Line at an offset from the axis. Both lines have a semantical meaning. The axis is important to describe an element in space, from a local viewpoint, where the Reference Line becomes important to relate the positioning of an element with regard to other elements. The positioning of the Reference Line is a design decision and is chosen freely by the designer. The system defaults to aligning the Reference Line with the axis, although other alignments are quite common, as displayed in Figure 7.14.

7.4 Mechanisms to support transitions

199

Figure 7.15: Reference line is offset from axis line Further examples will illustrate different possible choices for the positioning of the Reference, to clarify that it is not desirable to have a purely automatic decision. When a designer chooses this offset, the positioning of elements is complete and unambiguous for one particular dimension. A grid of Reference Points and Lines In the prototype, a grid of Reference Points is built while designing. These points are available over the different Scale Levels. Moving Reference Points will keep all connected elements up to date, regardless of the Scale Level on which they are managed. Reference Points are positions in the model which can be shared between CAAD Entities. They are control points for elements, allowing them to be connected to each other and maintain their connections during modifications. These Reference Points can be used to build up a Reference Grid. Adjusting the grid can move Reference Points and the elements from which they are referenced. A regular grid can be manipulated into an irregular grid, by transforming grid lines. Deleting grid lines will disconnect the Reference Points without the need to delete the building elements. Moving the control points of elements to grid points can establish a connection.

Figure 7.16: Example of a grid adjustment that influences the building block Additionally, Reference Points can be split up in a 2D part and in a Height Reference. The Height Reference can act as a building floor reference, to allow elements to be positioned relative to a building story. Adjusting story heights can actively modify the model and allow elements to stay connected. When refering to the 2D position of a Reference Point, this position can be maintained

200 Chapter 7. Transitions between Scale Levels and Design Phases for elements on different floor levels. It is not common for grids to differ between floor levels. Through the support of grids as a design entity, the user can connect elements to any grid that seems relevant.

Figure 7.17: Example of Height References and Reference Points In a similar way that Reference points mainly connect elements with their 2D coordinates X and Y, Height References connect entities vertically and are usefull to link entities to floor levels. This would allow modifications to the floor levels to be reflected in all related entities. Reference Points and Height References together define all anchoring coordinates, which are used to connect building elements together. But they can store additional design information, using the Property Links and Parameter Expressions. Normally, Reference Points would be defined absolute. The X, Y and Z coordinates are simply static values. The user can modify them, but they are directly set by their value. A further step would be the application of relative values. The height of a wall can be expressed as being relative to a Height Reference, allowing an offset which stays related to the desired floor level. Using Reference Points with Transitions Scale Level transitions will be facilitated through the use of a grid of Reference Points. Masterplan elements, spaces and regular building elements can share Reference Points, staying connected at all times, even when modifications are performed on a different Scale Level. This does not imply that there will be no conflicts during modifications, but managing these conflicts remains the responsibility of the designer, rather then of the software. It would help, however, when a system cooperates with problem detection. A good example of such an application is Solibri Model Checker 5 , which can load 5

http://www.solibri.com

7.4 Mechanisms to support transitions

201

building project data in the IFC format and, based on an elaborate rule-based system, detect anomalies, problems and conflicts with building regulations. This involves interference detection, area calculations and navigation path queries. Examples of how IFC documents are used to aid with problem detection and simulation can be read on [cad06b, IFCs in Action6 ] and [Art06, IFCs connect7 ]. By laying out design elements on a common grid, the implicit relations between these elements are maintained. The grid can be seen as a hierarchical grid, to which the different Scale Levels connect. In the data structure, a grid entity is proposed as a separate design entity, generating additional Reference Points to which building elements can connect. Adjusting the properties of the grid can move the Reference Points, which can then influence all building entities that also reference these points. Extending References with Contours A similar reasoning can be made with series of points or Contours. The different floors in a building are usually related in shape, so it makes sense to let them share the same Contour. Adjustments on one floor level are not independent from other floor levels, which is something that can be enforced through the sharing of Contours. If the Contour itself uses the Reference Points and Height References, the complete geometrical positioning of building elements can be an interconnected network of coordinates. Changes in points can be communicated to other elements, allowing modifications on some elements to generate adjustments to other, related elements. Moreover, the edges of such a contour might carry additional information about its structure or connectivity. In a hierarchical cascade, global characteristics could be defined on a Project Level, which can be overridden on a contour basis. And on the level of a particular floor, another distinction from the global level can be chosen. However, such a system can become very complex for the user to maintain. This is especially apparent in the Styles system of Autodesk Architectural Desktop, where style overrides are used throughout the application, at the cost of complexity. It is not an obvious system to configure and its performance is only reached with a thoroughly set up template system, which takes time and experience to prepare.

7.4.2

Add Classification Information

Most CAD software relies on layers to structure a drawing. Layer names can be constructed according to the ISO 13567 standard. In the data structure, the choice is made to use the attributes from this standard as properties of building elements. Different layer schemes can still be derived from element parameters, but now form a multi-dimensional structure. 6 7

http://aec.cadalyst.com/aec/article/articleDetail.jsp?id=306852 http://www.architectureweek.com/2006/0712/tools 1-1.html

202 Chapter 7. Transitions between Scale Levels and Design Phases This is elaborated on in section 9.2.1 on page 251. In the data structure, the BB/SfB classification system is applied. This system is explained in section 5.6 on page 140. Combining the classification attributes with the proposed attributes from the ISO 13567 standard defines common attributes for all CAAD Entities. The simplicity of only having to assign a layer to an element does not outweigh the additional information that is kept when using several parameters, reducing the amount of choices per attribute. If required for export purpose, it is always possible to extract layer information from common element attributes. Classification Information is important for generic access to element information, regardless of its actual implementation. The classification of an element allows transitions to be automated or to be proposed to a designer in a wizardlike format, where only relevant choices are presented. It also sustains element filtering, which is necessary in the preparation steps for a transition.

7.4.3

Connections between Planar Elements

Introduction Defining connections between building entities is an important responsibility for an architect and is a task that is quite specific in a building context. In building practice, defining these connections in detail is mostly relevant in the Construction Design Phase. When the design transforms from Sketch to Preliminary and Construction design, the composition of the Physical Elements becomes important. Solving the correct connection between planar elements, which are comprised of finishing layers and a core structure, is part of the constructional elaboration of the design. This Section discusses how elements connect and how these connections might be controlled. It contains a short summary of the approaches used in some common BIM applications and how connections are structured in the data structure from this doctoral research. Autodesk Architectural Desktop In ADT, the endpoints of walls have a certain area in which connections are generated, called the Cleanup Radius. Apart from defining these radii for elements, the user does not have to perform additional operations to connect most wall elements. The left side of Figure 7.18 displays a wall with a small cleanup radius, while the right side sets a higher radius for the highlighted wall, allowing it to get connected to the other walls. Increasing the Cleanup Radius enforces a connection between adjacent entities.Beware that in both cases, the Reference Lines are not touching at all. This poses questions however, to the correctness of quantity takeoffs, when relying on the length of the Reference Line. The Reference Line defines the connection type. In the example of Figure 7.19 the cavity wall has its Reference Line on the interior side. This results in the left

7.4 Mechanisms to support transitions

203

Figure 7.18: Connections and influence of Cleanup Radius in ADT connection to be interpreted as an X-connection, while the middle connection is a T-connection. The right wall has a different Wall Style, which does not connect it to the cavity wall.

Figure 7.19: Influence of Reference Line on the connection in ADT There is a need, though, to define the priorities of the layers that compose the structure of a wall too. This is done by setting the priority of the components of the Wall Style. Moving elements does not alter other elements, apart from the connections being regenerated. There is no permanent connection between elements. Additionally, walls can be extended or trimmed against a roof, as displayed in Figure 7.20, where the profile of the underlying wall geometry is modified. This is stored as an upper and lower profile for the wall entity. There is no permanent connection between the walls and the roof, so it is merely used as a modeling aid. When the roof is modified, the user has to regenerate the connection with a trimming operation.

204 Chapter 7. Transitions between Scale Levels and Design Phases

Figure 7.20: Connecting walls with roof in ADT When the user wants to connect walls with floors, there is no real support in ADT. The user is responsible to make sure that all elements are positioned correctly. It does help to use an Interference Condition between the walls and the floor, which allows the floors to create holes in the walls where they overlap. And with such an interference condition, there is a permanent relation, but it has to be defined individually between object instances. Actual building details are created as traditional 2D drawings, although a building section could be used as an overlay. However, changes in the model do not have any connection with the detail drawings. Graphisoft ArchiCAD When the reference line of elements touches the reference line of other elements, a connection is generated, by merging all elements or element layers with identical hatching, as in Figure 7.21. There is a Priority system, which can tweak individual walls and how they connect with other walls. As a result, many complex connections between multilayered elements are automatically solved, even when using the custom element profiles, which were introduced with ArchiCAD 10. They allow the user to define a profile for an element such as a wall, with different materials and different volumes. The connections between such complex walls are solved fairly well, even in 3D, as shown in Figure 7.22. Even then, this system does introduce new complexities and problems. There is no automatic connection between walls and floors, although the section

7.4 Mechanisms to support transitions

Figure 7.21: Connections in ArchiCAD

Figure 7.22: Complex connections using Profile Manager

205

206 Chapter 7. Transitions between Scale Levels and Design Phases view will draw floors over walls, which ensures that most derived drawings look correct. What is helpful is that materials of the same type are automatically merged together in a section, which allows for clean section views directly from the 3D model. Walls can be trimmed by roofs, as displayed in Figure 7.23, but this is not a dynamic relationship. The trimming is only partially retained after modifications to the elements. The cutting plane, which is derived from the plane of the roof, is stored inside the wall element so some modifications, such as raising or lowering the wallâ&#x20AC;&#x2122;s height or moving an endpoint of the wall will still keep the correct cutoff plane. However, lowering the roof or changing the roof angle will not have any effect on the wall at all, as visible on the right sideof Figure 7.23.

Figure 7.23: Trimming walls with a roof in ArchiCAD

Additional Solid Element Operators can be applied, that enforce a more dynamic relationship, where modifications to elements will automatically regenerate the operation. This is also correctly reflected in quantity takeoffs, in contrast to the overlay which happens in the section view and which is only a cosmetic operation. These Solid Element Operators are a solution that seems valid and compatible with the BIM concept, but they lack a clear overview. The operations can be edited, but only one by one and without any kind of overview on a project level. An example is shown in Figure 7.24, where the wall is modified by the roof, using the Subtraction with upwards extrusion operation. Changing the slope of the roof, as shown on the right side of the example, will adjust the wall automatically. Even though it is more complex to create and especially manage the Solid Element Operations, they form a solution that is more capable of maintaining the integrity of the Building Model. They can be used to create an excavation from a site, using the foundation walls and the floorslabs from an underground level, but they can also force walls to leave room for floorslabs. They are not only a modeling aid, since they are dynamic and reflect correctly in quantity calculations as well.

7.4 Mechanisms to support transitions

207

Figure 7.24: Solid Element Operations in ArchiCAD

BricsCAD Architecturals The user can define dynamic connections between walls, floors and roofs. Modifications will adjust the connected elements as well. The height of a wall can also be dynamically connected to a floor level. The advantage of these dynamic connections lies in the assurance that the model will follow most modifications. When an architect intends the wall to extend against the roof above, it is with a high certainty that this connection has to be respected when walls are moved around or the roof changes its slope.

Autodesk Revit The parametric relations between elements are at the core of the Revit application. The user can choose to enforce these relations by locking dimensions. As a result of these relations, most connections are solved adequately, without user intervention. Unlike in ADT or ArchiCAD, element modifications do not invalidate these connections in most cases, unless constraints cannot be satisfied anymore. Defining these dynamic relationships between elements is one of the core concepts of Revit and distinguishes Revit from most other architectural design applications. Examples are displayed in Figure 7.25 and 7.26. Additionally, Revit supports dynamic detail objects. These are 2D drawing objects, but with parametric behavior. When the user adds a detail drawing, the 3D Model geometry is not only used as a visual underlayer, but also as an anchoring reference. When the edge of a roof moves, the detail, that is drawn on top of it, can adapt itself to certain size adjustments. This gives an opportunity to define details that still synchronize with the underlying building model. It is fair to say that this is one of the best solutions of all the discussed applications, with regards to managing connections and construction detailing.

208 Chapter 7. Transitions between Scale Levels and Design Phases

Figure 7.25: Aligning walls in Revit

Figure 7.26: Aligning unconnected walls in Revit

7.4 Mechanisms to support transitions

209

Different connections between Planar Elements This Section gives an overview of the different types of connections that occur in buildings. A strategy to manage them in a digital building model will be elaborated. L-connection When two elements join in one point, this give an L-connection8 which is displayed in Figure 7.27.

Figure 7.27: An L-connection This connection is made with the axis lines, regardless of the positioning of the reference lines. The connection between the elements might be regarded as a separate entity with its own properties, if required by the implementation. This will be important in the Construction Design Phase, where accurate positioning of elements with regard to other elements is paramount. The connection is where all connectivity information could be stored. However, wether this connection will be elaborated as a separate geometric object or merely as a contract object, which manages the relation between these elements, is not important at this point of the discussion. The following example shows three almost identical L-shaped connections in Figure 7.28, where the axis lines are connecting, but the reference line is positioned differently.

Figure 7.28: Different choices to position the reference line An L-shaped connection between walls with multiple composing layers, such as a cavity wall, can produce similar connections. Depending on the situation, it might make sense to make the connection on different positions as shown in Figure 7.29. 8 The connection is topologically identical to an L-connection. The actual angle between the elements is of lesser importance.

210 Chapter 7. Transitions between Scale Levels and Design Phases

Figure 7.29: Joining multiple elements Remember that the axis is still the symmetry line of the element.

T or X-connection When multiple elements join, we obtain a T or X-connection. This might lead to situations where axis lines will not join in the same place. With elements that have multiple layers, as in Figure 7.30, one approach would be to disconnect the layers and make the connections as if the elements had only a single layer.

Figure 7.30: T-connection between multiple elements It is, however, a better solution to make sure that the Reference lines will always join in one point, as shown in Figure 7.31.

Figure 7.31: T-connection with aligned Reference Lines This concept has been elaborated in current BIM applications, where most systems utilize a priority system, defined at the level of the Composition definition. This allows certain layers inside the Composition to be split up, to let other layers pass through. Connecting walls with different thickness might lead to connection difficulties. This is apparent in Figure 7.32 where two elements are aligned.

7.4 Mechanisms to support transitions

211

Figure 7.32: Aligning elements This particular example can be solved, by choosing the reference line at the common side of both walls. The solution is usually to place the Reference line in an aligned position and offset the axes appropriately. Positioning Reference Lines on Grid lines In Figure 7.30 the reference lines are always positioned to connect in one point. The positioning of Reference Lines will preferably be done on a grid, as shown in Figure 7.33. Individual elements might be offset, e.g. to align them on one of the sides or to flow around a column.

Figure 7.33: Positioning Reference Lines on a Grid Building practice does not force any particular layout, since there is often no full, rigid wall to begin with. The contractor materializes the connection of walls on site, which has no direct connection with the conceptual representation as discussed here. From the viewpoint of the designer, the reference lines will always be connected at their endpoints. A design can always be translated with the reference lines aligned on a design grid, while individual elements can be offset locally. When the design is represented as a schematic drawing, only displaying reference lines, a coherent and readable layout should be visible. Connections in 2D or 3D A simple connection is the connection between two or more elements that is fully specified from the 2D projection. If drawing a detail for this connection, it would be a simple drawing that was valid over the length of the element. A complex connection is defined when a single section of the detail is insufficient to define the whole connection. It is suggested that a design application provides an interface to define the desired connections between elements.

212 Chapter 7. Transitions between Scale Levels and Design Phases Building practice shows that many of these detail drawings are reused through different projects and it thus makes sense to collect them in a detail drawing catalogue. The architect, however, still has the responsibility to interpret and possibly adapt the detail to the specific characteristics of a project. An architectural design application could present the user with a connection wizard or configurator. An example of how such a wizard could work is displayed in Figure 7.34.

Figure 7.34: Concept of a Connection Wizard In such a system, the user would be confronted with a certain connection that has to be solved. Using a visual approach, the different composing layers of an entity can be clicked and extended or trimmed to reference lines or planes from other entities. It would be useful to use references such as axis, the closest or furthest plane from another layer and a possible offset. All mutual connections could be collected as a sequence of operations and the order of the sequence could be controlled. In current BIM software, such details are largely managed automatically using composing layer priorities, which will be illustrated further on. How they are solved internally, however, is not documented. Many of these concerns play a pivotal role during the Construction Design Phase, while they are not elaborated in the Sketch Design Phase, where the thickness and the composition of entities can be neglected. The example from Figure 7.35 shows the difference between how the model is managed in the Sketch Design Phase and how it might be elaborated in the Construction Design Phase. Manage connections from the data structure It is preferable to define one mechanism that can be used for all connection types. From the viewpoint of the user, it makes little sense to define the connection as a separate entity, but this seems a usable approach for the data structure, since the connection needs to manage all interrelationships between the composing

7.4 Mechanisms to support transitions

213

Figure 7.35: Different element positioning and composition between Sketch and Construction Design Phase layers of the different elements, while the elements do not have to be aware of the details of the others. Conclusion Finishing details in architectural practice usually occurs in the Construction Design Phase, quite often in the form of 2D Drawings. Even when using BIM software, most construction details are not modeled but rather drafted. This is a direct result of the fact that the 3D Model in BIM usually lacks all the accessories that are required in detail drawings. A fully automatic section can not generate plinths or water baffles, if they are not modeled. In many cases, it is difficult to define in advance the desired connections. A good example is when the design is elaborated in the Construction Design Phase, when decisions on materials and element Compositions are decided upon. Figure 7.36 displays this situation. The left side is the initial layout, in the Sketch Design Phase. Interior walls that are situated on a floor slab. However, at the right side, the situation is much more complex in the Construction Design Phase. The floor will have an elevated floor finishing. The left wall will have to divide two compartments in this part of the building, while the right wall is a light wall that might have to be removed when the offices will be renovated.

Figure 7.36: Elaborating Floor-Wall connections in the Construction Design Phase

214 Chapter 7. Transitions between Scale Levels and Design Phases In many cases, especially with prefabricated components, there are non homogeneous constructions. In such building systems, there are construction rules, which define the possible connections, from the level of the construction detailing. By defining certain dynamic links between entities, some of this intelligence could be included into the design. E.g. making certain offsets or spacing dependent on general parameters, would allow a certain parametrization, that is embedded in the project data. The thickness and positioning of these elements might be trivial in the Sketch Design Phase and pose many design questions in the Construction Design Phase. The current data structure and prototype is more limited in its approach, so future enhancements are required to manage these more complex situations at the level of the data structure. The concept of a Connection Wizard is presented in this Section, but it will not be implemented in the prototype.

7.4.4

Links between entities

In the data structure, three categories of links are introduced: Dependence Links, Object Links and Property Connections. The first two have been introduced in the CORE Object Model, but the third type is added in this doctoral research.

Dependence Links Dependence Links define parent-child relations, as illustrated in Figure 7.37. Elements that become a child of a parent, will be removed and transformed together with their parent. Each Element can have only one parent, but a parent can have any number of children. This creates a strict treelike structure.

Figure 7.37: Dependence Links introduce Parent-Child Relations

7.4 Mechanisms to support transitions

215

Object Links Object Links have been described in detail in the CORE Object Model, but the effect they have on the elements was not discussed. Three types were introduced: • In a Physical Contact Link we connect two Physical Elements. Such a link has the same effect as joining two Reference Points, so these two types of relation belong together. The act of joining Reference Points from two elements should introduce this link at the same time. It thus makes sense to let the user decide upon joining and splitting and let the system take care of adding and removing links. • A link between a Space and a Physical Element will be a Physical Boundary Link . These links are very important in heating and ventilation calculations, where the composition of enclosing elements has to be related to the enclosed volume. It will also be used for calculations of wall, floor and ceiling finishes on a room by room basis. This is also a situation where the joining and splitting of Reference Points will help realizing these relations. Planar Elements that are adjacent to more than one Space at one of their sides should be split or should obtain different Surfaces per space. Even though this system is not utilizing a winged edge data structure, some of the characteristics of such a system can be recognized. The inner working of the data structure, however, does not need to be exposed to the user. • The last link type, the Imaginary Boundary Link , which is only created between Spaces, can also benefit from the splitting and joining of Reference Points. It will be mainly used for evaluation tests which query the correlation between rooms, such as energy simulations or circulation schemes. There is no preset limit in defining links between elements, since they are part of the decision making process. The application relies on the insight of the user to define relevant links. The linkage between Physical building elements and the Masterplan Block is fairly loose. All building elements can be made dependent on some Masterplan Block, to allow removal but also translations from the Masterplan to be transferred to the Block Scale Level. It is the linkage between the spatial model and the other two Scale Levels that is more complex. Spaces might be linked to a Masterplan Block, with an algorithm that checks their contour points, since they should lie in the same contour as the enclosing Masterplan Block. This is possible if we assume that the division in Masterplan Blocks is mostly two dimensional, disallowing overlaps between Masterplan Blocks. A typical top-down design approach is creating overall masterplan volumes and splitting them into different buildings or building zones, according to function or structure or geometry.

216 Chapter 7. Transitions between Scale Levels and Design Phases

MP Block Dependence Link Physical Element Object Link Space

Figure 7.38: Dependence and Object Links between different Scale Levels In a similar way, Building Elements can be linked with Spaces and also Masterplan Blocks. But an existence dependency between a building element and the Space is not available. Linking Building Elements to Spaces using their common Reference Points seems an easier approach and is at the same time quite easy to manage by the user. It does introduce, however, the responsibility of the user to make sure that the connections between enclosing elements and Spaces is coherent. When the prototype of IDEA+ is further developed, it would make sense to introduce additional algorithms for error checking and validating the current design layout. This is however, not elaborated in the current prototype. The linking of Reference Points also seems a way to make sure that Spaces connect correctly and that no left-over spaces are kept, at least in 2D. Since this might suffice for most common design tasks, this approach is elaborated in IDEA+. Property Connections The third connection type was not discussed in the CORE Object Model, but it was added, inspired by design applications from other disciplines, mainly Mechanical and Animation software. Property Connections are a way to connect seemingly unrelated elements through their properties, allowing them to be changed synchronously. By having the height of a wall depend on the height of a particular floor level, changes in floor levels can adjust the elements that depend on that floor level. This is a way to embed information about the design directly inside the elements. These connections are a way to store arbitrary relations between elements. In contrast to the sharing of Reference Points, which only occurs between elements that are nearby, the connection of properties also allows the storage of nongeometrical relations. The user can link properties from different entities, as long as they have the same data type. These entities do not have to be nearby or physically juxtaposed.

7.5 Example transitions in a design project

217

The user has to decide wether a property link is uni-directional or bi-directional. A uni-directional Property Connection defines one property as a master and the other as a slave. Slaves follow modifications of their master, but they can not control their master. A bi-directional Property Connection defines both properties as being equal. This concept is implemented in the prototype and is similar to parameter wiring in the animation applications Autodesk 3ds max and Maya. Such connections are also available in Mechanical Design Software, where parameters can be related to other parameters, usually dimensions of user-defined variables. Ideally, such a connection can be embedded with some intelligence through the use of a parameter expression, rather than a simple equality connection. The designer can embed design intentions directly into the elements, rather than relying on interpretation of markup information. In theory any property can become connected to any other property. As an example, the connection of a wall and a column is briefly discussed. When the designer decides to position the wall with one of its endpoints on the Reference Point of the column, some connection has to be configured. This requires the wall to be offset from its endpoint, to not overlap with the column. This depends on the size of the column, which depends in its turn on the chosen construction type and material, but also on the amount of floor levels above the column and on the direction in which floors or beams above the column need to be supported by the column. This is usually a result of structural calculations or based on common experience. It would benefit the user when some of this knowledge could be embedded by formulating it as a relation or an expression. Using expressions to formulate relations between objects is not common in architectural design applications, but is used extensively with mechanical design systems. In the implementation chapter, this will be discussed in more detail.

7.5 7.5.1

Example transitions in a design project Main Overview

We will illustrate the concept of Design Phase and Scale Level transitions with a fairly basic design example, as shown in Figure 7.39. The case study presents enough generic problems to be of use in this description. The example has some main characteristics and also some limitations. â&#x20AC;˘ The design should not be too trivial, to allow enough different object types and their relations. It will contain a main building volume, a modest set of spaces or rooms and a some common building elements. â&#x20AC;˘ The physical elements will be mainly planar elements, which are not specified at first. They can be used to depict floors, walls and roofs and can contain openings. We can also specify columns or beams, but other entities such as stairs are ignored.

218 Chapter 7. Transitions between Scale Levels and Design Phases

Figure 7.39: Example model â&#x20AC;˘ The planar elements do not contain curved surfaces. Support for curved surfaces is limited in many architectural applications, although many building projects can be adequately described with planar surfaces. We try to define the concepts rather generically, to minimize the dependence on geometric characteristics. â&#x20AC;˘ The planar elements have a continuous thickness over the whole surface. â&#x20AC;˘ The plane orientation is usually orthogonal, but a sloped roof surface has to be possible. Walls are vertical and floors are horizontal. The example project is meant to visualize and document the design. The distinction between surfaces is not necessarily identical to the way the model is stored inside the CORE object model. A designer might imagine a wall that crosses several floor levels as one design entity, while it can be stored as separate entities in the project. The bare fact of creating a drawing is already a useful exercise in trying to capture the design intent, which should help us to define how the data structure should act. Drawing the design will indicate the main, rough form of the building, e.g. using rectangles to construct a contour. In many cases, drawings are not created starting from a detail, but starting with the overal layout of the building, mostly schematic, which is further refined and detailed afterwards. An initial design is often the result of a main sketch, which can then be translated as a volume model. This model will be more specified by subdividing the volume into individual spaces and rooms. The enclosing elements of the spaces are specified by adding openings and choosing their composition. This is an example of a top-down approach, where the project starts on the Masterplan Scale Level, passes over the Block Level and then specifies the Space Level. In architectural drawings, annotation is used to clarify the design. Dimensions, grids and symbols such as a North-direction arrow can be used. However, they

7.5 Example transitions in a design project

219

are not further elaborated in this research, since the focus is not on creating the final technical drawing output. It is assumed that, eventually, the prototype should be able to export the design in a format suitable for one or more commercial CAD applications, where the design can be finalized and documented. This could be realized through the export of the model as a DWG file or preferably as an IFC document, retaining most of the information of the building model, but this is not discussed here. The design example will be used to describe the mechanism of transitions, starting from the first definition of the project.

7.5.2

Creating the Masterplan Model

On the highest Scale Level, the project is created as a set of Masterplan Elements. In Figure 7.40 two Masterplan Blocks are used to define the volume of the building and one SitePart, which is a part of the site having common characteristics. The full site can contain several SiteParts, such as a parking space, a private garden or the built zone.

Figure 7.40: Adding a Masterplan Block and the SitePart The main volume is added as either a primitive box or as an extruded contour. For this discussion, it does not really matter whether this is done through simple drawing commands or as full 3D operations using surfaces or solids. At this point, the project contains just one Element, called MP01, which carries a Masterplan Block, from which a graphical representation is generated. A second volume, called MP02, is added in a similar way, as displayed in Figure 7.42. If it is important for the designer, the two elements can be grouped or merged as one single Element, containing two Blocks instead of one or they can be linked so they have a relationship embedded in the project data. The link is called MP01MP02 and is added in the diagram of Figure 7.43.

220 Chapter 7. Transitions between Scale Levels and Design Phases

Links Project Elements

MP01

Figure 7.41: Simple scene with one Masterplan Element

Figure 7.42: Adding the second Masterplan Block

MP01

Elements

MP02

Links

MP01MP02

Project

Figure 7.43: Adding a second Masterplan Element

7.5 Example transitions in a design project

7.5.3

221

Transition to the Block Scale Level

At this Scale Level, the Masterplan Block is subdivided into Spaces. This usually starts by defining floor levels, using the same contour as the Masterplan Blocks, which are split horizontally. The prototype assumes a constant floor level for each level in a particular Masterplan Block. Split-Level designs require the model to be divided in separate Masterplan Blocks. Spaces are created to represent the rooms in the building, as shown in Figure 7.44.

Figure 7.44: Switching to the Block Scale Level and adding two Spaces These spaces are called Floor0 and Floor1, which represent the stories in the first Masterplan Block. They should keep a link with their enclosing Masterplan Block MP01. This can be done as a Dependence Link. Spaces will not be part of more than one Masterplan Block and that is a deliberate limitation. For the building model to get queried, it is assumed that the spatial model is hierarchical, where each Space is located completely inside a Masterplan Block. This is shown in Figure 7.45. A simplified version of this scheme, which shows only the actual links between objects, is displayed in Figure 7.46. Whenever a split occurs, we also want to have a link between the two adjacent spaces. Floor levels are thus connected by definition. This connection does not mean that they have a passage, but that the potential of walking from one space to the other is there. Further subdivisions can be made by vertically splitting the floor levels into separate spaces. We should distinguish between splits that occur over the different levels and splits that only occur on a single level. In the simplified version, these are all perfectly horizontal or vertical splits. Whenever a split is introduced, the two adjacent spaces should keep a link. The link type will be specified later.

222 Chapter 7. Transitions between Scale Levels and Design Phases

MP01

MP02

Elements

Floor0

Project

Floor1

MP01MP02 Links Floor0MP01

Floor1MP01

Figure 7.45: Subdividing Masterplan Element in Spaces

Floor0 MP01 Floor1 MP02

Figure 7.46: Subdividing Masterplan Element in Spaces (simplified)

Floor0

Room003

Floor1

Room104

MP01

MP02

Figure 7.47: Subdividing Spaces, in this case Floors into Rooms

7.5 Example transitions in a design project

223

How many splits are required is decided by the designer, but the ultimate goal is to have a subdivided Masterplan Block where every space is the smallest enclosure that has to act independently. This is in most cases the same as the rooms in a building, but sometimes rooms contain more spaces, when they need to be treated differently. They might have a different floor or ceiling finish or they might have a different Activity. All spaces on a particular floor level are still related, even though they might not be adjacent. In IDEA+ this is handled with Space Assemblies, which group spaces in a certain way. IDEA+ distinguishes between manually assigning spaces to a particular Assembly and automatically updating the group of spaces inside another Assembly. The former is meant to provide support for any meaningful grouping a designer can propose, while the latter would be sufficient for many common groupings, such as a grouping by function or floor level. An automatic assignment can add all spaces with the same floor level to one assembly or can add all spaces with the same Activity to the same assembly. Spaces can be part of as many Assemblies as required. A spatial occupancy plan can be created from an automatic list of Assemblies for all the different Activities. The implementation of Space Assemblies poses additional questions. • To derive correct areas in an assembly, Spaces should not overlap. By the introduction of polygonal clipping the contour of Spaces is first merged, so the area calculation will not count overlapping areas twice. • When assemblies are regenerated, they collect all spaces that are relevant, based on their internal filter, e.g. by activity or by vertical position. However, when multiple assemblies are defined, they might contain the same spaces. One strategy could be to only allow Spaces to be assembled once and avoid any overlap in groupings. Another strategy could be in subdividing the Space between the assemblies. However, in that case, there must be a controllable division scheme. It might be as simple as equally dividing the spaces over the assemblies or using weights or other distributions. • When an assembly itself is inherited from Spaces, it could be possible to assemble other spaces. However, that poses even more conflicts and overlaps. Since assemblies are useful in fast estimations of areas for cost calculations, these issues have to be clarified further. Assemblies have thus far been only partially realized. The result of creating the additional Spaces is displayed in Figure 7.48. At this Scale Level, openings in walls or floors are not included, but it is valid to define which surfaces are open and which are closed. An open surface can be thought of as a void or virtual wall and presents no physical separation between spaces. This is required to still distinguish between these spaces. They are not physically separated but make sense as separate entities from the designers’ point-of-view.

224 Chapter 7. Transitions between Scale Levels and Design Phases

Figure 7.48: Adding additional Spaces In the case of adjacent spaces with a void or open surface, they should be linked automatically using an Imaginary Boundary Link . In the other case, the closed surface will become a wall or floor later and then it needs to have a Space Boundary Link with the space. This is already a part of the information that is needed on the next Scale Level. Based on the notion of closed and open surfaces, transitions are actually prepared to the Space Scale Level, where Physical Elements are introduced.

7.5.4

Transition to the Space Scale Level

The enclosing elements of the Spaces that are not void are materialized. These are mainly Planar Elements and depending on their orientation, they will become floors or walls. The upper floor will become the roof plane. Figure 7.49 displays the physical elements, which were added. In addition, the designer decides upon openings in these elements, to create Windows and Doors. At this moment, these openings are still empty. The possible relations between Physical Elements, Space elements and Masterplan Elements can be described. The enclosing elements should be linked with the Spaces they enclose. In most cases, they need to link with two Spaces. Such a link is a Space Boundary Link. This has already been prepared in the splits on the Block Scale Level. At the same time Physical Contact Links should be introduced for all Physical Elements that connect to other elements. The floor of a Space needs to be connected to the walls of that Space, the walls need to connect to the walls next to them and all walls should be connected to the ceiling. It is assumed that the floor is split between all Spaces. Even though the designer might want to imagine the floor as continueing over the whole floor level, the building model

7.5 Example transitions in a design project

225

Figure 7.49: Switching to the Space Scale Level and adding Physical Elements

will require separate entities. They will often share the same Composition, but they have to be maintained as individual floors. Since walls and floors are usually adjacent to two Spaces, they should not be created twice. This can be done either by ensuring that adjacent Spaces create only one adjacent enclosing element or in a second step, by filtering out all elements that occupy the same Space. This is easier when all corners of a Space volume are merged or shared with other Spaces. This is the desired configuration, to avoid â&#x20AC;&#x153;left overâ&#x20AC;? voids between Spaces. It is the intention that the combination of all Spaces occupies the same volume as the enclosing Masterplan Block. In Part III, a strategy to enforce model integrity will be discussed. Until now, this example illustrates a linear approach, where elements were defined on a particular Scale Level. The project then stepped to the lower Scale Level in this top-down example.

7.5.5

Going back to the Block Scale Level

Figure 7.50 displays the Block Scale Level, where the Spaces are managed. Now the Physical Elements have been added, which is visible as a wire frame representation. Note that stepping back to these Scale Levels will not remove elements, but rather adjust their Representation. Physical Elements are a part of the Space Scale Level and they are not displayed on the Masterplan Scale Level.

226 Chapter 7. Transitions between Scale Levels and Design Phases

Figure 7.50: Returning to the Space Scale Level after adding Physical Elements

7.5.6

Modifying the building model

Creation, modification and deletion are three different types of operations that can occur in the building model. They all influence not only the available elements, but might change, create or remove links between these elements. The more of these changes can be handled by the system, the less the designer needs to manually maintain the model integrity. But it is not a trivial task. Modifying properties of elements Such changes usually have little impact on other elements. In some situations, however, elements might become dependent on other elements. E.g. the switch to a different composition will change the load on supporting elements. When switching between load bearing and non-load bearing walls, the whole building structure might have to be adapted. In the end, the designer still has the responsibility to define a coherent structural model and provide the correct set of physical elements to materialize the design concept into realizable entities. â&#x20AC;˘ Changing the thickness of a wall seems a rather simple adjustment but all elements that have a Physical Contact Link with this wall should be regenerated, since they might rely on that element to generate their own representation. And then they might trigger additional updates to elements that are linked against these secondary elements. This could end up as a chain of regenerations and maybe even an iterative loop, where other elements might trigger a regeneration of the initial element. â&#x20AC;˘ When moving elements, the building morphology can change. Small movements, as illustrated in Figure 7.51, will not invalidate the current structure, keeping all links intact and the relative position of elements identical.

7.5 Example transitions in a design project

227

Larger movements, however, can dramatically modify the positioning of elements against each other. This can be compared with moving vertices in a geometric mesh. As long as the movement of a vertex stays inside its adjacent enclosed volumes, the mesh topology stays the same. Figure 7.52 illustrates a conflict when vertices or edges are moved.

Figure 7.51: Modifying building contour without changing topology

Figure 7.52: A conflict can occur when vertices or edges are moved

228 Chapter 7. Transitions between Scale Levels and Design Phases Adding an element When making sections on the Block Scale Level at a point where no elements in the Space Scale Level have been created, no real conflicts arise yet. But adding a new element at either Scale Level afterwards introduces new obstacles for the software development. This paragraph takes a detailed look at the effect of subdividing a space and the resulting links between elements. Figure 7.53 displays a single room with four enclosing walls.

Wall01 Wall04

Wall02 Wall03

Figure 7.53: An existing simple space The diagram of Figure 7.54 displays the links between the walls and the room they enclose. The links with the floor and the ceiling are not shown, for reasons of clarity.

Wall04 Wall03 Room01 Wall01 Wall02

Figure 7.54: Walls enclosing a single room As an example of the adjustments needed to the underlying model, a new wall is introduced which subdivides the existing space. The diagram of Figure 7.56 displays the corresponding links. If it is assumed that the previous situation was fully configured and all links were defined, the addition of that wall requires a fair amount of adjustments, not only to the elements, but also to the links. The space has to be divided, but also the floor, the two walls which connect with the new wall and even the floor on the story above.

7.5 Example transitions in a design project

229

Wall04

Wall07

Wall01

Wall05 Wall02

Wall03

Wall06

Figure 7.55: Subdividing the existing space

Wall04 Wall07

Wall01 Wall05

Room01

Room02 Wall03

Wall02 Wall06

Figure 7.56: Walls enclosing two rooms

230 Chapter 7. Transitions between Scale Levels and Design Phases If we further subdivide the newly created space, the amount of links further increases, as shown in Figure 7.57 with the corresponding links displayed in Figure 7.58. Wall04

Wall01

Wall07

Wall10

Wall05 Wall08 Wall02 Wall09

Wall06

Wall03

Figure 7.57: Further subdividing the space

Wall07

Wall04

Wall09

Room03 Wall10 Wall08

Room01 Room02

Wall01

Wall05 Wall03

Wall02 Wall06

Figure 7.58: Walls enclosing three rooms

Removing an element The removal of a Masterplan Block forces all dependent Spaces to be removed as well. This is automatically done by the Dependence Link. At the same time, all enclosing elements that are adjacent at both sides to some of the removed Spaces should be removed with them. Some of these elements will need to

7.6 Questions and remarks

231

be maintained, since they can also be adjacent to Spaces from inside another Masterplan Block. • Should Planar Elements be merged if possible? Walls that lie in the same plane and which have a physical contact link can become one single wall. But the decision lies with the architect and not the system. A program such as SketchUp identifies such planar orientation and indicates this by displaying the border edges with a thin line instead of with a thick profile line, leaving the decision to erase this edge with the designer. • Will a Space which loses one of its enclosing elements be removed or is it expected that it gets joined with a possible adjacent Space? IDEA+ as a prototype will not provide an automated answer. The user should maintain the configuration of the model and insert appropriate enclosing elements to make sure the model is coherent. At all times, the design is like a puzzle, where pieces are moved around before they finally fall into place. All steps in between solved states are maybe not valid building models, but they can not be skipped either, to provide the possibility of fine tuning the design and to provide what-if scenarios. • Are there existence-depencies between enclosing elements and the spaces they enclose? No. There can be no Dependence Link between Spaces and their enclosing Physical Elements, since they can enclose other Spaces as well. The removal of a Space does not remove these enclosing elements, but in some cases, there might originate a void in the building volume, as illustrated in figure 7.59. When subtracting all Space volumes from the Masterplan Element from which they depend, these leftover voids can be retrieved. When removing an enclosing element, the two adjacent Spaces could be re-linked with an Imaginary Boundary Link , creating a “virtual” wall. In the prototype, this is not automated. At this point, it seems appropriate to launch a Design Wizard, where a dialog or a sequence of dialogs pops up and let the user decide how the adjustment should be handled. This is after all a design decision, for which the user is less likely to rely on an automatic algorithm. At the same time, the user will be hindered when every operation is accompanied with several questions and popups. It is assumed that most modifications should be allowed by the system, making the user responsible for maintaining a coherent mode.

7.6

Questions and remarks

Keeping all Scale Levels and Design Phases together? In a linear approach, such as the conversion options in Architectural Desktop, users accept the fact that it is not possible to update the Masterplan Model from changes in the generated building elements.

232 Chapter 7. Transitions between Scale Levels and Design Phases

Figure 7.59: A void might occur when a space is removed In this doctoral research, however, it is a goal to keep the different levels available and also editable. Making changes on one Scale Level, however, will introduce inconsistencies with elements on other Scale Levels. When the Building contour of a Masterplan Block is changed, the generated spaces and the generated planar elements will have to adapt, if the building model needs to stay coherent. For some changes, this might simply mean the translation of some corner point, but other changes can introduce a whole new layout, which is difficult to automatically follow on the other Scale Level.

Figure 7.60: Modifications can introduce additional changes Since the exploration over different Scale Levels is desired, there has to be a strategy to synchronize the contents on the different levels. It could be an option to modify dependencies over time. At the moment the user transitions to another Scale Level, the other Scale Levels could become dependent on the active Scale Level. As an example, a Masterplan Block could become generated from the exterior walls, instead of relying on its own contour.

7.6 Questions and remarks

233

Changes to the Physical Elements can thus be followed. That does imply, however, that it is not possible anymore to modify the contour of the Masterplan Block directly, since it is an element that becomes completely dependent on other elements. To be able to adjust the Masterplan Block on its own Scale Level, the dependency has to be reversed and the Physical Elements become the depending entities. When each element would be independent at some time and dependent at another moment, there seems to be less reason to introduce these dependencies in the first place. A better solution might be to start with a new, â&#x20AC;&#x153;alternativeâ&#x20AC;?Masterplan Element, but inheriting certain information from the Masterplan Element from the first attempt. In a similar way, Spaces might be automatically generated whenever walls enclose a region. This is sometimes used in other applications. While this will ease the data entry for the user, it is complicated by the need to assign Activities to Spaces. This is preferably not something that can be done automatically, although a default or empty Activity could be assigned. However, from then on, Spaces are no real design entities, but rather labels or attributes to other entities. Generating enclosing elements from the spatial model seems another possibility, but the same problem of not automatically assigning composition information to planar elements can be encountered. Another strategy might be the removal of all but the last two Scale Levels, as if it were a special backup version of the project. This is inspired by the RIBA Plan of Work , where a design workflow can be found that allows to go two steps forward and possibly one step back.

Design Phase: Sketch Design Scale Level: Masterplan

Scale Level: Block

Scale Level: Space

Figure 7.61: Keeping several stages A motivation for such an approach is the understanding that a typical design workflow is not strictly linear, but also not entirely random. Most transitions happen in one direction, occasionally taking one or several steps back for evaluation purposes. It might be safe to assume that the design is usually evolving forwards, but sometimes backwards, on a linear time line.

234 Chapter 7. Transitions between Scale Levels and Design Phases

Introducing the thickness of Building Elements In the Masterplan and Block Scale Level and in the Sketch Design Phase on the Space Scale Level, the thickness of elements will be ignored in this proposal. In the transition to the Preliminary and the Construction Design Phase, however, the thickness of elements will be introduced. For the positioning of an element with regard to its References different possibilities are open. It is the result of a design decision that defines where the wall, a beam or a floor are positioned. At the moment an initial transition occurs that takes the design from the Sketch to the Preliminary Design Phase, generic planar elements without thickness are replaced with walls, floors or roofsâ&#x20AC;&#x201D;depending on their orientationâ&#x20AC;&#x201D;with a selected thickness. This replacement can be made automatic, even though the user might opt to choose different replacements instance by instance or based on predefined rules. Centering a wall over its reference line or placing a floor at the lower side of its reference height might be a valid first choice, but in some cases the user might choose to adapt this alignment. In all cases, the offset from the baseline or reference line has to be editable at creation time and afterwards. But there are many cases where the addition of the thickness of a component might introduce conflicts. Wall Thickness When thickness is given to a wall, the positioning of the wall with regard to its reference line becomes important. Giving walls a thickness might make a corridor too small to pass through, so some of the walls might need to be translated to compensate for that. Sometimes the thickness has to be added to the inner side of a contour, while at other times, the contour defines a column structure where the walls have to flow around. As the default suggestion, all walls will be centered on their baseline. The offset from this line is a user-editable property. The choice of this offset also influences the connection with other walls. In a transition from the Sketch Design Phase to the Preliminary or Construction Design Phase, a planar element will be replaced with a wall and the default empty composition. The choice of a composition directly influences the thickness of the wall, but also the alignment of walls. The alignment that is desired can be chosen by adjusting the offset from the reference line. This is important when the user wants to have one side of a wall in the same plane as the side of another wall. When the second floor level is explored, the alignment choice made for the first floor might be adapted. The system has to allow these flexibilities, but can not predict the choices of the designer. Floor Thickness Following a similar reasoning for floors, there are similar design choices to make. Adding thickness to a floor, would require the designer to decide upon the alignment. In some cases the bottom side of adjacent floors needs to be aligned,

7.6 Questions and remarks

235

while at other times the floor finish has to align at the top side. At the same time, connecting walls have to be adapted to still join correctly. In both cases, the initial design simply had a flat surface at the same height. In the case of a terrace floor, which was displayed in Figure 7.35, it can be a requisite that the bottom side of the floors are aligned, while at other times the top side of the floor will be the alignment plane. In both cases, they might have started as two aligned planes when the thickness was ignored. In the example of the terrace floor, there is an inherent difference in construction thickness between a full terrace floor construction, including isolation and terrace tiles with provisions for evacuation of rainwater, and a common inner floor, requiring only the main floor construction and its finishing or sometimes an acoustical floating floor. The terrace floor might end up twice as thick. This can not be ignored when elaborating the design. Connection Wizard To aid the user when deciding about the connections between elements, a “connection wizard” is proposed. Depending on the active Design Phase, different connections are targeted, as illustrated in Figure 7.62. • In the Sketch and Preliminary Design Phases, the 2D Connections should be investigated. These are the places where two planar elements connect and form an intersection line. • In the Construction Design Phase the place where multiple elements intersect has to be defined. These can be thought of as 3D Connections, which join 2D Connections.

Figure 7.62: Aligning floors when introducing thickness Such a Connection wizard has advantages and disadvantages. It can enable to specify details in a guided approach, but it might disrupt the design process. The

236 Chapter 7. Transitions between Scale Levels and Design Phases connection between Planar Elements should be mostly an automatic process, as discussed earlier on. When the design is elaborated into a Design Phase that is sufficiently evolved, construction details become important. This is usually the Construction Design Phase. In this case, the user might opt to call the wizard, instead of being forced to follow the wizard, whenever a transition into this Phase occurs.

7.7

Conclusions

This Chapter gave an overview of Transitions, what they are and how they function. It was argued that Transitions are not adequately supported in current BIM applications and what possible mechanisms could help to improve their support. The example case study explained how Transitions could be applied in a practical design project. However, additional questions arose and not all of them have yet been answered. Most construction documents include some characteristic drawing details, which are usually 2D Connections. Full 3D Connections are seldomly documented since they can not be represented completely in a 2D Representation. The system will add default thicknesses and alignments. The thickness is derived from the chosen Composition, while the alignment must not change through the choice of composition. The way compositions are defined, they lay out the components that represent a series of entities with the same inner structure. However, the positioning of an element with regard to its reference line has to be set separately. Switching to another composition does not influence this offset. An architectural design application has to present flexibility to the architect when configuring alignments and connections. Even though IDEA+ does not target the drafting of construction documents, which is the realm of most commercial CAD applications, it has to understand the design language and the design intentions of the architect. This is an ambitious undertaking and still leaves many open questions for possible future research. A Design Phase Transition is mostly performed through the addition of element information. As an example, a simple planar element can become a cavity wall, with a certain composition. To perform this transition might involve modifying elements. This is obtained by decoupling elements from their topology, allowing elements in the IDEA+ data structure to apparently switch type at runtime. A reverse Design Phase transition, however, can not involve another type switch, since this would lead to loss of element information. This reverse transition is therefore handled through the representation settings. These concepts are explained in [Hen00], where the Core Object Model is described. A Scale Level Transition will have to create additional building elements, if required. When a Masterplan block is set up, it lacks walls or floors. They can be

7.7 Conclusions

237

added initially, in the transition to the Space and Block Scale Level, the former creating spaces and rooms and the latter creating actual building elements. The reverse transition depends on the potential existence of a Masterplan block. This could be generated as the outline of the building, containing reference points from all external walls. If, however, these building elements were already generated from a prior Masterplan Block in the first place, we need to update the existing one. The grid of Reference Points forms a connection between different Scale Levels. Most modifications can be reduced to Reference Point manipulations, such as transformations. Other modifications, such as choosing a different composition for a planar element, should not influence the other Scale Levels.

Chapter 8

Integrating Evaluation tests Introduction This Section will explain the motivation for integrating evaluation tests inside an architectural design application. While the actual development and elaboration of tests is beyond the scope of this doctoral research, it is important to explore the requirements for the data structure and the prototype to support these tests. The integration of evaluation tests is motivated by the impact design decisions have on the project early in the design process, as displayed in Figure 8.1, taken and translated from [Tro01].

Figure 8.1: Impact of design information on design costs In common architectural practice, designers will preferably evaluate their concepts during the design elaboration phase. However, these evaluation tests commonly require extensive data entry and sufficient project detail, to be executed. Since this takes an enormous effort and much of these data is not available at that point, it is not trivial to make these tests an integral part of the design process. A large part of this evaluative phase is assumably performed mentally, based on both intuition and experience. While there are many different software applications which support such tests, they are applied mostly on a finalized design, informing the architect about conformance to certain criteria, but long after the concepts have been clarified. However, the real advantage of 239

240

Chapter 8. Integrating Evaluation tests

evaluation tests is the potential to improve and adapt the design. This is easier to do early in the design process and at the same time it has more far reaching impact, when compared to performing the test at a moment the design has been almost completely elaborated, as illustrated in Figure 8.1. There are a couple of reasons to explain this situation. The time it requires to translate the design project into input documents for the evaluation test can be considerable. In most cases, the evaluation test is a stand alone application or environment. In many cases, there is no direct conversion from the design data to the required input format. The architect thus has to reintroduce the design data. Reducing this effort usually implies that the architect only executes such a test when the design is finalized. A second contributing factor is the required amount of information. To be able to generate realistic results, the architect needs to provide detailed information about the design. This is usually not available at the time of the first design sketches. And finally, the complexity of these applications often results in a slow and labor intensive conversion process, which is usually not justified when the design is still evolving, since the results will be outdated almost instantaneously. However, the impact of the evaluation test in the early phase of the design process is much higher than at the end. Most major design decisions are still being considered, which can result in important options that still have to be taken into account. It is precisely at this time that the architect would benefit the most from evaluation tests. It only seems logical to look for an approach to ease the translation of design data into an evaluation test and to investigate possibilities to optimize the calculations with common, default parameters. This is precisely what the integration of evaluation tests is attempting. This is obvious in theory, but has to be proven for practical simulation tests.

8.1

Characteristics of Evaluation Tests

A distinction has to be made between tests which extract and report information and tests which, based on the simulation, add information to the elements and which may even modify the properties of elements.

8.1.1

Extraction Tests

The first category of tests are the extraction tests, which include reporting tools and data exporters. A reporting tool traverses the project data to request data from the design entities. Typical examples are cost estimations, quantity takeoffs and the generation of many different listings for administration or reporting. The tests will not modify entities and will rely as mush as possible on the generic methods, to make the test independent of possible later additions to the data structure.

8.2 Examples of tests

241

Data exporters are another type of test. They will traverse the project data and write every encountered object into another format. This could be used to export the building geometry into a visualization application or to export the building data into a textual format used with building simulation applications. It is important to understand the difference between extracting the building information and extracting the geometry. The former involves a deeper understanding of the building structure and the architectural design concepts, while the latter merely requires the graphical entities from one of the representations. In most cases, the 3D representation will be used, e.g. to extract polygons or meshes for 3D applications. The extraction test could at the same time generate extracted documents and call external processes to use these documents. A visualization test could extract the 3D geometry together with the material information into a format that might be directly rendered out by an external rendering application, such as Radiance or a RenderMan-compliant rendering application. This will be illustrated with the examples, further on in the text.

8.1.2

Data Generation Tests

The second category of tests are explicitly using the results of some simulation and add them into the main project. This can be in the form of a graphical chart, creating drawing entities inside the project, but such a test can also write its results directly inside the properties of elements. The test could update existing properties or it can even add extra properties to elements. The results of the test become a part of the project data and they are stored and kept with the elements on which the test has been executed. The method to enable this in the data structure is explained in the implementation chapter, where the Property System and Extended Properties are discussed.

8.2 8.2.1

Examples of tests Daylight Estimation Test

The test for daylighting has been elaborated in the Design and Building Methodology research group at the K.U.Leuven, in the course of the doctoral research of Benjamin Geebelen[Gee03], [GvN05]. The IDEA-l program was developed to provide a fast, but accurate calculation of the annual cumulative daylight penetration. During this research, some necessary connections with other CAAD programs have already been tried out based on collaborations with another research team. The daylighting test is, however, not yet integrated into the current application prototype.

242

Chapter 8. Integrating Evaluation tests

Overview of IDEA-l Geebelen developed an optimized calculation method to improve daylighting simulation on an annual basis. The problems such an evaluation faces are the usually long computation times, the variability of the sky and the high amount of required lighting cases1 . The approach was to use the radiosity algorithm, combined with Southwell relaxation. However, instead of focusing on visual output for rendering, for which radiosity is often applied, calibration tests indicated that lower-quality mesh subdivisions did not negatively influence the acquired calculation results.

Figure 8.2: Lower quality mesh provides sufficient accuracy in IDEA-l In Figure 8.2, the surface path size is enlarged. For visualization purposes, this diminishes the image quality considerably, but in the daylight calculation, results were still accurate. The left side of the image took 5 minutes to compute, yet it generates the same illuminance levels output2 as the right image, which finished in about 20 seconds. At the same time, the required Âą4700 lighting cases have been reduced to parallel computing of 188 daylight coefficients, with one additional inter-reflections step, as illustrated in the scheme of Figure 8.3, which depicts the algorithm. As a result, the IDEA-l prototype, which was implemented, provides an accuracy which is comparable to advanced simulation engines, yet at a spectacular computation speed. A simulation for a whole year can be performed in less than a minute. Integrating IDEA-l in IDEA+ What is required for the data structure to support the daylighting test? To be able to perform such a test from within the design process, all that is required are the outer surfaces and their material properties. To optimize the 1 Âą4700 lighting cases have to be performed, which equals the average hours of daylight in one year. 2 According to [Gee03] the mean relative difference between the corresponding illuminance levels is less than 1%.

8.2 Examples of tests

243

Figure 8.3: Decreasing the required calculation steps in IDEA-l calculation times, it is assumed that only Planar Elements and openings are required. The material properties from the current data structure would have to include accurate reflectance and transmittance values. Since these values can be derived from real world materials, a material library could be set up in advance, requiring no additional input from the user. Information about the daylight conditions can be automatically derived from the Outside class, which stores geographical position and orientation of the project. As such, the test could be performed without additional user intervention, assuming that the environment and the main material properties have been set up. Although this evaluation test has not been integrated in the prototype at the time of writing, we expect the test to be usable from within any of the available Scale Levels and Design Phases.

8.2.2

Cost Estimation

A prototype for a cost-estimating test, using the different Design Phases and Scale Levels has been elaborated in a Masters Thesis [Wit02]. The flow of cost calculations between different levels has been implemented as a Visual Basic module that operates inside Autodesk Architectural Desktop, but based on the Conceptual Model of Neuckermans. This testing mechanism has to be

244

Chapter 8. Integrating Evaluation tests

integrated into the data structure and application prototype, after finishing the object model and the generic structure for the testing applications.

8.2.3

Visualization

As an example of data extraction, a Rendering test has been chosen, which exports the generated 3D representation as a series of input files for the Radiance rendering system [LS98]. This is a suite of light simulation tools, allowing realistic physically based renderings, with accurate lighting level simulation. The test exports the 3D geometric representation as a series of Radiance data files and adds some additional control files to launch the rendering process, as displayed in Figure 8.4. This enables valuable feedback about the influence of lighting on the project. Rather than embedding a full rendering engine inside the main design application, the program simply generates the input files and executes the external rendering application. This simplifies the implementation, yet it still gives usable results. However, additional applications are required. It is preferable to focus on widely used software and at best, those that are freely availabe. In some cases, it is possible to just include these external applications alongside the prototype application, provided their license permits this.

Figure 8.4: Rendering a model directly with Radiance The full feedback of integrating these results with the project data, however, is not enabled with this test.

8.2 Examples of tests

8.2.4

245

Other possible tests

While the elaboration of actual tests is beyond the scope of this research, it is interesting to at least point to possible interesting evaluations that are deemed to be valid during the design process and especially the early design stages. In an academic research group, it is interesting to see which other experiences are available and which might be worthwhile to integrate. Within the Design & Building Methodology group, several research domains are being investigated. Two examples will be mentioned. The research involving Universal Design 3 will attempt to improve the design of products and environments to be usable by all people. This not only includes persons with physical disabilities, but also people with temporary disabilities, mental disabilities and actually people without disabilities at all. Applied into architecture, this can be translated into guidelines for a designer. Several thesis projects already elaborated specific case studies, in the fields of acoustics and accessibility. However, having these guidelines taught and available as a checklist might not suffice. This research uses a combination of literature study, interviews, participation experiments and case studies. The results would benefit the designer, should they be integrated in some form into the design tool. An evaluation test, which checks the current digital building model against basic rules would be able to report deficiencies in the design early on. Such a test would ideally be a data generation test, creating notes or annotation into the model to indicate shortcomings. Another interesting research domain involves Durability and Total Cost simulation, where not only the financial cost of buildings is taken into account, but also its impact on the environment, throughout the whole building life cycle. This is currently mainly based on models using spreadsheets, but such simulations would make perfect sense to integrate into a design application. These tests would be suitable throughout the different Design Phases, gradually requiring more elaborate information from the building model. In the context of the European requirements for building insulation and control over energy consummation, the Belgian building practice has introduced energy performance regulations, called Energie Prestatie Besluit (EPB)4 . This is currently included in the current regulation system for building permits and requires the use of a specific software tool, made available by the government. However, in the evolving context of Building Information Modeling, it would make sense to derive such data input from the digital building model directly, instead of manually entering all required data into a separate program. This would also be a possible future research possibility, where the digital building model would be extended with such an evaluation tests. This might be accompanied with an additional wizard to query the necessary information from the designer. However, it is preferable to derive as much information directly. Building orientation, building element compositions and room volumes would 3 4

http://www.design.ncsu.edu/cud/about ud/udprinciplestext.htm http://www.energiesparen.be/energieprestatie/index.php in dutch

246

Chapter 8. Integrating Evaluation tests

not have to be explicitly queried from the designer, since all this information is immediately available from the model. This tests is assumed to be mostly oriented at the Preliminary Design Phase, when the building permit needs to be created, but it seems to be interesting to experiment with such an evaluation tests throughout the initial design exploration, to allow a more quantifiable measurement of the performance of the concept.

8.3

Conclusion

The development of Evaluation tests is not the real scope of this research. It is assumed that separate researchers will focus on particular test algorithms and that they will collaborate to integrate these tests into the prototype application. This would give the necessary feedback to inform about the desired functionality and support from inside the prototype application. It is not even required to develop simulation tests from scratch. As illustrated with the rendering module, the integration of an external set of tools which support data input from regular text files is straightforward to implement. It is more important to provide the necessary parameters to the application to retrieve additional information from the designer. It would be beneficial if the evaluation test could retrieve as much information as possible without additional user input, e.g. by relying on the classification information. Without extended knowledge about the provided design entities, it is reasonable to derive quantities, such as areas or volumes from the different entities, when they have been properly classified. Another approach is to provide an additional wizard, where a general mapping could be set up, asking the user to connect the given entities and their classification to the necessary parameters from the evaluation test.

Chapter 9

The Project Data A design application is almost useless when the result of the design efforts can not be stored in some form. The project data has to be serialized. This can be in the form of a project file or it could be stored inside a database. The research project from Section 4.5.3 on page 121 proposed both the partial elaboration of the data structure and the configuration of a database for the building project. Unfortunately, the research budget granted did not fully support the initial research proposal and the decision was made to not further elaborate this task. However, in all scenarios there had to be some possibility of the storage and retrieval of the project data.

9.1 9.1.1

Storing the project inside a file Existing file formats

At first sight, it might seem wise to chose an existing format to store the project data. This would allow easier exchange of the project with existing applications and could allow the usage of existing parsers for the IDEA+ files. An approach to define a structure to parse and write several existing formats, such as 3DS , OBJ , NFF and a subset of the POV-Ray scene language can be found in [Rul96]. This is elaborated as the Crossroads library, but has not been updated recently. This would be a valid choice, if the IDEA+ data structure were a graphical model, containing geometry, a hierarchy and only a small amount of additional metadata, which could be stored as attributes for the geometry. In that case, it would have also made sense to adopt a format such as VRML, which supports a hierarchical set of transformed nodes, with added visual material appearance. A alternative but probably better format would be one of open CAD formats. Formats such as HSF, HMF and JTOpen have been described in Section 3.1 on page 98. Unfortunately, the concept of a full semantic building model is not easily translated in a mere graphical form. As discussed in Section 3.3.2 on page 104, the IFC format has been set up to represent a semantically rich model to describe a building project and would be a valid option in IDEA+. While this format is explicitly created to exchange building information, it is still in progress, has 247

248

Chapter 9. The Project Data

a complex conformance procedure and gives little freedom to adapt it to an existing application. The IFC format will be considered for the exchange of an IDEA+ project, but not as the internal data format. When required, an IFC-exporter could be created, allowing the IDEA+ model to be opened in any of the IFC-capable BIM-applications. As such, applying IDEA+ in the design process would still allow the continuation of the project in other applications. The scheme of Figure 9.1 displays the envisaged data exchange possibilities. They are not all available, but clearly display the different exchange paths. Geometric Data

Building Model Data

Extracted Data TXT

RAD

...

OBJ

extract

ArchiCAD WRL

IDEA+ Application

TOOLBAR HOO PS

...

3D model

C R E A T E

ADT

GRAPHIC VIEWPORT load/save

HSF

M O D I F Y

STATUS INFORMATION

Internal Data PDF

DWF

building model

IFC

Revit

...

U3D IDEA+ XML

Database

Figure 9.1: Possible Data Exchange paths from the design environment

Geometric data These are usually 3D Models from external sources, which could be imported and exported using the 3D Scenegraph1 . To this end, IDEA+ utilizes the Hoops 3D Application Framework, which is discussed on page 369. This toolkit supports several formats, for both import and export purposes. The export of the 3D model is straight-forward. The import, however, requires some internal mapping, to make sure that the imported model receives a valid function in the building model. This might be as simple as telling a 3D model of a tree that it actually represents a tree, but it can be more complex. The actual 3D geometry will not become part of the IDEA+ model, since only a reference will be stored, to reload this external file at runtime. These geometric formats have been discussed in Section 3. Internal Project Data The IDEA+ building project has to be stored in some form. At the time of writing, IDEA+ uses a custom XML-based format, which is described in Appendix 2. Future research can enhance this with 1 A scenegraph is a hierarchical description of graphical elements and their transformations, but also their graphical properties. It is a data structure, organized as a tree, which is widely used in 3D Graphics applications. There are several frameworks that implement a scenegraph.

9.1 Storing the project inside a file

249

a full database model, which would allow access to the Project Data from other applications or even online collaboration. The implementation chapter will explain how the data structure facilitates the serialization process. Extracted Data Some of the Evaluation Tests can extract data from the IDEA+ model. These include material and quantity listings, but also dedicated export routines for external simulation modules. This information can be generated from the internal IDEA+ model, but in some cases it makes sense to use the scenegraph instead. The exact geometry of the 3D Representation is only accessible in this scenegraph. Building Model Data A last option is the exchange of the building model with external BIM applications. The most suitable format for this exchange are IFC files. This would allow the IDEA+ building model to be loaded in an external application, respecting the design data. The export of the IDEA+ model to an IFC file is assumed be reasonably straightforward to implement, but the reverse poses more problems. To be able to correctly load an IFC file, a large set of the IFC defined entities should be supported, which is clearly not a trivial task. This exchange is being evaluated, but not elaborated at the time of writing. This would probably require the use of an IFC toolkit, for which some options are available online2 .

9.1.2

The IDEA+ file format

The data structure provides the possibility of storing the project as a custom IDEA+ file, supporting the full structure of the project and its elements. Since this format is not depending on any external file format, it can grow alongside the data structure. The first incarnation of the IDEA+ format was based on a VRML-like syntax, with nodes defined for all IDEA+ element types and their attributes. The biggest limitation, however, was the strict syntaxis and the requirement of the parser to know every single IDEA+ type and property. A strict syntax is not problematic when the file is computer-generated, but the second requirement places a burden on the development of the parser. Every time new data elements are introduced, they also have to be added to both the exporter and the importer routines. In an evolving system, this was not manageable. The implementation of the Property System, however, was an aid to adapt the format and have it automatically synchronized with the properties. An XMLsyntax was applied and the import and export routines were rewritten to be generic. As a consequence, they should not be rewritten or adapted when new elements or new properties are introduced. The explanation of the IDEA+ format can be found in Appendix 2 on page 417 while remarks on the property system can be found in Section 12.3 on page 281. 2

http://www.iai-international.org/software/Tools%20for%20IFC%20developers.html

250

Chapter 9. The Project Data

Why not using a Database system? The property system does not rely on a database system. In the first outline of the IDEA+ project, it was assumed that it would involve a database system. The building data would have to be stored inside a database, to allow many different application to consult it. However, during an initial research project, which was briefly discussed at 121, it was decided to not elaborate this at the time. The first prototype used a custom file format to store the project data. Several version later, the development still continues using a text-based file format rather than a database. For the purpose of this research, file serialization suffices. However, that is not to suggest that a database system would not be beneficial. The original CORE Object Model [Hen00] did use an MS Access database for the elaboration of the case study. A graphical design application was not created at the time. When browsing through the database listing, the large amount of different tables can be noted. Indeed, when directly translating the classed from the data structure into database tables, such a solution seems necessary. This is problematic, however, when the data structure is still evolving during the research. It was indeed experienced that the initial file format had to be adapted continuously, which introduced more problems than it solved. The more pragmatic approach using the XML-based format of the current prototype has at least shown a usable method to have an adaptable format, where the attributes can evolve, but the main XML-tags are never changed. The translation functions are only rarely adapted with this approach. It is assumed that the concept of the small set of tags and properties can be more easily translated into a valid database scheme, where the fields of the tables can reflect the tags in the current file format. With this experience, a next step would indeed be the translation of this XMLformat into a database scheme. Directly embedding the project data in a database would not only open the possibility of concurrent use and collaboration, but also for custom queries. The additional support for SQL queries on a project database would be beneficial for the evaluation tests, but that is not elaborated in this research. It is planned to integrate a database system gradually. This would initially involve a project library, to capture object templates and reusable components, such as materials and activities. In a second stage, the project data itself could be added as well, together with the integration of SQL queries for data extraction and possible data manipulation. At that moment, it would be possible to connect to the building data using external applications or even web forms.

9.2

Conforming to existing structures

Even though the IDEA+ format is a custom structure, the content of the IDEA+ data is not completely arbitrary. This helps in enabling mapping between IDEA+ data and other data structures, whenever needed.

9.3 Conclusion

9.2.1

251

ISO Layer Standard

The properties of CAAD Entities are based on the attributes as proposed in the ISO 13567 Layer Standard [BLK97] as discussed in Section 5.5 on page 137. Especially the notion of orthogonality is important here. Information that is independent of other information should be kept as a separate attribute. Some of the coding in this standard directly applies to the CAAD Entities from IDEA+. The Agent, Element, Status, Phase and Sector fields are used as attributes in the CAAD Entity class. Other fields, however, apply to Representation information. Adding these fields to the Representation class allows it to filter the displayed entities. These fields are Presentation, Projection, Scale and Work Package. When a CAAD Entity generates a Representation, it receives the settings from the requested Representation class, defining which Graphical Entities need to be added. This allows the CAAD Entity to take on a different appearance according to fields such as Scale or Projection. The lightweight Graphical Entities do not need to carry all this additional information. If the Representation is set to a 2D Projection, as an example, no 3D Volumes will be generated. The Graphical Entities do not have to know completely what they represent. It is enough that the Rendering classes, which call the necessary code to display the graphical entities with actual drawing commands, know the intent of the graphical entity. CAAD Entities might generate more than one type of graphical entity for one particular Representation. To distinguish between the possible functions of the generated Graphical Entities, some fields need to be carried along with these graphicals, in particular the Presentation field.

9.2.2

BB/SfB

The CORE object model describes Physical Elements in a hierarchic diagram. This is based on the BB/SfB [DNHS90] classification system. This system and its implication in IDEA+ is discussed in Section 5.6 on page 140. Since the addition of classification information allows elements to get semantic information, in the form of metadata, the possibility of filtering representations and managing elements based on their category is enabled regardless of the type of elements used. Elements can receive display properties, such as color or line types, but they can also be selectively locked or hidden based on their classification code. It also allows the export of CAD drawings with automatically generated layers, based on this code.

9.3

Conclusion

The Project Data is set up to contain the full building model, including all relations and classification information. Even though the implementation as

252

Chapter 9. The Project Data

a database system has been postponed, the implemented system can load and store Project data using the IDEA+ file format. The data structure has been set up to be flexible and is oriented to use existing standards, to facilitate possible data exchange in the future. An important future research step is the actual translation of the XML-based file exchange system into a full database model, allowing external applications to communicate with the data structure through common database connections. This would open the system for collaborative manipulation and for possible use in a web-based environment.

Chapter 10

Interacting with building data 10.1

Manipulators

Introduction A trend in design applications is the increasing support of graphic interaction with the design entities. Since the early days of graphic interfaces for operating systems, common visual operations have been made possible, such as the ubiquitous drag-and-drop and other mouse based interactions. An application such as CorelDRAW has a long-standing tradition of controlling many properties in a graphical way, using so-called Manipulators. Such an approach was not common in early CAD applications, where most program interaction took place at the command prompt or the Console. A command prompt, as shown in Figure 10.1, is the textual interface to a program such as Autodesk AutoCAD. Early versions of AutoCAD lacked menus or toolbars and even the now defunct Screen Menu was a later addition, before the introduction of menus. Remembering large lists of textual commands was the common way of interacting with the application and is still prominent in applications such as AutoCAD, Bentley MicroStation or McNeel Rhino. The console or terminal is the textual interface of an operating system and is still available in most systems. This is typically used by experienced users or administrators. The Graphical User Interfaces provide most common interactions, but some commands can only be performed at the terminal. In most cases, typing commands can be faster and more productive then using menus, toolbars and buttons.

Figure 10.1: The AutoCAD command prompt This is indicated in the study of [CMH05a, CMH05b] where an experiment involving users of AutoCAD was conducted which looked at the impact of the 253

254

Chapter 10. Interacting with building data

introduction of the Tool Palettes since release 2004. It was shown that the difference between novice and experienced users was leveled when directly using this new GUI element. At the same time, the study concluded that experienced users heavily rely on accessing the application through the keyboard interface, which has been the primary means of controlling AutoCAD since its first release. Our own experience, when teaching this application, gives similar results, where many commands that shift throughout the menu structure over different program releases are often hard to track down, yet when typing the tried and trusted commands directly on the prompt, they have been largely left unaltered over the years. Our former experience makes this access more productive than learning and relearning the position of the commands in the GUI. Some current CAD applications still have a console available, but more and more operations can be performed interactively. Software such as Autodesk Revit provides more graphical interaction, in turn influencing the development of its sibling Autodesk Architectural Desktop.

10.1.1

Manipulators in design applications

Autodesk Architectural Desktop AutoCAD has since quite some time supported grip editing. This is used to drag a point from a line or polyline to another position. The cursor snaps to the grip and color creates a distinction between selected and unselected grips. This is combined with tooltips, guidelines and editable text fields to provide a more graphical approach to editing, as shown in Figure 10.21 .

Figure 10.2: Grips editing in AutoCAD Architectural Desktop added more enhanced grip editing to the architectural objects, such as the height of a wall or the opening direction and the size of a 1 The screenshot is a simple rectangle where one vertex is being moved. The user is overwhelmed with information. . .

10.1 Manipulators

255

door, as shown in Figure 10.3. Influenced by both Revit and ADT, an improved grip editing was also introduced with the AutoCAD 2007 release.

Figure 10.3: Manipulators for a simple door in ADT

Autodesk Revit Revit has used elaborate editing of properties since the beginning. This ranges from the dragging of an opening, to the graphical setting of certain properties of library objects, or families as they are called in Revit. This is illustrated with a door in Figure 10.4.

Figure 10.4: Manipulators for a simple door in Revit Revit also supports dimension driven design, where the editing of the dimension string actually transforms the measured geometry. This is quite common in Mechanical CAD software, but at the time of writing Revit is the only Architectural CAD software using that approach2 . 2 To be more correct, Bentley MicroStation has support for dimension driven geometry, but it is not utilized in the common workflow. It is more a utility for experienced users.

256

Chapter 10. Interacting with building data

Graphisoft ArchiCAD Many manipulation operations in ArchiCAD are guided with graphical markup. The rotation of an Element actually displays reference lines and the reference angle, to better preview the operation. Since ArchiCAD 8 interactive hotspots can be added to library objects, written in GDL. The opening of a window can be set numerically or graphically as shown in Figure 10.5.

Figure 10.5: Manipulators for a simple door in ArchiCAD ArchiCAD 10 introduced huge improvements in the interactive editing, with the guides and the Tracker. Guides, which are displayed in Figure 10.6, are automatically displayed during editing, based on nearby entities. They can take the form of magnetic reference lines and angles, helping cursor movement to parallel, perpendicular or orthogonal movements. The user can define intersections of lines, without any additional entry but still with full CAD accuracy.

Figure 10.6: Guides in ArchiCAD The Tracker is a floating palette with numerical values which are relevant for the current operation. This is shown in Figure 10.7, where the user can start typing while graphically editing, so accurate numeric input is still possible.

10.1 Manipulators

257

Figure 10.7: Tracker in ArchiCAD

Google SketchUp

Other design applications, such as Autodesk 3ds max or Google SketchUp have been making more extensive use of manipulators than CAD applications, as shown in Figure 10.8. It is only the last few years that showed an increased interest in providing this interactivity in CAD software too3 .

Figure 10.8: Examples of manipulators in SketchUp

3 In fact, since AutoCAD release 2006 the command prompt can be optionally detached from the viewport border, where it becomes a floating information palette, following the cursor around on the screen with an optimized and shortened set of commands.

258

Chapter 10. Interacting with building data

10.1.2

Research Example

Oh and StÂ¨ urzlinger [OS03] and [OS05] describe several issues with regard to accurate graphical manipulation in a CAD system4 . They have researched an approach to manipulate compound objects graphically. Their system allows Group Separation, where arbitrary parts from composite objects can be graphically separated and assembled using mouse gestures. They also suggest a new movement technique, inspired by modeling with Lego bricks, allowing to interpret drag-and-drop movements into accurate positioning of elements, based on minimizing translation and choosing between possible candidate positions based on a maximal screen overlap. Studies such as these indicate that there is still a potential of improving the use of CAD software, where accuracy is required, with graphical methods that are less exact, without compromising on the correctness of the results. It is important in the discussion on Manipulators to understand that they are used for easier graphical manipulation, without giving up on accuracy, as required in a CAD system. Object snaps, which are common in many current CAD applications are a good example. In the early days of CAD software, people could create exact drawing by typing coordinates only. This was, however, augmented with snapping tools, allowing the user to interpret a mouse click into a special coordinate, such as an end point or an intersection. However, initially this involved the user typing additional commands before the mouse click, severely slowing down the drafting speed. Recent applications still support these snapping tools, but with no additional data entry. Most relevant reference points are continuously scanned and they are highlighted interactively while drawing. The final drawing is as accurate as with previous methods, but the effort for the designer has diminished considerably, up to a point where novice users sometimes fail to understand the importance of such accuracy.

10.1.3

Manipulator types

To be able to manipulate CAD data with user interface widgets or items, they need to combine both ease-of-use and accuracy. To that extent, the main characteristics of such manipulators are briefly discussed here. Intuitive data entry widgets A widget can be defined as a user interface element for data entry. Most applications use a wide variety of widgets, to enable the user to control the application and the data that is being edited. Typical examples include text boxes, sliders and buttons. It is possible to combine many widgets into one, to set multiple related parameters, such as option check boxes or color pickers. Each widget is by its nature connected to some data type. 4

http://www.cs.yorku.ca/â&#x2C6;źwolfgang/publications.html

10.1 Manipulators

259

A text box is used to edit text strings or even large bulks of texts. The interaction with the document in a text editor occurs mainly in a large text widget, which even might display color and formatting. A table-style widget is the main data entry widget used in a spreadsheet application. Similarly, one could imagine the graphical view in a 3D or CAD application to be a data entry widget for graphical documents. However, in this discussion, the focus is actually on widgets that might be used inside such a graphical window or as manipulator widget for property dialogs. The following list, defines common manipulator types and their respective associated data types. Point-dragger Manipulating points in a graphical window is usually performed using the mouse. Control points can be selected and translated directly, without data entry. This translation is usually constrained. Points are commonly dragged alongside a line or within a plane. A point-dragger is a simple graphical representation of a point. The type of representation is dictated by the movement constraints that are applied. Arrows are typically used to depict available movement directions, while arcs or circles can indicated available rotational freedom. While the dragging of the mouse on screen occurs freely, the actual movement might be filtered to discrete steps, such as grid positions or snap positions, such as intersections or endpoints. Slider This is a common widget to define a number within a specified range. It is easy to manipulate and can limit the user to enter only valid numbers. A typical example is used with the setting of a color, where each value of the Red-Green-Blue triplet can receive a value between 0 and 255, to define a 24-bit color value. Switch This is used to control a Boolean parameter, having only two possible values, such as true or false and on or off. A single click toggles between the available values. Adding/Removing items In some cases, it is convenient to allow the insertion or deletion of items inside a list, such as the corner points of a floor contour. Requirements and Constraints To enable manipulators, they have to relate to particular properties and be constrained. It is technically not possible to create a slider widget with infinite reach5 . The application developer has to define the range of values and the allowable intermediate steps. In a flexible application, this range and the step sizes have to be derived from the available properties, rather than being fixed in the source code. 5 In some cases, developers use tricks to make sliders adaptive to wide parameter ranges, but typically many sliders use an internal integer that allows 128 discrete steps.

260

Chapter 10. Interacting with building data

Application of manipulators in the prototype While the data structure itself does not require support for manipulators, the prototype application benefits from graphical interaction. This is mainly used when manipulating Reference Points, since they are the predominant item to manage the structured building model. The current implementation applies manipulators with custom Operators. When the user chooses to create or manipulate the Reference Points, clicking and dragging of these points will be used to manipulate them. • The Create operator allows the user to click on the working plane to insert Reference Points. Each click appends a point to the entity being created. • The Insert Point operator will interpret each click as a position to insert a new Reference Point into the currently selected entity. • The Remove Point operator will remove clicked Reference Points. • The Modify Point operator is used to drag a Reference Point to another position. All of these operators use the current Working Plane and will obey the current Grid settings. This allows to quickly modify the design entities, using only the mouse. In future research, manipulating local object parameters for design entities can be elaborated. This requires to generate custom Manipulators, based on information derived from the Design Entities at runtime. While this was already tested in an isolated prototype, it was not carried out in the current prototype, due to time constraints.

10.2

Expressions & parameters

For a designer, many design entities are related. An element can have the same height as another one. Or an element is aligned to another. In most Architectural CAD software, such relationships are not explicitly stated. The designer has certain ideas, but they are not embedded into the project data. In Mechanical CAD software, however, there is more support to store such design decisions into the project. Constraints and Expressions materialize design ideas as actual project data. In dimension driven design, the measurement becomes a driver for the geometry and by defining expressions between dimensions, relations can be enforced. This is precisely the objective of the Property Connections in the IDEA+ data structure. All common classes support the linkage of properties, enabling a way to store design decisions into the objects. Properties can be linked, if they share the same data type. This linkage can have a direction, which states which property is calculated from the other. There is also support for bi-directional

10.2 Expressions & parameters

261

linkage, forcing two properties to be identical at any time, regardless of which property is adjusted. The uni-directional linkage can be extended with an Expression. This is a formula which defines how one property can be calculated from another property. It should even be possible to define an Expression involving several properties. This is quite similar to the formulas in a Spreadsheet application, where cell values can be calculated from the results of other cell values.

Chapter 11

The Geometric Model 11.1

The complexity of translating building geometry into a digital model

Modeling software in general can be used to create any kind of geometry. There are software limitations obviously, but most geometric forms are creatable. In architectural design, however, there is a tendency to limit the kind of geometry that can be modeled. Most architectural design software focuses on the construction and documentation phase, where most effort is spent on the generation of construction drawings. These are 2D technical layouts, using a combination of linework and annotation. Most 3D modeling in these architectural software applications is based on drawing outlines and extruding them to give them height. This is quite commonly accompanied with control over transformations, which are a combination of translations, rotations and scaling operations. But that is usually the scope of architectural modeling software. Support for freeform modeling, such as in the dedicated NURBS modeling software McNeel Rhino, is almost non existent. Programs such as Autodesk Architectural Desktop, Autodesk Revit and Graphisoft ArchiCAD have almost no support to create double curved surfaces directly. They all have possibilities for basic 3D modeling and through the linkage with external modeling software, such as Google SketchUp or Maxon Cinema4D, support for arbitrary complex geometry is promised. This is rarely a problem since most designs are adequately described with only 2D drawings for the different floor levels. But a building can have characteristics that make it hard to model accurately and completely with current architectural design software. Especially renovation projects suffer from limitations in these widely used software applications, where many relatively common building details are hard to model. In 3D any geometry is creatable, but many freeform volumes are hard to represent in 2D drawings. The simplest approach is generating a slice through the 3D volume. This is usually combined with a projected top view of the volume below the cutting plane. But 2D representations suffer from clarity. Adding sections and elevations improves the documentation, but none of these basically 2D drawings fully represent the volume. 263

264

11.2

Chapter 11. The Geometric Model

Geometrical limitations in building models

The following paragraphs illustrate a few of these geometrical limitations.

Walls are vertical Most buildings have vertical walls, which is usually the only type of wall that is supported in BIM software. Non vertical walls and slanted walls pose specific modeling and representation issues. Autodesk Architectural Desktop can model non-vertical walls using custom wall Profiles. Any object can be freely transformed, using a transformation matrix, but although this is mathematically not really complex, it gives little control to the user. Autodesk Revit allows the import of freeform surfaces, which can then be turned into valid building elements, allowing them to be fully integrated into the building model. This clearly puts the focus on integrating any geometry into the philosophy of the Building Model, but this geometry can not be created in the Revit software itself. Graphisoft ArchiCAD supports slanted walls, columns and beams since release 10. This poses some additional problems, mainly for the plan view, forcing the program to add options for the representation of individual elements, such as the choice between a conceptual drawing and a projected drawing. There is support for complex cross-section profiles, but they can not generate doublecurved surfaces and they are not fully measurable, at least in the current version of the software at the time of writing. And that is not all. If an application supports the import of complex geometry or if it can create the geometry itself, it also has to integrate this geometry in the building model. It is not enough to model a geometry to represent a sloped wall, when the user is not able to treat and manage the object as other wall objects. The user should be able to decide not only where an opening is inserted, but also how it behaves. They might have to be placed vertically or they might follow the slope of the wall.

Sloped elements Most buildings have horizontal floors. This is not only easy to draw and model but is above all the most practical solution for the function of a floor, which is carrying people and furniture. If a BIM program only supports horizontal floors, sloped surfaces could probably be modeled with a roof tool, which is bound to support a slope parameter. But then the designer is actually creating a semantically incorrect model. It could be argued that only the end result counts, but using elements for other functions might pose many problems in the interpretation of the building model. When people interpret drawings, they usually ignore these differences, but in an increasingly automated environment, many of these checks and evaluations are

11.2 Geometrical limitations in building models

265

being performed by computer algorithms. Ambiguities in the building model might negatively affect evaluations. The Dutch architectural office of MVRDV created the Villa VPRO project in 19971 . In the facade, shown in Figure 11.1, one of the floors bends around from one level to the level above. Even though this can be quite easily modeled in most 3D applications, since it is merely a straight extrusion of a curved profile, it poses ambiguities in the building model. The floor blends into a wall and then back again into a floor. It is not clear how this should be organized in the building data. If it is modeled as a continuous volume, it might be modeled as a floor, but most BIM applications have no support for this geometry when using floors. If the user tries to model it as separate floors and walls, it is not clear where to make the distinction between floors and walls.

Figure 11.1: Villa VPRO In the end, this might not even matter that much, since calculations and on site construction are based on materials, rather than on functions. The semantical structuring of the building model is apparently mostly a problem for the architect. Other involved parties, such as clients, often need only the representation rather then the building model. This might change in the future, so a better understanding and support of building semantics will be helpful.

Non-constant thicknesses Most floors and walls have a constant thickness. This is the case for both real building projects as well as architectural modeling applications. In a design context, it is quite often undesirable to have non-constant planar entities, unless they serve a certain esthetic goal. But modeling an existing 1 The Project is illustrated at the MVRDV website http://www.mvrdv.nl/ v2/projects/ 010 villavpro/index.html

266

Chapter 11. The Geometric Model

building accurately is more likely to require walls with a varying thickness, amongst others. In a polygon-based modeling environment, it is quite easy to start with a simple form and then drag individual vertices around. The added support of inserting vertices in the mesh topology, combined with several tools such as slicing and welding completes a full polygonal modeling system. This can be used for almost any possible volume and this is the main focus for digital content creation and game modeling environments, such as Autodesk 3ds max or Newtek Lightwave. Architectural and mechanical CAD software usually has only very basic support for mesh modeling. These applications focus on solid or surface modeling and, at least in the case of mechanical software, accurate NURBS surface modeling. With NURBS modeling software, it is quite easy to adjust control points, but this is less obvious in solid based modeling. Architectural modeling software mostly inherits drawing features and solid modeling features from generic design applications, usually without any support for editing and creating NURBS or polygonal models. With solids created from extrusions and lofts or sweeps, it is possible to adjust the modeling history, but at the same time it is almost impossible to adjust the final form further, when the original modeling history has to be retained. Even with the improved parameterized modeling features of AutoCAD 2007, which features extended grip editing, the user still has to be very creative in applying these commands in less straightforward manners. A parametric solid can be modified according to its parameters, but the moment actual vertex editing has to be performed, the initial modeling history is usually lost. An application such as Autodesk 3ds max has a partial solution in its modifier stack. The operation is performed as a modifier, which implies that it is parametric and there is still full access to the previous steps in the history, even in an non-linear fashion, since the stack can be reordered at will. What makes it less flexible is the fact that some of these modifiers are by their nature history based. An Edit Mesh modifier can store adjustments to any of the geometric levels of the mesh, such as points, edges or surfaces. This modifier can capture editing operations such as insertions, transformations and removals, with operators such as beveling, extruding, chamfering and welding 2 . But this is based on the indices of these entities inside the underlying non-deformed mesh. This index is likely to swift with changes in the underlying geometry, making the dependent modifier more than likely defunct when the source geometry is adjusted, such as when changing its parameters. There are built-in warnings, which point the user to these limitations and some modifiers provide fully parametric behavior, such as a volume selection, instead of an index-based selection. Even when the user rigorously applies only parametric operations, it is quite likely that the full modeling history has to be collapsed, so the parametric history is fully lost. This usually happens for performance reasons or when other operations require a mesh geometry rather than a parametric geometry. Related softwareâ&#x20AC;&#x201D;such as McNeel Rhinoâ&#x20AC;&#x201D;also focuses on powerful modeling operations, at the cost of losing the modeling history. 2 To

describe all these modeling methods is beyond the scope of this text.

11.2 Geometrical limitations in building models

267

In parametric modeling systems, which promise editability through their creation parameters, it is only easy to create changes that are catered for by the parameters. Every change that is not directly supported by the parameters is a complex and mostly manual modification, which can be invalidated with changes in the underlying topology. And changes take the core time of most design sessions. To conclude, it is clear that a parametric modeling system is only as flexible as its pre-programmed parameters. It is therefore understandable that full flexible modeling, in the sense that it is achieved with polygon modeling, is not fully compatible with parametric modeling.

Curved surfaces In current architecture, most building forms are orthogonal and flat. Walls are straight, floors are flat and roofs have a single slope angle. When an arched form is used, it is usually a single-curved surface, based on the extrusion of a circle or arc segment. This is supported in most architectural design software. Whenever more complex geometry is required, many applications fail to support the modeling in an architectural context. While some applications support the creation of curved surfaces, either by modeling or by importing from external applications, their management in the building information modeling context is quite limited. Even when the application can load this geometry into the rest of the 3D model, limitations arise with the plan representation and with the integration of the semantic data in the full building model. The geometry is not managed as a full intelligent building object, which makes it behave quite differently from the rest of the building objects. Double curved surfaces that are said to be walls, might not support the insertion of openings or the full correct calculation of its composition and materials. Many applications only support the representation aspects of the building model, allowing plans, sections and elevations to be created at best. As a designer, it is logical to expect these surfaces to react as regular building volumes, allowing sections, with appropriate hatching, but also correct dimensioning and material takeoffs. When this is not supported it becomes hard to categorize such an application as a fully integrated building modeler. A room enclosed by double-curved walls should still react as a room in the building context, yet the calculation of a correct room area and room volume has to be supported too. This is not always easy. Depending on the context, it has to be possible to calculate areas with different calculation methods, e.g. excluding the area where the ceiling height is less then two meters. While it would be possible to model these areas separately, it would be better that the calculation method itself is supported by the BIM software. Mechanical design software, on the other hand, is more supportive for the modeling of curved surfaces. But products and machines follow different rules when compared with architectural elements. Fillets and Blends 3 are almost non3 Two approaches to let one surface connect smoothly to another surface. In product modeling, surface continuity is an important design goal.

268

Chapter 11. The Geometric Model

existent in buildings, where the majority of corners are edged. This is largely a result of material properties. Most physical building elements are assemblies of smaller entities, such as bricks or beams. And even though each single brick has a predefined fixed format, its application and assembly on site often implies modifications, such as splitting and small manual adjustments. A curved wall is built from straight bricks, which lack any curved property inherent in their individual form. Most manufactured products are assemblies of fixed form parts, which are each made of one homogeneous material. The assembly positions them but without any deformation or manual adjustments. Any movement is explicitly supported through the design of the part, such as hinges or positioning fasteners. Many of the building construction objects are linear in nature. They might be created by extrusion or by sectioning, but there are usually no curves in their individual form. Fully curved building entities can be divided in two categories. Smaller accessory objects such as a bath tap or door handles are in fact products that are designed and manufactured with the tools from mechanical engineering. They are used “as is” in an architectural context, but the focus of an architectural design application is clearly not the modeling of these accessories. On the other end of the specter are the walls, roofs and floors, which are assembled on site and hardly ever contain fully curved geometry. The exceptions are curved beams, which are either prefabricated—as with steel or pre-stressed concrete—or they are cast in situ, in a curved mold. But even then, the mold is often not fully curved, but rather facetted from planar wooden plank castings. Bending standardized steel profiles is also an operation that has no counterpart in mechanical or product modeling, apart from sheet metal design. Creating curved wooden furniture on the other hand, using high-pressure in a moistened environment, is used, but not on site and it is not applied in building elements, but rather in prefabricated accessories.

Layered Compositions A concept that is very common in architecture are layered compositions. Many building entities use assembled materials. Typical examples include a cavity wall or a roof construction. In reality, they are an assembly of materials. To the architect, however, they act as one design entity and are thus modeled as such. When a cavity wall is seen as one entity, its model has to contain the full composition. This is supported in most BIM applications as a single definable composition, which can be shared between all elements that have the same construction. Some applications support only the sequence of material layers, each layer supporting a reference to a material and a thickness. Others add additional position properties, such as top and bottom offsets, which support more complex compositions.

11.2 Geometrical limitations in building models

269

This is a concept that is unique to architectural modeling and which has no real counterpart in mechanical software. There are some common difficulties with layered compositions. â&#x20AC;˘ Most applications have limitations in connecting layered compositions to other elements, such as in a wall-floor connection. In reality, there is no such problem, since each layer is individually constructed on site, rather than as a prefabricated layered plate. Through the addition of priorities to layers, most applications can support common intersection problems, where elements can be split to make room for layers with a higher priority. And when the architect meets a situation which can not be solved with the layered entity, it is always possible to model the individual layers as single-layered planar elements, which are then more flexible to model, but which loose their connectedness. They are also problematic when openings have to be inserted, since they have to be added to all layers separately. â&#x20AC;˘ As long as the layer is homogeneous, one composition is enough to define the composition of the planar element. In the case of a framed wall construction, the individual parts of the wall define the material quantities and a specific framing distribution has to be derived, taking into account openings in the element. In a Sketch Design Phase, it is not necessary to model the element with this amount of detail, but a firm specializing in framed buildings might require very accurate detailed wall and floor constructions. There are even dedicated software solutions to generate accurate framing plans from a building model. This is not the focus of this research. â&#x20AC;˘ Layered compositions are hard to combine with planar elements with varying thicknesses. If this is the case, some applications support one varying layer, which captures the thickness change. In other cases it might make more sense to actually model the individual layers independently. The reason why this makes sense is the fact that it makes little difference to the building model wether a wall is made as one compound layer or as individual layers, for certain evaluations, such as a materials quantity takeoff. Such solution might be more problematic for spatial modeling evaluations, since there is no longer a single enclosing element available.

Split Levels and Stair Cases Most buildings have layouts which can be quite accurately described with 2D plan drawings. Each plan represents one floor and floor levels are constant throughout the building. An application such as Graphisoft ArchiCAD is entirely based on a concept of modeling floor by floor.

270

Chapter 11. The Geometric Model

Every time the building breaks through these floor levels, problems arise. Split levels and stair cases are usually quite difficult to model correctly, since many operations in a building modeling application are floor level oriented. In floor level oriented applications, the user has to invent a work around to model buildings which do not follow the subdivision into floor levels. In some cases, the modeling environment becomes a hindrance to the building model. Another example is the approach of Autodesk Architectural Desktop, where the project is split into different files for different floor levels. This is not a real problem for most designs, unless a certain representation encompasses more than one level. In a stair case, it is common to show the underlying stair flights and when there are floor openings, it is often necessary to show at least a partial projection of the underlying floor level. This is almost trivial when a section is a cut with underlying projected view through the full 3D model, but when a floor level is an independent file, it has no access to the other levels. This is solved with additional references, which are used as overlays, but they make the building model more complex than necessary, regarding the sometimes trivial building layouts that can not easily be represented. Adding manual linework to complete the drawings is totally disconnected from the actual building model, requiring all synchronization to be done by the user instead of the system. Graphisoft ArchiCAD at least supports the visibility of entities on other floor levels, which helps the user break through the barrier dictated by the floor level oriented interface. When the architect envisions floor levels as being non-constant and where some floor levels may even merge with others, through the use of slopes or void spaces, common building modeling applications have no real solution to support this concept. It is remarkable that designs such as the H2O Expo Pavilion of Nox Architects 4 which was designed and realized between 1994 and 1997, are not modeled with architectural design software, but rather with product modeling software, ignoring the common vision of floors and spaces, but focusing on the construction and assembly. It can even be discussed wether it makes sense to create 2D sections through such a building, since most of the sections would not be able to show elements with their real dimensions. The creation of 2D drawings for such designs is usually more an administrative obligation than a construction requirement. In the particular example of the H2O Expo Pavilion however, the sections shown in Figure 11.2 are actually taken on the place of the structural truss assemblies, which results in accurate 2D drawings for the manufacturer. The building model can be used directly to generate output usable by a manufacturer, such as laser cutting data or listings of profile lengths. The importance of 2D drawings diminishes with these kind of projects. 4

http://www.noxarch.com

11.3 Conclusion

271

Figure 11.2: H2O Expo Pavilion

11.3

Conclusion

While ideally, digital building models would enforce no limitations on the design, certain simplifications for the enabled geometry are common in most design applications. It is argued that these limitations are in many cases of lesser importance. However, recent evolutions in digital modeling are increasingly influencing designers, who incorporate freeform modeling tools in their design practice. Some architectural offices have consequently taken this from design till manufacturing and have adapted their design process to accommodate these tools. While total geometric freedom would be very desirable in an architectural design application, the data structure has several limitations. They are motivated by pragmatic reasons and time constraints. The chosen subset of graphical entities is limited but is assumed to be valid, nonetheless. The current data structure provides a set of graphical entities which can be used to generate representations for design entities. They do not cater for any possible geometry type and do not contain circular curves or curved surfaces. They do provide a few methods which can be used to define a wide variety of building forms and will be discussed in the implementation Chapter 17.

Part III

Implementation: IDEA+ as a prototype application

273

Implementation Introduction The following chapters will elaborate the proposed concepts, through the implementation of the data structure and an accompanying prototype application, called IDEA+. The data structure is created as a modular class structure, starting from a generic but flexible Property System, on which the rest of the structure relies. This structure is set up using Object Oriented Programming (OOP) techniques, to remain flexible and generic. Special emphasis is placed to ensure portability between different computer platforms and to remain independent from external libraries. This approach leaves open the possibility for possible future integrations of these concepts into existing design software. To interact with the data structure, a prototype application is developed. This application is used to create the design entities to construct a digital building model. The application also explores techniques to request information and and manipulate the design. The application serves as a testing bed for the data structure and illustrates how the different concepts could be enabled in architectural design applications.

275

Chapter 12

The data structure 12.1

Introduction

To be able to manage a building project in a digital form, we need to decide upon a data structure that is able to capture the desired design information. It is required that the data structure be set up in a flexible and generic way. If we qualify a design as “the problem of defining an unknown number of elements, with an unknown number of properties, following a work flow that can not be predefined”1 , it is not an easy goal to provide a framework that can capture this peculiarities. The data structure needs to be rich in semantic meaning, to limit the use of metadata. When more information is available, fewer “data about data” are required. At the same time, a well-defined set of metadata is applied, to generically structure all design entities. This utilizes the BB/SfB [DNHS90] classification system. This is particulary useful for a generic filtering of elements, as will be explained in Section 5.6. The proposed data structure2 is partially realized, to a level that is sufficient for a prototype application. The main focus of this implementation is to demonstrate a usable subset of building elements and a workable feature set. This will allow us to investigate the functionality needed for design description, project storage and evaluation tests. At the same time, we suggest an approach for Design Phase and Scale Level transitions.

12.2

A modular data structure

The data structure is divided in a few modules, containing related families of classes, as illustrated in Figure 12.1. This modular structure strictly defines the allowed dependencies between modules and influences all implementation decisions. The Extra module contains the serialization functionality, while the Events module defines all available commands. They are implemented unaware of the actual prototype that utilizes 1 paraphrasing

[RW73] chapter is written with the assumption that the reader has a general understanding of programming concepts and in particular of Object Oriented Programming (OOP). The implementation will use C++ but the text will be largely independent of the chosen language, where appropriate. 2 This

277

278

Chapter 12. The data structure

Base

Graphics

CAAD

Extra

Events

Tests

Data Structure

IDEA+ Prototype

Figure 12.1: Main structure of the prototype them. It is only on the level of the prototype that the user interface and application interaction is defined. Base containing generic objects, lists, text, color, data types, constants and macroâ&#x20AC;&#x2122;s. Graphical containing objects for geometric representations and calculations, such as points, vectors and lines, but also matrix calculations and transformations. CAAD containing the main architectural objects, such as physical elements, their composition and type, conceptual elements and their relations or links. This module also contains the classes for Representations, which handle the connection between architectural elements or CAAD Entities and the graphical entities that are used to represent them On the application level we also have a few modules. Extra All functionality to export and import projects to external files. Tests These classes describe how a test can work with the main object model. Events Commands and Events, which contain the low level functionality needed to work with the object model. To create a workable prototype, the data structure and the application use two frameworks. The GUI Framework takes care of the management of windows, dialogs and all other widgets, which define the user interface. The 3D/CAD Framework defines a scenegraph and contains methods to display 3D objects

12.3 Base Module

279

3D/CAD Framework

Data Structure

Prototype

GUI Framework

Figure 12.2: Connection between Prototype and Frameworks and interact with them, graphically. This is displayed in Figure 12.2. At this moment, it does not really matter which frameworks will be actually used. The next paragraphs give an overview of the main classes3 which are needed to describe a simple building model. With this chosen subset, a full project can be described. The grouping of classes reflects the chosen modularity, where dependencies between modules are strictly defined.

12.3

Base Module

The Base Classes contain general objects and methods for the management of different objects, properties, color, text and lists. They also contain utilities for calculations, preprocessing, compilation, debugging and logging. Within the Base Module, the IDEA+ Property System is located. This system implements the data structure as a hierarchic tree of objects with properties and possibly containing lists of other objects.

12.3.1

Main classes in the Base Module

Base Main class, from which most other classes are derived. This class provides the possibility of setting and retrieving properties in a generic way, allowing to handle most classes in a similar approach. Each Base class can have properties such as real numbers, text and integers, but also references to other objects and lists of objects. These classes define the IDEA+ Property System. RCHandler Through the use of reference counting , the total amount of references to objects is monitored. As a result, objects can be automatically cleaned up when they are not required anymore. This is a simple method 3 All class names are actually preceded with CIDEA, but this is omitted in the text to enhance legibility.

280

Chapter 12. The data structure to provide some of the advantages of Garbage Collection systems which are used in other programming languages, such as Java4 or C#5 . This is important, since many objects can be shared, which implies that multiple references to these objects will exist. Only the last reference has the right to clean up or delete the object, so the memory that it used is released.

Color & Shader The main visual properties, for the display of graphical elements. A shader contains common properties such as colors for ambient, diffuse and specular material components and visual qualities such as transparency and translucency. Lists & Vectors To be able to store objects inside lists, a generic list-class is set up, based on the Standard Template Library (STL) [MS96], allowing to have a generic access to lists of objects and lists of references to objects.

12.3.2

Dimensions and Measurements

There was no specific support for actual sizes in the Object Model. Quite similar to the classic use of a program such as AutoCAD, the whole system used real numbers to define sizes, but no decision on the actual size of one unit was proposed. For a modeling or drawing application, this does not pose many problems, but from the moment quantitative information is required, actual dimensions need to be correctly defined. The current implementation assumes all units to be expressed in Meters. There is no real Dimension data type yet and no conversion from input and output dimensions with the internal unit system has been set up.

12.3.3

The Property System

Properties or characteristics of entities are predefined. They are embedded in the source code of a program and need a dedicated set of methods to access them. This is quite common in most programming languages, but it poses a problem when implementing a complex and large system. To be able to modify the properties of any entity, dedicated tools need to be written. This can be done in the form of a simple dialog or as a complete graphical manipulation interface. In both cases, the system needs to be adapted when new objects or classes are introduced. Experience with the earlier prototypes warned about the feasibility of such an approach. Creating a custom interface element for all different entity types is almost impossible and is also a maintenance nightmare. Each and every modification of a class definition requires adjustments on several places in the system. 4 5

http://www.java.com http://en.wikipedia.org/wiki/C sharp

12.3 Base Module

281

And the task becomes larger when the whole data structure has to be serialized. The export of the data in memory to a file or database and the correct import of the same data to fully restore the Project data is quite elaborate. In [GHJV95] there is the memento pattern dealing with serialization from an entityâ&#x20AC;&#x2122;s state to a persistent file. But this only solves a part of the problem. Partly based on concepts from Java and MFC serialization, a generic approach to access properties was established. The main concept borrowed a technique from Charles Cafrelli [DeL01, Chapter 1.7] describing a system to access properties of any object through the same interface, if these properties had been registered with the application. This example was adapted and further elaborated, using optimizations and methods from other game programming books [DeL00] [Llo03] to form the basis of the IDEA+ Property System. Properties and Property Sets Each class that needs to be persistent derives from a Base Class, which enables generic access methods to all properties to be maintained. A property has to be registered by the developer, when it is deemed important enough that it has to be stored inside a database or file. All registered properties can be retrieved during an import operation. Internal object parameters that are only required at runtime do not need to be registered. The registration of a property gives the system generic access to it. Common data types are supported, such as Boolean values6 , integers, real numbers, strings7 and enumerations8 , but also references to other objects and lists of objects.

RCBase

PropertySet

Property

<<use>>

PropCategory

union Base

Label

<<use>>

RCHandler

IContainer

double

Vector

int

string

bool

color

Actual Class names preceded with "CIDEA"

Figure 12.3: UML scheme for the IDEA+ Property System The availability of this property system offers some important advantages. â&#x20AC;˘ The application adapts itself to newly registered objects at runtime, instead of writing specific interface elements for the different design entities. To avoid creating a separate dialog to edit each class, one generic Property dialog is used. Each property is automatically inserted as an entry in the 6 true

and false an std::string 8 Lists of strings, to represent alternatives for a value. 7 Using

282

Chapter 12. The data structure dialog. Upon activation of a specific property, a widget is loaded as an editor for this property.

â&#x20AC;˘ At the same time, the serialization process has become generic. The export and import operations completely rely on this Property System to query all registered properties, write them in an external file and then import them again. Adjusting the data structure, either through the addition of new classes or through the modification of registered properties, does not require any changes to the import and export routines. More info on the IDEA+ format in Appendix 2 on page 417. â&#x20AC;˘ An additional feature of the Property System is the possibility to extend the list of registered properties at runtime. The internal object behavior will not change when custom properties are added, but evaluation tests might rely on them or the user can choose to engage them in the project. These Extended Properties are managed in a similar way as the regular Base Properties, also allowing them to be serialized alongside the regular data. This is described in further detail in Section 15.1 on page 335. This is an important achievement for a data structure evolving alongside the prototype application, which is quite common in research projects and prototype development.

12.4

Graphical Module

The group of graphical classes are meant to contain the generated graphical representations of objects. They are not platform-specific and do not provide means to be drawn on the screen. They are used when elements generate their representation and are then translated by a rendering method to display them for a particular graphical engine. The representation is thus usable in many systems. When supporting a new graphical engine, only the translation of these graphical entities into drawing routines is required, independent of the underlying building model. This module contains different graphical entities, such as lines and polygons and also definitions for solid volumes and operations. This module, however, does not rely on any particular geometric kernel or engine, to make the data structure portable. As such, the Graphics module should be regarded as an intermediate graphics language, without actual drawing or modeling code for screen or print. This module does contain most important geometrical operations, such as matrix transformations, distance, area, volume and intersection calculations and different utility methods for geometry generation. The resulting graphical entities do not derive from the regular Base class, to keep them lightweight. This implies that they are not following the same structure as the other classes in the property system. This is motivated by the fact that a single entity from the property system might generate several graphical entities, which need to be regenerated in real time, following all modifications of the generating entities.

12.4 Graphical Module

283

Point A point in space. This contains regular 3D coordinates but also homogeneous 4D coordinates [FvDF+ 93, chapter 5.3]. There are some utility methods for common calculation questions with coordinates, such as cross and scalar products, the conversion to polar coordinates and calculation of distances. Line The connection of two points. Some methods support common required calculations such as projection, direction and options for parallel and perpendicular lines. Polygon A series of points on a plane. With only three points, it is guaranteed that they are in the same plane. A polygon with more points has to be triangulated. Since triangulation algorithms can become quite complex to capture all exceptional cases, this is not embedded in the polygon class. This stays the responsibility of the graphical engine. Solid An abstract class to manage solid operations. They contain only the management of the graphical objects. The actual mathematical operations required for full Boolean operations is the responsibility of the graphical kernel and is not implemented in these classes. They include Compound Solids, for Boolean operations, Polygonal Solids, which are created from a list of Polygons, Sweep Solids, which sweep a profile along a path and Primitive Solids, which are simple boxes and cylinders. Matrix Necessary for translations, rotations and scaling. Coordinate System Used for the transformation of objects. Utility methods are added for the transformation between local and global coordinate systems. Other Classes can be added when required. Since they all derive from a common graphical class, it is easy to extend the existing classes.

Graphicals

Point

Line

Plane

PrimitiveSolid

Matrix

Polygon

PolySolid

Solid

Coordinate System

Text

SweepSolid

Figure 12.4: Graphical Classes

CompoundSolid

284

Chapter 12. The data structure

12.5

CAAD Module

12.5.1

Main classes of the CAAD Module

Relying on the Base and Graphics modules is the CAAD module, containing all architecturally meaningful design entities and the Project class. Different CAAD entities make instances of the generic graphical entities, to define their representation. When required, the actual application will request a list of graphical entities from the CAAD entities, which will then be traversed by a render class, to call the necessary drawing commands. This ensures independence of the underlying modules from any particular operating system or graphical engine. The group of CAAD Classes are used to describe the actual building model. Project The building model is a project, containing lists of elements and all shared objects. A project can be stored and retrieved as an IDEA+ file. Element The main building element, which contains both a semantical meaning in the form of CAAD Entities and a possible graphical representation, in the form of Graphical Entities. CAAD Entity These entities contain most of the building information. They can also contain links to other CAAD Entities, providing a way to store relations between entities. Graphical Entity A CAAD Entity can generate graphical entities for all required representations, but an Element can also contain independent Graphical Entities. Library Element These are entities that can be referenced by multiple elements. They are usually not Project-specific, allowing them to be reused in other Projects. Material All Physical Elements are made from materials. The material class combines all visual and physical properties. Composition This contains all shared properties for CAAD Entities. They carry information which several elements have in common in the form of layers and thicknesses. They are used with Physical Elements. Whenever a property of a Composition changes, all CAAD Entities that reference this composition will be updated. This is comparable to styles in Architectural Desktop or in MS Word. Activity The functional requirements that can be attached to rooms or building blocks. Representation A predefined view on the building data. This contains properties such as viewing type, Scale Level and Design Phase.

12.5 CAAD Module

285

Figure 12.5 describes both the Generic Principle Layer and the Architectural Aspects Layer, as described in the CORE Object Model. This figure is a translation of the Model in an UML notation9 , explaining the actual implementation of the IDEA+ Data Structure.

Project Library Element

Material

Composition

Composing Layer

Element

Representation

Physical Element Type

Physical Contact Link

Activity

Physical Element

Physical Boundary Link

CAAD Entity

Space

Imaginary Boundary Link

Masterplan Element

Grid

Outside

Space Assembly

Common Space

User Space

1 Space Type

Hole

Figure 12.5: UML Scheme of the IDEA+ Data Structure for CAAD Entities The CAAD Entities are the specific building entities. They are stored in a list inside an element and have been elaborated in [Hen00]. There are several different types of CAAD Entities. CAAD Entity

Physical Element

Space

Masterplan Element

User Defined Entity

Grid

Figure 12.6: Inheritance Diagram for CAAD Entities

Physical, Conceptual, Scene and Graphical Elements While the CORE Object model mainly defines different CAAD Entities, which are on a similar level, the implementation of IDEA+ has lead to the choice of different entity categories. 9 The

UML scheme uses some graphical liberty, for reasons of readability.

286

Chapter 12. The data structure

Library Element

Material

Composition

Activity

Representation

Figure 12.7: Inheritance Diagram for Library Elements

Project

Material

Composition

Activity

Representation

Elements

CAAD Entities

Figure 12.8: Relation between Elements, Project and Library Elements

Physical Elements The single Physical Element class from the CORE Object model is retained and the Physical Element Type provides the choice for different entities. Every tangible entity, which needs to be constructed on site and which represents a direct cost is placed in this category. Most common BIM applications focus mainly on these entities. Conceptual Elements are the non-Physical CAAD Entities from the CORE Object model, such as Space, Grid and Masterplan Elements. They are design entities, but are mainly used by the designer on higher Scale Levels, as mere virtual entities. They are only realized with their enclosing Physical Elements. Graphical Elements are similar to regular drawing entities from generic CAD applications, such as lines, splines and solid volumes. They could be used while designing as placeholders, before actual design entities are placed, or to clarify design decisions, such as symmetry axes, hatched zones or even plain annotation text. Technically, they will generate the regular IDEA+ graphical entities, and will function more as wrappers. Scene Elements non-physical entities, which are mostly used for visualization, such as cameras to store viewpoints and symbols such as a North arrow. Section planes and Elevations could also become part of this category.

This modification was motivated from the end point of the user in the application prototype. These categories will be used to present the users the types of objects that can be created.

12.5 CAAD Module

12.5.2

287

CAAD Entity : Physical Elements

Physical Elements are tangible building objects. These are the objects that the contractor has to realize on the building site. Their structure is derived from the BB/SfB classification system [DNHS90]10 . Skeleton Element A class to store information about linear elements, such as columns and beams. They usually have one dimension which is larger than the other dimensions by an order of magnitude. Planar Element A class for planar entities, where the thickness of the plane is smaller than the size of the plane, by an order of magnitude. This is used for common entities such as walls, floor slabs and roofs. The complete hierarchy of possible physical elements is shown in Figure 12.9. This is an extended version of Figure 5.3 from page 132. Physical Element Type

(0x) Site Element

(1x) Foundation

(28) Skeleton Element

Beam

Column

(2x) Primary Element

(3x) Secundary Element

(4x) Accessory Element

Planar Element

Stairs

Surface Finish

(21) Wall

(23) Floor

(5x) Fluids

(6x) Electricity

(7x) Fixed Interior Element

(8x) Movable Interior Element

Roof

Figure 12.9: Inheritance Diagram of Physical Elements

12.5.3

CAAD Entity : Space

Spaces are conceptual entities, describing the volume enclosed by building elements. These are typically rooms or corridors, but spaces can also be only a part of a room. To be more precise, a Space is the smallest unit which is identified as a separate functional volume. Spaces in commercial BIM applications In commercial CAD applications, spaces are often only seen as an attribute and not as a real design entity. Most applications consider spaces as being dependent on enclosing walls and they provide the option to generate a space from line work or walls. This often leads to the requirement of making adjustments through the enclosing walls. 10 More info in Section 5.6 on page 140. The implementation of Physical Elements is elaborated on page ??

288

Chapter 12. The data structure

More info was given in Section 6.1, but the main characteristics related to Spaces are given here.

Autodesk Architectural Desktop Architectural Desktop provides Spaces and Space Boundaries. Spaces define a volume and contain material settings for the finishing of floors and ceilings. Space Boundaries on the other hand contain the finishing of the enclosing elements of a space. Both are used complementary. Additionally, Mass Elements can be used for conceptual modeling, where parametric volumes can be created. There is a wizard to convert a model with Mass Elements into actual Building Elements, but this is a one-way process. Once created, there is not connection between the two models.

Graphisoft ArchiCAD The main design entity to model rooms or spaces in ArchiCAD is the Zone tool. Zones are created in the floor plans and they can be either independent or can be related to enclosing elements, such as walls, but also dedicated line work. With slanted walls and more freeform modeling support, Zones will adapt to these free volumes only when they are connected to these entities. A nasty problem in ArchiCAD is the way Zones are updates when the related geometry is modified. The user has to manually call the Update Zones command to enforce updating the zones and repeat this for each floor level. Zones can be used in the Interactive Schedules, to derive volume and area calculations. They can also derive information about the enclosing elements, such as Window or Door areas and amounts. However, the same Update Zones method is required to correctly recalculate the listings, e.g. when windows are inserted in walls, they do not show up automatically in the listing, even after a recalculation. Only by forcing the Update Zones command, will they be correctly regenerated. Zones can be represented in the 3D Window, when adjusting the display settings for this representation. However, when Zones are displayed, all other geometry is represented using a wire frame display style. Zones can inherit the materials from the enclosing elements.

Autodesk Revit Revit has a similar method as ADT to create a massing model. In Revit it is possible to attach building entities to the faces of a mass volume. It allows for partial updates, but whenever more elaborate changes are made in the masses, the connection gets lost.

12.5 CAAD Module

289

Characteristics of Spaces Spaces can be seen in two ways. They might be considered as separate entities, promoting them to real design entities. They might also be seen as bounded volumes, by generating them from their enclosing building entities. The former sees Spaces as independent design elements, while the latter assumes that Spaces will be created as a result of modeling other entities. The following properties are inspired by [HC02], which provides a good and structured approach to the description of spaces. • Spaces can be connected to other Spaces. This connection can be classified as being disjunct/disparate, where spaces have no connection at all, touching, where two spaces have at least a part of their Space boundary in common, and connected, where they have a physical or visual connection, in the form of a window, a door, a frameless opening or a “virtual” wall. • The capacity defines the amount of persons that the space can host. Even though the Activity class also contains this information, there is no real redundancy, since the Space might provide more room than what is strictly required for the chosen Activity. This is very useful for space occupancy tests. • A Room might contain more Spaces, where the Space is considered to be the smallest separate volume. In IDEA+ this can be modeled as a Space Assembly element. Implementation Outside There is only one outside Space, which contains all information about the environment and the site. Properties such as positioning coordinates, climate and orientation belong to the outside space. It is not built and can not be influenced by the design. The Outside is stored as a member variable of the Project. Common Space They are the regular space elements, usually defined by their contour and their height. They can be linked to an Activity and grouped into a Space Assembly, which are discussed in the following paragraphs. There are two types of spaces: User Spaces and Holes. Where the usual notion of spaces is captured with the User Spaces, the Holes are used for openings in building elements. The motivation to define them as spaces lies in the fact that holes can be used as spaces, when they are large enough for a particular activity. See [Hen00, p.87 & 106]. We consider spaces as a conceptual, non-physical design entity, enclosing a volume in the model. A Common Space is the smallest volume in a project that can hold one or more activities. It can be a room, a corridor or a part of a room. Spaces can be grouped in Space Assemblies, which may form combinations such as a wing, a single story, all office spaces or the circulation space. The Outside

290

Chapter 12. The data structure

CAAD Entity

Space

Outside

Common Space

Space Type uses User Space

Hole

Figure 12.10: Inheritance Diagram for Space Classes is considered as a particular case of a Space [Hen00, p.91]. The Outside space can only exist once inside the project. While creating a space, additional physical elements can be generated, which may become walls, floors or roofs when switching to the Space Scale Level . This allows to generate the links between the Space, as a conceptual element and the physical elements that define its volume. Even when no bounding geometry is needed, these physical elements could be used to to access and manipulate the space in a coherent way. A row of columns or even a virtual wall could be a separating geometry to define the space. The CORE Object model clearly states that Spaces and Physical Elements are mutually independent. Only through the creation of links between these elements will interdependencies be introduced. A Space has a Space Type, which can be a User Space or a Hole. User Spaces are accessible spaces, while a Hole is used to define an opening inside planar elements. In some design cases, a Hole can be promoted to a User Space, when it has sufficient size to carry an Activity. Since the Space Type is detached from the Space object, the data structure provides means to switch between Space Types.

Manipulating Spaces When Spaces have been defined, they are usually not in their final stage. Different manipulation operations have to be available to be able to correctly model the required spatial layout.

Subdividing and Merging Spaces Two common operations on Spaces are subdividing and merging. Spaces can be created as the extrusion of a simple contour, carrying mostly 2D information. These operations, however, allow more complex volumes to be created in an intuitive and straightforward manner.

12.5 CAAD Module

291

This places some requirements on the underlying graphical engine. The extrusion of a 2D contour is fairly simple and can be quickly simplified as a series of planar polygons. To merge or subdivide such a volume takes a more complex geometric calculation, which can be performed in the modeling kernel. At the moment, the In a next development phase, the full integration of a modeling kernel can be introduced, without creating dependencies between the data structure and a particular kernel. To enable this, an abstract modeling layer is added to the Graphics module, to be called by the CAAD Entities. The prototype can then call the specific modeling commands for the chosen kernel. Translation of Corner Vertices Since Spaces are CAAD Entities, they utilize Reference Points, to define the control geometry. This automatically allows sharing and translation of these Reference Points with other elements. The translation of a shared Reference Point automatically assures a synchronization between the Space and other elements. Re-thinking Spaces An important implementation decision is the choice for an approach that relies on mostly geometrical information, where the Space aspects are simplified as attributes or metadata and an approach which starts from purely semantic data, from which the geometrical representation is fully dependent. In IDEA+ the geometry is generated and is thus of secondary order, but the control geometry, in the form of the Reference Points, belongs to the primary design information. It was decided to not let Spaces be completely dependent on their enclosing elements, as stated in the CORE Object Model. Spaces are independent design entities, which can live with or without enclosing elements. This is similar to generic planar elements, which have no connected composition and thus no material information. The connection of Reference Points is a method to define relations with other elements and allows synchronization after modifications. Common Spaces, which are the Space entities used for Rooms and other enclosed volumes, have to be subdivided down to a level where they enclose the smallest identifiable volume. This will be a single room in most cases, but when the characteristics of a room are not homogeneous the room will be further subdivided.

12.5.4

CAAD Entity : Space Assembly

Any set of spaces can be grouped as a Space Assembly. They can form groups of spaces with common parameters, such as floors, circulation spaces or office spaces. The grouping of spaces can be done in two ways. The first option is a manual grouping, which allows any set of spaces to be grouped as seen fit. A second

292

Chapter 12. The data structure

option is automatic grouping, where the assembly is collected from properties of the spaces. This can be done from geometric properties such as Reference Heights defining floor levels, from classification properties or from any other chosen property. Spaces can be a part of as many Space Assemblies as required.

Space Assemblies These Common Spaces can then be arranged in groupings, called Space Assemblies, to form meaningful entities, such as an office, a circulation corridor or a nursing unit in a hospital. The CORE Object Model indicates that Spaces are allowed to be part of several Space Assemblies, to allow freedom in these groupings. However, this introduces multiple questions, e.g. how to query the area of a Space Assembly when the Spaces might have multiple references in different assemblies. Even though it would be a trivial algorithm to make sure that no single space is counted twice, there are conceptual questions. How would the area of a Space will be taken into account when it is assembled twice? Would it be divided over the different assemblies? How will the weighting be executed? Even though this is not elaborated in the prototype, Space Assemblies would also be allowed to become part of other assemblies as well, to enable hierarchical grouping. This further complicates area and volume calculations. The implementation of Space Assemblies has defined different filtering options in the assembly. â&#x20AC;˘ Selection based filtering can let an Assembly reference a free list of Spaces. This allows much freedom, but places no requirements on adjacency or juxtaposition. This could be used to collect conceptually related Spaces. â&#x20AC;˘ Filtering based on vertical sizes could be used for building stories. Based on the lowest and highest point of the space, an assembly could collect all spaces on a particular floor level. â&#x20AC;˘ Activity based filtering could be used to collect all spaces which reference the same Activity.

Experience with BIM software and building practice indicates that in a design project Spaces need to be collected differently for different queries. Sometimes an assembly based on activities is relevant, while on other occasions, the zoning or contours are defining how Spaces belong together. It is even more complex, since different evaluation tests require a different method to calculate spaces. In some heat-loss calculations or administrative documents, the brute volumes need to be taken into account, while at other time, the net area or volume, in between the enclosing elements, is required. The calculation of the area or volume of a Space is thus dependent on the evaluation type.

12.5 CAAD Module

12.5.5

293

CAAD Entity : Masterplan Elements

The conceptual entities that are used on the Masterplan Scale Level. These elements form the global volume of a building. Depending on the size of a building, one or more elements will describe the overall shape. The Masters Thesis of [MP03] elaborated the conceptual structure for these Masterplan Elements. The scheme of Figure 12.11, which was developed in this thesis, anchores Masterplan Elements into the main IDEA+ data structure. The design entities on the Masterplan Scale Level consist of the Masterplan Block, the SitePart, the Structure and the Equipment. The first two function as CAAD Entities and are derived from a common Masterplan Element class. The last two, however, function more as attributes. They can be shared between several Masterplan Elements, which is done with a reference.

CAAD Entity

Masterplan Element

Activity

SitePart

Masterplan Block

Equipment

Structure

Figure 12.11: UML scheme with the added Masterplan Elements Masterplan Block This is the common element to describe building shapes. They are mainly defined by a contour, a height and a number of floor levels. A complete design can be quickly modeled as a set of Masterplan Blocks. This is a simple volume, but it enables fast volume and area estimations, providing an early cost estimation. Since it captures information about floor levels, divisions of a building with different floor levels need to be modeled as a different Masterplan Block. SitePart The Site, which is defined on a Scale Level above the Masterplan, is split up in SiteParts, defining the different functions on the site, such as building zone, parking zone or gardening zone. These parts indicate which zones in the whole site can be built upon and which need to stay unbuilt. Structure This element contains information about the structural solution, chosen for a particular Masterplan Block. This can be a combination of column grids, concrete cores, such as elevator shafts and load-bearing facades. The designer can also choose the span direction for this structure. This element type is meant to embed global structural decisions inside the building project, on the Masterplan Scale Level. Equipment Analogous to the Structure, the Equipment element embeds global design decisions inside Masterplan Elements. The choice of the equipment

294

Chapter 12. The data structure type will not involve setting actual systems and detailed technical requirements, since these are further developed on lower Scale Levels.

The scheme of Figure 12.11, however, was adapted in the implementation, to better conform to the IDEA+ data structure. This is shown in Figure 12.12. It was decided that the introduction of Library Elements would better fit with the purpose of some of the entities that are referenced from Design Entities. The Structure and Equipment are thus derived from this common class and so is the Activity. These are all non-tangible design entities, which are shared between several tangible design entities. Library Element

CAAD Entity

Masterplan Element

Activity

SitePart

Equipment

Structure

Masterplan Block

Figure 12.12: Adapted UML scheme with the Masterplan Elements A Masterplan Block encapsulates Spaces from the lower Scale Level. This is an assembly of floor levels, which contain individual Spaces. Once a Masterplan Block is specified as a concrete set of spaces, it can be reconstructed from the assembly of spaces. This is elaborated in the description of transitions.

12.5.6

Library Element : Activity

An Activity describes the possible functions a building must accomodate. They can be assigned to Spaces and Masterplan Elements. An interesting approach can be found in GraCAD [SGB00, SSB02]11 , which allows the designer to visualize a graph-diagram from a CAD model in ArchiCAD. This system includes the management of the building program, which will result in a generated layout. In their concept, functions are created first and spaces are being mapped to the functions. It allows to add more spaces to a function. However, it is unclear of a function could be mapped to multiple spaces and if more than one function is allowed in a space. Typical properties of Activities are the required area and volume, but also the climate characteristics, such as temperature and air humidity. In [Hen00] Activities were defined as CAAD entities, allowing them to become a real part of the design. This introduces some conflicting properties, however. A coordinate system and Reference Points are common properties for all CAAD Entities, yet they are of little use for Activities. 11

http://www.es.tu-darmstadt.de/index2.php?page=709

12.5 CAAD Module

295

At implementation time, the choice was made to define Activities as shared entities or Library Elements, quite similar to Materials and Compositions. They can be referenced from within CAAD Entities and are kept at the project level. References to the modeling of Activities can be found in BASâ&#x20AC;˘CAAD and ACTIVITY [Ekh01, EF00, Ekh96].

Library Element : Activity An Activity can be assigned to both a Masterplan Block and a Common Space. As mentioned in the previous section, more than one Activity could be assigned to these elements, which places additional demands on the Activity properties. An Activity has some common characteristics, such as Time Occupancy and required area, volume or climate. In contrast to most CAAD Entities, there is less reason to define geometric properties for an Activity. The proposed object model of [Hen00] defined Activities as a real design element and placed it amongst the regular CAAD Entities. The implementation in the current text questions this proposal, since an Activity has more in common with shared elements such as Materials and Compositions, than with other CAAD Entities. Materials and Compositions are stored inside the Project and can be referenced by several objects. It makes sense to treat Activities the same way. Regardless of the chosen implementation, Activities are not considered a mere attribute of a Space. Activities can be defined independent of Spaces and they might become part of a project library during the Programming Design Phase. As such, they are a full design entity.

Activities in commercial BIM applications Autodesk Architectural Desktop In ADT, activities are not seen as a design entity. That said, it is possible, through the use of Space Styles to define how spaces appear. This is augmented using Room Tags. This is comparable to a block with attributes, which links to the Space. Using these Tags, schedules can be generated for room listings.

Graphisoft ArchiCAD In ArchiCAD, there is no real activity tool. There are the Zones, however, and they can be assigned Categories. This implies that an activity in ArchiCAD is merely thought of as an attributes for a space. While this allows for extraction of common room schedules, the activity is not seen as a design entity. An interesting approach can be found in the ACTIVITY project from Anders Ekholm [EF00, Ekh01]. This is an Add-on for ArchiCAD, allowing the designer to model activities as if they were a regular design entity.

296

Chapter 12. The data structure

Autodesk Revit Quite similar to ADT, Revit allows to create Room Tags in between walls, which are discovered automatically. Adding these tags will enable to user to create listings. However, an activity is not seen as a design entity either.

12.5.7

CAAD Entity : Grid

Even though a visual grid is available in the prototype, Design Grids are seen as an independent design entity. They are drawn as a pure graphical entity but their functionality is that of a CAAD Entity, generating a graphical representation, but also allowing connections through Object or Property Links and the possibility to split or join their Reference Points. The added value of using Design Grids as a real design entity is capturing design intent. The anchoring of an endpoint of a wall onto such a grid is not only a temporary drawing aid, but an embedded design decision, where the anchored elements follow grid adjustments. A Design Grid can have any position, orientation and grid spacing. At the same time, multiple grids are allowed, providing a more flexible design workflow. Any combination of grids can be used and they all serve to capture some of the underlying design decisions into the project data. An example is shown in Figure 12.13.

Figure 12.13: Illustrating a combination of Grids

Contour Based Grids A Grid type that was not elaborated is the Contour Based Grid. This is defined as a series of Reference Points describing a contour and parameters to fill this contour with a grid of lines. The lines are clipped against the contour. This is a design entity that would be beneficial to describe more complex combinations of grids, allowing to have multiple grids in one design. Each grid can

12.5 CAAD Module

297

have its own orientation and spacing. This might be useful to define a separate grid for a wing inside a building that has a different structure. A simple example of how a contour based grid could be used is displayed in Figure 12.14

Figure 12.14: Illustrating a Contour Based Grid

Working Plane At the same time, the working plane can be adjusted alongside the Design Grids so cursor movements can be interpreted with regard to an active grid. Modeling operations usually require the restriction of the mouse pointer to a specific plane and additionally to grid positions inside this plane. It is advisable to allow means to temporarily disable the grid or to switch to a lower or a higher grid spacing. This is typically done with key modifiers, such as a combination of a CTRL or SHIFT key press and a mouse movement. A typical application of a temporary working plane and snapping grid is the input of an opening inside a Planar Element, where it makes sense to switch the working plane to the plane of the Planar Element, so the user can draw directly on top of these elements. The input coordinates can afterwards be translated to a local coordinate system, which is relevant for the Planar Element, such as the UV-coordinate space, which is often applied with NURBS modeling or with texture mapping. UV coordinates are used when translating global 3D coordinates into a local reference coordinate system, such as a single patch in a NURBS surface or a pixel on a texture map. A single UV coordinate uniquely identifies a position, which can be translated back again to a full 3D cartesian coordinate.

12.5.8

CAAD Entity : User-Defined Entity

The CORE Object model proposed this entity as a possible extension to the object model, as a user-oriented addition for entities that do not fit in the regular structure [Hen00, Section 2.1.2]. While the CORE Object model did not further specify these entities, basically assuming that this was the area where end users or developers could augment the system, some suggestions are made in this Section.

298

Chapter 12. The data structure

Instances These elements are used whenever a CAAD Entity needs to have linked copies. Whenever the original entity is updated, the instanced copy follows the changes. The only difference between the instance and the original reference object, is its position, using a transformation matrix. As such, only one entity needs to be managed, possibly controlling multiple identical copies with it. This is a concept that is widely used in CAD software. These instances are called blocks in AutoCAD and cells in MicroStation, but many other applications use the same concept. Some of the proposed properties are a reference to the original object and an offset, using a transformation matrix. Reference Documents When external files are linked, they are used as references. The advantage of keeping the link to the original document is the possibility of updating the reference when the original has been modified. This concept is called XRef or external reference in AutoCAD, but it is also called Overlay, Linked file or Module in other applications. This enables to host external data inside a project, while at the same time files do not have to include the full content of the referenced document, allowing smaller file sizes. The proposed properties included a string to set the relative file path, the actual file name and date, to aid updating and some optional attributes to define the visibility, such as the relevant Scale Level and Design Phase, the Planning Phase and a BB/SfB code. The geometry that is loaded from the external file can be inserted into the current scenegraph, in a separate segment, where it is unaffected by the current project entities. It would be interesting to use the referenced document for complex geometry, such as a mesh representing a tree or a city block. However, real integration into the building project poses questions. How will information about used materials, surface area or volume be queried from such a file? When the prototype would allow the hosting of other IDEA+ files, there could be a hierarchic project, but the same questions arise. How to manage the content, when information is queried? A possible solution might exist in manually defining additional custom attributes for such an external file, possibly using the current mechanism of Extended Properties, to enable regular tests to at least retrieve some information about the external document. E.g. when a custom cost attribute is created for an external model, such as a mesh representing a chair, together with a correct classification code, it is possible to include the external object into quantity estimations.

12.5 CAAD Module

299

Scripted Entities When the behavior of an Entity can not be predefined, it would be beneficial to the user to be able to script it. A custom script could be used to customize the graphical entities that are generated and possibly have a more suitable calculation of area or volume. This is inspired by the power of library objects in ArchiCAD, which are scripted using the Geometric Description Language (GDL). This is a basic-like language, with support for control structures, such as “if. . . then”and “while”loops. While this GDL syntax is fundamental to the inner working of ArchiCAD, it is not strictly needed to use the application. In fact, most users rely on objects that are predefined. In many discussions with ArchiCAD users on the online forum ArchiCAD-talk 12 , however, it is clear that most users refrain to start developing their own GDL objects. It is often said that “architects are no programmers”. While this might be the case for many individuals, the architectural profession and training constantly involves the need for problem formulation. During problem solving, a programmatic formulation might makes sense. A typical examples is the creation of a small calculated table using spreadsheet software for basic area surveys in the Programming Design Phase. In a typical office, the development of officespecific scripts, routines and templates is performed by the CAD manager, who is often also the IT manager. To be able to define a scriptable object in a design application, it has to define some common parameters, to identify it and then provide a script in some form. The application will parse this script for known parameters and operators. The development of such parsing functionality could built on existing scripting languages or parsers. It is important to understand that the features of the Property System in IDEA+ play a pivotal role here, already allowing generic access to element parameters. When a scripted object presents itself to the system, no further effort is required to access its properties or to store it with the project data. While this is not elaborated, mechanisms to facilitate this in the future are already worked out in the current data structure. It is even possible to define most custom objects as scripts, possibly using an XML-syntax based on the current IDEA+ file format. This would allow to define custom object templates as text files, rather than having them be coded and compiled into the main application. Upon launching, the application could scan a preset folder with scripted files and load them into the IDEA+ factory, so they can be instanced as regular entities. Extensions could thus be easier to create, although debugging errors will be potentially more complex. For the user it would make little difference if the created entity would be an external template or a precompiled native entity. 12

http://archicad-talk.graphisoft.com

300

Chapter 12. The data structure

Conclusion Even though these entities seem to be an amalgam of all the entities that do not fit well into any of the common object types, they are all based on concepts that are in use in different design or CAD applications. The study of existing applications has shown the validity of many of the common concepts these applications provide. The differentiation in IDEA+ would be mostly situated in a more elaborate parametrization and generalization of these techniques. Since all these entities would inherit the characteristics of the Base object class, they do not have to be treated in custom methods or custom dialogs. They all become a part of the regular design entities. It is possible to include them in Property Connections, to extend them with additional parameters and to store them with the rest of the project data. They will be represented using the same methods as other CAAD Entities, will be selectable without additional effort. Their biggest advantage lies in flexibility and storing design intent. Instancing is an approach to define an entity once and reuse it. This ensures that someone who receives the project can make no false assumptions on the intention of these objects. They are intentionally identical and will stay identical when changes are made. Simply making independent copies would not ensure there equality. The design intention is enforced in the project, without requiring additional annotation or labeling. Similarly, the solution of external reference documents is well known and understood in both CAD and DCC applications. This is an approach that facilitates the organization of larger projects, but can also be used to divide the project into individually managed pieces, which are edited by different people. Simply importing an external file will never retain the connection with this file. The only way to ensure that the imported file and the external file stay synchronized is through referencing. And lastly, the scripted entities have proven to be very important with the GDL objects in the ArchiCAD library system. A script can generate a much wider variety of permutations of a single object, while at the same time, design logic can be built in. While there is conceptually not a real difference between a programmed entity or an entity using a script, the access to the preprogrammed entity is mode difficult for an end user. It requires access to the source code of the application and a compatible compiler to recreate the application executable. A script could be edited without recompilation of the application. While it makes the program more vulnerable to errors and bugs, scripting provides flexibility. The elaboration of such entities poses additional questions, though and it was deemed wiser to postpone their elaboration for future research, when the main data structure is more stabilized. The biggest hurdle is to make sure that this custom objects follow the behavior of other native CAAD Entities, reacting identically with regards to the use of classification codes, Reference Points and quantity estimations.

12.6 Organization and Implementation of CAAD Entities

301

12.6

Organization and Implementation of CAAD Entities

12.6.1

Object Factory

The creation of Elements and CAAD Entities is performed by an Object Factory. This is a collection of entities from which instances can be created in the project. This is an approach to generate entities in an abstract way, making the functionality of the application generic and independent of the available entities. Additionally, it is possible to add new entity types later on, without the need to adjust or adapt the application. The concept of a factory is described as a design pattern in [GHJV95]. When entities are registered with the factory, they can be instanced by the factory at runtime. It is even possible to enhance the factory at runtime, through plugins. Graphical and Architectural classes are registered with the Factory, which stores an instance of these classes into master lists. See Figure 12.15. Graphical

store Factory

GraphicalsList

store

Base

BaseEntities

Figure 12.15: The working of the IDEA+ Factory The Create method requests an instance from the Factory, which returns a copy of the master instance, based on the passed parameters. This is then added to the Project data. See Figure 12.16. request Create Command

Factory

instantiate Base

addTo

Elements

Figure 12.16: Instantiating a Base Element from the Factory While the current implementation uses a preset list of available entity types and interaction modes, in a global array, it would be beneficial for future flexibility to rely on the factory to derive all possible available entity types. Registering an entity is currently implemented, but the GUI and the user interaction does not derive them from the factory yet. Object creation, however, is already performed by the factory. It would also make sense to register custom tests, commands, library entities and even user dialogs directly in the factory, to dynamically derive the GUI from all available object types in this factory. This will be further elaborated to create a more modular system, possibly using plugins. Defining entities in a

302

Chapter 12. The data structure

plugin or add-on script could then be used to call registration methods and fill the factory when the program launches.

12.6.2

Physical Element, Type and Composition

Physical Elements are all the real world building elements, such as walls, floors, roofs or beams. The CORE Object Model describes them as containing a Physical Element Type, which stores the instance-specific data, and also a Composition, which carries the data that are shared between instances. Other BIM software sometimes uses the term styles to describe the same concept. A typical example is a cavity wall. The fact that it is a straight and vertical wall, defined by a start and ending point, is defined by its Physical Element Type. The value of the parameters height and length are unique to this instance. The material layers that define the internal structure of the wall are defined as a reference to a Composition. Different walls can share the same composition. When changing the height of one wall, other walls do not have to change, but changing the definition of the Composition forces all other walls that reference this Composition to change as well. When switching to another Composition, the wall shares characteristics with other walls. This functionality is found in most BIM applications. Compositions solid composition The element is made of a homogeneous material. It includes a Reference to material and a main width or size. linear composition The element is made as a sequence of elements, e.g. metal stud interior wall. This describes a pattern of individual materials, with length and material reference. shape composition A pattern of a specific section/shape, which can be repeated with given length, offset and material reference. layered composition The width of the element is divided in parallel layers of materials, each with thickness and material reference. compound composition This could be a combination of all of the above in a single composition. It will be used to create more complex compositions out of regular sub-compositions. Implementation choices Theoretically, it would be possible to define a full hierarchical class structure, containing all kinds of elements in a large, tree-like structure. This creates certain problems, though. If a huge class structure were defined, where every possible object type with all its possible variations becomes a separate class, functions which work with these classes would need to distinguish between all

12.6 Organization and Implementation of CAAD Entities

303

these possible classes. A Representation would have to react differently to every possible object type. A similar problem arises when variations of objects are defined. Once a curved wall is added, the handling of a wall needs to make a distinction between the straight and the curved type. This quickly becomes a maintenance nightmare, where the large amount of classes forces elaborate type checking. According to [Mar00] this is not a good programming approach: â&#x20AC;&#x153;Subclasses should be substitutable for their base classesâ&#x20AC;?, which is known as the Liskov Substitution Principle. The consequence is that an application expects all classes which are derived from a certain base class to behave the same. The derived classes adhere to the same interface as the base class. The application should not be aware that a curved wall uses other parameters than a straight wall. Further specialization of the wall make it more specific. It is possible to create a whole inheritance hierarchy, starting from a generic planar element, which can be further specialized as a wall, as an exterior wall and as a cavity wall. Different options could be followed, but overall, the implementation of IDEA+ gives preference to a smaller amount of classes. The fact that a wall is interior or exterior could be set by an attribute and could even be retrieved by al algorithm, which checks the adjacency with existing spaces. A wall that only touches one space, on one side, could be assumed to be touching the outside space on its other side, thus becoming an exterior wall. While defining the wall as a planar element indicates that it might have a free polygonal shape, walls are usually modeled as linear elements, having only two main reference points and a constant height. It is unclear if the best approach is to provide both options as different classes, or to make them all variations inside a single class, based on its attributes. The current implementation has chosen to define a wall as having a series of points, defining its base Reference Line. When there are only two points, the wall is linear, but adding additional points will generate a chain of linear wall segments. Such an implementation will assume the wall to be vertical, having a constant thickness and a constant height. By adding additional parameters, such as start height and end height and also the option to define the thickness manually or to derive it from the Composition, makes for a larger freedom in the generated geometry. However, experimenting with the choice of attributes indicates that a large list of attributes makes the design entity more complex to manage, thus hindering design exploration. In any case, the implementation quickly necessitated a more flexible data structure and a more generic formulation of objects and their properties, to be able to derive the editing dialogs from the object and not having to define it in advance. This is discussed in Section 12.3.3 where the Property System is described. Without going into more detail on the technicalities of this implementation, Physical Elements share the same common parameters: â&#x20AC;˘ A series of control points or Reference Points. A planar, vertical wall has two points, a column only one, while a floor slab has three or more points. Regardless of the amount of points, all these classes will behave

304

Chapter 12. The data structure in a similar way, where the user defines the points and any object reacts identical.

â&#x20AC;˘ A series of additional attributes, such as height, thickness, slope or length. Through the Property System, they can behave identical with regard to the application and the user interface. These properties will be editable and each object might have its own functionality. How the object reacts to these properties and points stays hidden for the application. It is encapsulated in the implementation and the application does not have to be aware of the implementation at all, to be able to manage these elements. â&#x20AC;˘ There is also a series of common administrative properties, such as the name of the element, its classification code and its unique index, which is required for persistent storage and retrieval in a file or in a database. This functionality is inherited from the Label class. What is the advantage of such an approach? Through the description of a clear interface, the application knows exactly how to handle it. All objects act in the same way. Having the hierarchical structure of elements included in their classification information, which is using the BB/SfB-code, the application knows the category or class of elements and is able to filter selections or choose appropriate display properties for elements, without having to know anything about the implementation of these elements. When new classes of objects are introduced, no part of the application has to be rewritten or adapted, provided they also conform to this same interface. This enables a flexible and extendable application.

Example: Wall This approach is illustrated with an example for a wall class. Assume that a simple wall contains a list of two reference points, defining the startpoint and endpoint, and one additional number, defining the height. The implementation of the wall additionally defines an algorithm specifying how to generate the possible representations for the wall, based on these properties. In the example this can be a simple prismatic volume or even a simple line for a low-detail 2D representation. To the application it does not matter how these points or the number are used, but even then it is able to pass the entered points to the wall entity, to demand the generation of some graphical entities for the active Representation and let all other work be done by the wall. Even when the application is unaware of the inner working of the wall, it is able to generate a user interface to manipulate this wall, allowing the user to make changes.

12.6 Organization and Implementation of CAAD Entities

305

At the moment a new type of wall is defined, such as a curved wall, which can be based on multiple Reference Points or which may carry an additional eccentricity at the middle of the wall, the application does not have to be adapted to be able to manage this new type of wall. It is clear that the handling of a column, with one base point and one height property or a floor, with multiple Reference Points can be elaborated in a similar way, without adapting the application. The user interface does not have to be modified either, apart from the addition of new toolbar buttons and menu entries. Even then, they might be generated from the factory, rather than by manually adding support for these new types. New types might even be added at runtime, making the implementation of the application totally unaware of the available object types.

Reference Points The series of Reference Points define the geometric properties. The interpretation of these points is left to the implementation of the CAAD Entity itself. Initially, each element kept its own series of points, which is more or less the approach in common architectural design software. Maintaining separate lists of points in each element is easy to implement and makes elements rather independent of other elements. In Mechanical CAD, through the use of constraints, relations and dependencies between geometry can be enabled, but this is uncommon in architectural software. These points can be extended with additional profiles or contours, which can be used to define a shape to extrude or sweep13 . Such additional profiles can be used to define the shape of an opening, or the profile of a beam or column. In IDEA+ the decision has been made to store these points as references, allowing points to be shared between elements. This makes sense from an architectural point of view. When the endpoint of a wall meets the beginning of another wall, they could be interconnected, by letting both elements use the same Reference Point, as shown in Figure 12.17. If a point is changed, both elements will follow. The connection becomes permanent and as such, the design decision becomes embedded in the project data. When the corners of a floor slab and the endpoints of a wall are joined, the elements become attached and stay connected throughout modifications in the project. Moving a wall will move or stretch all elements that are connected to the wall. Instead of relying on complex constraint and synchronization mechanisms it was decided to simply share the actual reference points between elements. There is nothing to synchronize, since both elements reference exactly the same point. Simple relations between elements can be adequately described with shared Reference Points. 13 A sweep is an extrusion of a profile along a path. Sometimes more than one profile can be defined, where the generated volume is interpolated between the different profile shapes.

306

Chapter 12. The data structure

Figure 12.17: Join two walls through their Reference Points Example: Hole Consider an opening in a Physical element. An opening is a Common Space, with Hole as its Space Type. Only Planar Elements are allowed to carry openings. The result is that there is always the requirement of both a Physical Element, with type Planar Element and a Common Space, with type Hole. These two CAAD Entities can be embedded in one Element, so they stay together at all times. The Planar Element would then be the first CAAD Entity, with the Hole as a dependent second entity. There is an existence dependency, where the Hole can only exist when the Planar Element is available. This is expressed with a Dependence Link. There is, however, the addition of a third CAAD Entity, being the optional Window or Door object, which is definitely not a Space, but rather a Physical Element. It is touchable, it has a defined cost and it has material properties, indicating that it would not suit to define it as a Space object. This is shown in Figure 12.18. Element

Physical Element2

Space

Physical Element

Window

Hole

Wall

Figure 12.18: Defining hole and window as part of same element The Window or Door frame is directly attached to the opening, whereas the Opening is positioned relatively to its hosting Planar Element. It makes sense to define the positioning of Holes inside Planar Elements in a local coordinate system, which is usually the relevant placement environment for locally attached

12.6 Organization and Implementation of CAAD Entities

307

entities. The opening can only be moved inside the plane of the Planar Element. A suitable coordinate space for placement and sizing of openings would be the UV coordinate space. This is a local coordinate system, which defines positions in a rectangular grid. Commonly, the local X-axis is called U and the local Y-axis is called V. This is sometimes extended with a W-axis, e.g. in the application of volumetric shaders 14 . UV coordinates are commonly applied in parametric modeling with NURBS or other mathematically defined surfaces, but they are also used for texture mapping. In both cases, the definition of UV coordinates is used to connect a position from a local coordinate system with a cartesian coordinate on a geometric object. For texturing, this is the linkage between the pixels of an image and the geometry. With NURBS modeling, each 3D patch has a related local UV space, where it is easy to define trimming 15 curves. When a Window or Door is defined as a separate Physical Element, it is also possible to create such object independently of a Planar Element, which makes sense for curtain windows and other larger framed objects. This is shown in Figure 12.19.

Element2

Element

Physical Element2

Space

Physical Element

Window

Hole

Wall

Figure 12.19: Defining hole and window as part of separate element The dimensions of openings define the size of the inserted frame object, but it should be possible to define an independent frame object on itself. Openings do not always have to carry a frame object. Some openings are simply void spaces and others might even be filled. The former occurs as inner connections between rooms, while the latter allows the additional work and involved cost to be modeled for renovation projects, while at the same time retaining a correct representation. Depending on the building phase, the situation before or after the construction work can be represented. It is therefore important to be able to define these properties with openings. 14 Small scripts or programs which define an output color based on mathematical or procedural functions, rather than on the pixels of an image. A shader program is evaluated at render time for each point on the surface and defines the resulting color on that local position. 15 It is easier to define a curve on a surface in a local 2D coordinate system than it is to define it directly on top of the 3D surface geometry.

308

12.6.3

Chapter 12. The data structure

Links and Relations

In the previous chapter, the different link types were introduced. Most links are meant to connect CAAD Entities, which carry the main building information. But there is a possible confusion on the user level. The Project contains Elements, which can contain one or more CAAD Entities. To the user, there is no real difference between an Element and a CAAD Entity. The whole interface is tuned to work on an Element level, where selecting, deleting, copying and pasting all operate on Elements. This is usually not a real problem, since simple Elements only carry one CAAD Entity. But the system provides room to add additional CAAD Entities inside a single Element. This is meant to support more complex entities, having multiple parts, but which have to be kept together at all times. Each Element is in fact a small assembly of parts which should not be separated. When disparate entities or elements need to be connected together, they should not be merged into one, combining their CAAD Entities. It is instead necessary to link them. What still provides access to the individual CAAD Entities and only stores the relation information in the additional Link object. Dependence Links When a Space becomes dependent on a Masterplan Block, through the creation of a Dependence Link, both the Space and the Masterplan Block are still part of separate Elements. But selection, deletion and translation of the Masterplan Element influences on the dependent Space, because of this link between the individual Elements. To be more precise, the links are kept between CAAD Entities, but to the user there is no real distinction. A complication arises since Dependence Links are actually kept with the CAAD Entities and not with their enclosing Elements. The CORE Object Model does not suggest to place children automatically in the same Element as the parent they depend on, since the design is still explored on an Element by Element basis. It would make things easier, though, since they would automatically belong together. This is still an option for the implementation, provided that the data that are kept inside the Element are insignificant. Otherwise, the CAAD Entity would lose part of its data when being â&#x20AC;&#x153;unparentedâ&#x20AC;? again. Property Connections The common property can be kept alongside the properties, or the property references a common value for both elements. The IDEA+ implementation works by creating a pool of references, where a connected property will become a member of the pool and updates can be controlled from the pool. Connections can be unidirectional or bidirectional. In unidirectional connections, one property will be dependent on another property, as in a master-slave relationship. In bidirectional connections, both properties can control the other.

12.6 Organization and Implementation of CAAD Entities

309

This is reflected in the user interface with small arrows, indicating the connectivity for a property. There is also a Property Connection dialog, where a new connected property is firstly created and then all connected related properties can be added to the pool.

Object Links The current implementation supports the manual addition of object links between arbitrary CAAD Entities. Depending on their type, the links are recognized as Physical Contact, Physical Boundary and Imaginary Boundary links. They are displayed when the user switches to a schematic Representation, as illustrated in Figure 6.22 on page 175.

Parameter Expressions Values or Expressions? Most parameters are simply set as values. In some cases, however, it would be beneficial to be able to define the parameter as a function or an expression. Instead of setting the actual value, a formula could be set up that calculates this value from other parameters or even parameters of other elements. This is a similar approach as the formulas in a spreadsheet, where the contents of one cell can be calculated as a combination of values from other cells. When a design carries expressions, design knowledge becomes embedded in the project data. In IDEA+ this is made possible with Property Connections. Through a link between parameters, properties of any entity can be connected to other entities. In its simplest form, this can be an equality between parameters, which is how it is implemented currently. A more elaborate implementation can add the possibility of defining Parameter Expressions.

Examples of Parameter Expressions For a designer, relations between elements are quite common, yet to explicitly store them in a formal way is less common. Most architectural design software does not provide any possibility to define these relationships or they only offer predefined common relations between entities. In other design fields, such as mechanical modeling, it is pretty common to formalize relations between entities. It is not by accident that the application Autodesk Revit, which enables some of these relations, has been developed using concepts from mechanical modeling. Another example of Parameter Expressions can be found in 3D Animation applications, such as Autodesk 3ds max , Autodesk Maya and Avid Softimage|XSI. Imagine a wall starting in the cellar and continuing up to the first floor level. Or a wall that has to extend 30 cm above a floor slab or extend to connect to a roof. These are three examples where the property of one object is connected with other objects and where Parameter Expressions might be used.

310

Chapter 12. The data structure

In the particular case of the wall, it might make sense to define the top and bottom relations as actual properties, rather then by using a custom expression. But even then, not all common relations will be provided directly by the parametric objects. When the user is allowed to define these relations when required, real design intentions can be embedded inside the objects. Table 12.1 illustrates the wall example. Even when the system provides no direct settings for these object characteristics, the use of Parameter Expressions can be used to define them if required. Table 12.1: Example of wall parameters that relate to other objects Part of Wall Upper Side Bottom Side

Position Absolute Relative to Floor Level 1 to Ref. Height 0 to Roof XYZ to Floor ABC ...

Size 3.2 m 0.0 m -0.5 m

Chapter 13

Representations Introduction This section primarily discusses graphical Representations, but when appropriate non-graphical Representations are explained in addition. A Representation sets the characteristics of a certain view on the building model. CAAD Entities can generate graphical entities for a specific graphical Representation, which are stored inside Representation Links. Even though these semantical objects might need graphical entities to represent them, the object model and the Representation system should not know too much about the actual graphical engine in use. This might be a CAD system or a graphical kernel, combined with a scenegraph framework, but the point is that the data structure is not aware of this implementation. Graphical entities are not allowed either to know anything about the Representation and the graphical engine. These graphical entities are simple light-weight classes, which are only used to pass information from the semantical entities through to the classes used to generate the graphical output. The line which is used to represent a part of some CAAD Entity is only a way to pass data around. At the moment the graphical output for a particular Representation is generated, the abstract line is translated to the drawing commands used to generate a line using the graphical engine. As a result, the graphical engine, the graphical entities and the CAAD Entities are almost independent of each other. This independency is an important goal in the current implementation. An older prototype suffered from the dependency of CAAD Entities on the graphical entities used to represent them, which was not a good and clean solution. Thanks to this decoupling of classes it was rather straight forward to port the original prototype to different graphical systems.

13.1

Graphical Representations

13.1.1

Working of Graphical Representations

Representations have generic properties, such as scale and viewing type. They keep a Scale Level and a Design Phase and request the CAAD Entities to generate a particular representation. 311

312

Chapter 13. Representations

As an example a plan Representation, which is a 2D view, might set its scale to 1:100, for the Sketch Design Phase at the Space Scale Level. It displays the new situation for building phase 1. All this information is passed through the available CAAD Entities, which in return pass a list of abstract graphical entities through to the Representation Links. The moment an actual display of this Representation occurs, the system will translate the abstract graphical entities to drawing commands for the current graphical engine, which are then called in an optimized fashion, allowing for a smooth and interactive display. A small amount of metadata are stored alongside the generated entities, to be able to retrieve the related CAAD Entities, when graphical entities are selected in the view. They form an interface to the underlying data. The moment the CAAD Entityâ&#x20AC;&#x2122;s properties change, the Representation for that CAAD Entity is generated again and new graphical entities replace the existing ones. The CAAD Entity stores a list of Representation Links, which link the generated abstract graphical entities with a certain Representation. The entity might look different for each active Representation and can in some cases even be invisible, if the display of an entity is irrelevant for a particular Representation.

13.1.2

How many Representations are required?

If we imagined five types of Representations, they could be a 2D plan, a 3D model, a Textual View, a Hierarchical View and a Schematic Diagram. We also have Masterplan, Block and Space Scale Levels and three Sketch, Preliminary and Construction Design Phases. The combination of all of them would lead to 5 Ă&#x2014; 3 Ă&#x2014; 3 = 45 different Representations. Even if we imagine that some of them might hardly ever be used, any new characteristic, such as building phase or display scale, multiplies this number. In this simplistic strategy, each combination of display representations might become a new Representation. This automatically leads to a large set of possible Representations, for which there is only a small subset of relevant and commonly used combinations. The opposite approach is to have the Representation change its parameters, so the generated graphical entities adjusts. This is the approach where each view will have its own display properties. In the prototype, however, a hybrid approach is applied. The Project keeps a list of active representations, which can be set to any combination of display parameters, and which can be applied to the view. The user has the freedom to decide which are the relevant Representations and can then switch freely between them. There are only as many Representations as the user needs to display the design. Each Representation is in fact a combination of settings for all the possible characteristics a Representation can have. The approach where each graphical window has its own parameters and each window becomes a new Representation, is not followed. This would lead to

13.1 Graphical Representations

313

problems of management. It would become hard to make changes and closing a window would effectively destroy that Representation.

13.1.3

Sharing Graphical Entities or not?

The current implementation stores a list of graphical entities for each Representation inside the CAAD Entity. As a result, chances are that for many representations, where the display of a particular CAAD Entity might be identical or almost identical, a new set of graphical entities is required. It is possible to further optimize this approach, by generating as few individual graphical entities as possible, while at the same time sharing the entities that are required in several representations. The same line that represents a beam in the Sketch Design Phase could be reused in the Preliminary Design Phase. Even though it could probably be managed, using Reference Counting 1 or Smart Pointers 2 , this approach was not elaborated. The current implementation, which creates different sets of graphical entities for the different representations seems to perform quite well. Additionally, the extra amount of graphical entities is only temporary, since they are not stored with the rest of the project data. They will be regenerated when objects change or when a project is closed and reopened. The regeneration of these graphical entities is only needed when the connected CAAD Entity has modified. The display of graphical entities is done by the graphical engine and is optimized. Changing the view, selecting entities or adjusting the display settings does not alter the building data, so it is not required to generate the graphical entities again.

13.1.4

Showing and hiding parts of CAAD Entities

Since the generated graphical entities receive some common information about the active representation, a custom display can be derived for each CAAD Entity. The Scale Level and Design Phase parameters of the current representation directly influence the appearance of the CAAD Entity. A wall might be represented as a simple line, for a plan view at a scale of 1:200 and at the same time be generated as a series of volumes, with different material properties for the different composing layers, in a 3D view in the Construction Design Phase. Some elements might even have no representation for a particular Scale Level. This is knowledge that only the CAAD Entities can have, so this is managed in the implementation details. The system only requests the graphical entities and passes along the information about the chosen representation. 1 Counting the amount of references to the object, to be able to clean it when the reference count reaches zero. 2 Instead of a regular C++ pointer, a smart pointer is used to facilitate memory management. Otherwise, the programmer has to explicitly call a delete method, to remove the object from memory and be sure that no other class is still referencing this object.

314

Chapter 13. Representations

The graphical entities do not carry any data about the CAAD Entities, allowing them to stay fairly light. They do have some additional data to indicate their display style, to be able to correctly choose the line type or color. This is necessary, since they are generated at runtime and might be recreated several times during the design process. However, these graphical entities do not contain properties such as color or line type, but rather keep a function index, which only takes a single integer or pointer. When the drawing routine receives such a graphical entity, it can call upon the desired drawing command to choose a particular color or line type. All the line needs to know is that is represents a cutting line, so the drawing routine can call the necessary methods to display it as a thick, continuous line, with the color based on the object type or material used.

13.2

Elaborating the functionality of Representations

13.2.1

Creating Elements

Upon creation of a CAAD Entity, which is contained in an Element, all necessary graphical entities are automatically generated and attached to the CAAD Entity for all possible Representations.

13.2.2

Removing Elements

Since all Representation Links are destroyed alongside the Element, all generated graphical entities are cleaned up as well. These Representation Links maintain the connection between a Representation, the CAAD Entity and the Graphical Entity that represents this CAAD Entity, as shown in Figure 13.1. A special note, however, has to be made considering the Command History. To be able to undo the deletion of an Element, it is not actually destroyed, yet moved to a special, invisible list of Elements. When the user demands the undo of an Element removal, it is placed back again in the list of Elements, with all its settings and properties intact. This is explained in Section ?? on page ??.

13.2.3

Modifying Elements

For each Representation Link, all used graphical entities are destroyed and then generated again from the CAAD Entity. This assures that the full representation is up to date. A possible optimization lies in the storage of version numbers with the representations, so the system can check if the generated graphical entities are valid for the current CAAD Entity. What is implemented are update hints. When the application requests an update, a hint is passed informing the Project if this is merely a selection update,

13.2 Elaborating the functionality of Representations

315

Graphical1

CAAD Entity

List of Rep. Links

Link1

Representation1

Link2

Graphical2

Link3

Graphical3

Link4

Representation2

...

Graphical4

Figure 13.1: CAAD Entity and Representation Links the modification of individual elements or the full regeneration of the complete Project representation. Selecting Elements will graphically change their Representation, but this is performed in the graphical engine and not in the actual generated Representation. The color, transparency and line type is adjusted to give a visual clue about which elements are selected, without the need to fully update their Representation.

13.2.4

Exporting Representations

Since the Representation of a Project is a series of generated Graphical Entities, it is possible to export them into other formats or to transfer them to a Rendering application. The advantage is that only the graphical entities have to be exported, which improves and simplifies the export process. A Rendering test does not have to be aware about the actual building model and only needs to provide methods to generate the commands for the display of most common graphical entities. This can be as simple as writing one method to display a polygon, when the 3D model has to be Rendered.

13.2.5

Creating Representations

The Project will step through all CAAD Entities and request a new graphical Representation, passing along the information about the newly created Representation, as shown in Figure 13.2. This approach allows the Representation to be unaware of the implementation details of the particular CAAD Entities, enabling the list of CAAD Entities to be extended at any time.

316

Chapter 13. Representations

if physical Application

Project

Elements

CAADEntity

Type Generate

Figure 13.2: Generate Graphical Entities Defining a new Representation type in the data structure, however, will require the CAAD Entitiesâ&#x20AC;&#x2122; implementation to be adapted. It is possible to have Textual or Listing Representations that do not require any adjustments to the CAAD Entities. The common CAAD information is retrieved through their generic interface, hiding implementation details.

13.2.6

Adjusting Representations

When the characteristics of a Representation are adjusted, all CAAD Entities have to regenerate their graphical entities with the updated parameters. For common design use, it is best to define a few common Representations and switching between them when required.

13.2.7

Removing Representations

All graphical entities are removed, if they reference this Representation. This is asked through the Representation Link. No other entities need to store them anymore and they can be regenerated at any time when required, such as after the undo of the removal operation.

13.3

Characteristics of Graphical Representations

Even though the real data are non-graphical, it is still necessary to generate graphical entities to be able to display anything to the user. Common CAD software uses graphical characteristics such as color and line type to visually display information about the represented entities.

13.3.1

Color

A color is used for several reasons in graphical representations for architecture. In a schematic drawing, it is used to distinguish between different functions, while a 3D model might use color as an indication of the used material. It is required that the requested colors are not managed by the graphical entity, but by the Representation system, based on information that is derived from the CAAD Entities. The translation of the building code to a chosen display color is performed by the Representation.

13.3 Characteristics of Graphical Representations

13.3.2

317

Line Type & Line Width

In a similar way, the displayed line types and line widths are not stored with the graphical entities, but derived from the CAAD Entity. In architectural representation, the choice of line types is still influenced by manual drafting practices. The palette of visually differing line types has to be kept rather limited, to help the readability of drawings. Dashed lines are typically an indication of hidden entities, while dash dot lines are usually axes. Even though printers and most plotters can print any combination of line widths and line types, the legibility of these thicknesses is limited. Most users will have difficulties to visually distinguish between more than three or four different line thicknesses. It is usually sufficient to have the distinction between about three thickness variations, going from fine over medium to thick.

Figure 13.3: Only a few different line widths are required Thick or medium lines are normally an indication of geometry which has been sliced, but they are also used in annotation, such as for titles, axes or section lines. Hatching and dimensioning is usually done with a fine line, to not interfere with the rest of the graphics on a plan. In a hidden line elevation or section view, there is usually the distinction between fine lines for projected geometry and thick or medium lines for cut geometry. A line width that gets too large will overlap with other entities and will obfuscate the drawing.

13.3.3

Hatching

Hatches are still widely used, even though the limitations of former pen plotters are non-existent today. A hatch is a visual indication of a property and is used commonly for sectioned geometry, where it will indicate materials or construction. These hatches define their sizes in output dimensions, such as printing an angled line every 2 mm. But hatches can also use full scale sizes, when they indicate a visible pattern, such as brickwork in a facade or tiles on a floor plan.

318

13.3.4

Chapter 13. Representations

Textures & Materials

Texture mapping is a common technique to generate realistic looking material information on 3D models. The advantage of a texture map is the simplicity with which a complex looking material can be simulated by projecting a photographic image onto the geometry. The current generation of graphic display adapters, such as the nVidia and ATI brands, has full hardware support for texture mapping. It is perfectly possible to support texture mapping, with little speed penalties for the processor, since they are handled through the display hardware. The limit is usually the available texture memory. This is still rather limited in common office computers, slowing down the application. But given the fact that most common workstations and decent desktop computers have good texture support, it makes sense to fully integrate texture information in the application. The information about the required texture map is stored as filenames with the Materials, alongside the full size in real world coordinates, allowing an automatically generated mapping projection.

13.3.5

Graphical Information and Representations

Inspired by the concept of Cascading Stylesheets 3 , a similar approach might be used for the display properties. Such style sheets define display styles both on a global level and on a local level. The most common parameters are defined globally, while individual types of entities and even individual instances of entities may override these global settings. Based on the function and the material of the CAAD Entities, the Representation will define global display characteristics. The color of a Masterplan Element will be mostly defined by either its core function, through the associated Activity or by the main material of its facade, which might be requested from the exterior Physical Elements. Individual entities might override this representation with more detailed graphical information, such as the Activity for a Space or the material of a Physical Element. A schematic representation might even disregard all color information.

3 http://http://www.w3.org/Style/CSS/ and http://en.wikipedia.org/wiki/Cascading Stylesheets

Chapter 14

Transitions Introduction The Conceptual Model for CAAD [Neu92] describes a set of Scale Levels and Design Phases. The Transitions between them have been discussed in earlier chapters, but the implementation was not described in detail. Each transition will bring the project data from one Level or Phase to another one. There are three Scale Levels and three Design Phases, but it is possible to define additional Levels, if required. A Transition is a series of changes to the building data, to enable the gradual enrichment of the project with additional design data and an approach to allow the data to follow along with the design updates. Even though these transitions usually imply enrichment, it is possible for the architect to elaborate a part of the project into more detail, e.g. to check a construction detail, but then opt to not follow this concept any further. A certain solution might not be desirable and its data might be removed again, after evaluation. It would be wise to allow the removal of this additional data, based on the requirements of the designer. This might be supported by a custom cleanup routine. Some of these Transitions change properties of entities, such as the switch to a more detailed composition or the change from Planar Elements to actual Building elements, while other Transitions have to create additional entities. Yet other Transitions merely change the display or Representation settings, without any modification to Project data. This is apparent for most reverse transitions. The main scheme of Scale Levels and Design Phases defines the two main Transition types. Transitions between Scale Levels for a particular Design Phase happen vertically in the scheme. The focus of the design changes and other entities are shown then in the previous Scale Level. There are two possible directions. The top-down approach is quite common, since it is the process of developing a design from a general Mass model to a model with specified Physical Building Elements. The reverse transitions happen in a bottomup approach, where the model starts from the construction details, which are assembled to a full building model. This is the case of a building system, based on a certain construction technology. 319

320

Chapter 14. Transitions

Transitions between Design Phases for a particular Scale Level are the second type, which happen to be horizontal in the main scheme. They change the detail focus, from rough to detailed and back. No new entities will be created, but the elements will change their composition.

14.1

Transition Rules

Introduction The implementation of Transitions happens through a series of Rules, called a RuleSet. A RuleSet defines the required modifications to objects and Representations. Filters are used to control on which elements a certain Action will be performed. This is best illustrated by some examples. • All vertical Planar Elements are transformed into Walls with an empty Composition. • All Walls which are on the exterior of the building will receive the default exterior Composition. • All sides of Spaces which do not coincide with a Physical Element will generate new Physical Elements, their type being based on the orientation. The UML diagram illustrating these different concepts is shown in Figure 14.1. The different classes will be briefly described.

Action list<Command> Perform()

Base

Create

Modify

Remove

Perform()

Criterium Property LowLimit HighLimit ComparisonOp CheckObject()

Rule list<Base> list<Action> 1 list<Filter> Execute()

* *

Filter 1 bool:inclusive list<Criterium> FilterList()

RuleSet list<Rule> Execute()

Figure 14.1: UML Diagram of Rules, used to implement transitions

14.1 Transition Rules

14.1.1

321

Rules

A Rule can be seen as a sequence of operations or Actions that are executed on a pre-selected list of entities. Ideally, the Rules are predefined, so the user can simply apply them, but during the development, the precise elaboration of these Rules is still experimental. Rules operate on generic objects, which means that they should be applicable to all derived objects, regardless of their implementation. Rules contain Filters, which limit their Actions to only occur for entities which pass through this filter. Filters can be based on the Classification Code of the entities or on Property names.

14.1.2

RuleSets

In the data structure, a RuleSet is created as a series of Rule objects, which can be instantiated in the project. Together, they define a series of actions that will be applied to the project data. This is similar to a script, but more Object Oriented. A script is just a text fragment, preferably in some external file. A RuleSet is a single object, which can be stored alongside the rest of the project, since it is using the functionality provided by the Property System. A RuleSet derives from the Rule class, allowing RuleSets to be included in another RuleSet. They have the same Execute() method as a Rule, which is simply to call Execute() on all their own Rules.

14.1.3

Filters

A Filter receives a list of objects, which it needs to filter and Criteria to define the comparison. A filter can be exclusive or inclusive, removing or retaining the elements from the list. This is stored in a Boolean value, which can be toggled between both states. There are Data and Object Criteria. • A Data criterium has a Property name to define which property to compare with. It also includes the allowed range for this property using a low and high limit and the comparison operator, which can be selected from 6=<≤>≥=. • An Object Criterium also has a Property name, but contains a reference object to compare with. It could be used to check if the object to check includes a reference to the comparison object. It includes the two operators = and 6=. A Criterium receives an object and will perform a check, to see if the object passes the criterium. Additional geometrical filters could be defined for the Reference Points: e.g. point in polygon and all points in polygon.

322

14.1.4

Chapter 14. Transitions

Actions

Finally, the Action class will be used to perform the actions on all elements that survive the filtering. Elements that do not pass the filter are not altered in any way. There are Actions to Create, Modify and Remove objects. All these Actions will use regular Commands, allowing the result of a complete Rule to be stored in the Command History and to be undone when required. This allows experimentation with Rules, Filters and Actions.

14.2

Synchronization between Scale Levels or Design Phases

When a Transition is executed, the building model should not be compromised. The freedom to make Transitions in all directions poses some difficulties. When a user makes modifications, they might have consequences on other Scale Levels or Design Phases. When the user steps back, the model has to follow along with those changes and not simply fall back on the old version of the design for that particular Level or Phase.

14.2.1

Scale Level Transitions

After a Masterplan Element is created, there might be no other elements to conflict with, but when the user steps to the Space or Block Scale Level and updates the model, stepping back to the Masterplan Level requires an update to the Masterplan Elements as well. The connection between elements on different Scale Levels is managed with the link classes. The Dependence Links can define the dependency of a Space with its enclosing Masterplan Element. But the linkage itself is not sufficient to update the enclosing volume. When a Masterplan Element is further elaborated, it is subdivided into Spaces, which can be subdivided further until all required rooms and spaces are defined. Subdivision does not change the enclosing volume, but adjusting the contours of the individual Spaces will influence the envelope of the Masterplan Element. Through the use of shared Reference Points, there is a system of common anchors, from which the Elements on different Scale Levels depend. Translating a corner point from a Space that lies on the building contour will directly adjust its enclosing Masterplan Element, so that poses no particular problems. Adding Spaces and removing or inserting Reference Points, however, does change the envelope. This means that the enclosing Masterplan Element, from which the Spaces seem to be dependent, is depending itself on its enclosed Spaces. This means that the Masterplan Element changes its behavior. Initially, it is completely independent, but after elaborating the Spaces on the Block Scale Level,

14.2 Synchronization between Scale Levels or Design Phases

323

it has to be regenerated when the Scale Level makes a transition back to the Masterplan Level. This is effectively a task the Transition has to perform. After the Masterplan Element is generated again, as a union of all its enclosed Spaces, it can be manipulated as usual through its Reference Points. But the synchronization problem is not gone, since the removal or insertion of new Reference Points on any of the Levels will influence all these elements. More profound adjustments of the Masterplan Element, such as changing the amount of Floor Levels will influence a rather large amount of entities. The Reference Points need to be accompanied by Reference Heights, which are used to define the elevation of Space Elements. The removal of a story on the Masterplan Level will have to remove all affected spaces. Their selection can be filtered based on the Reference Levels, which is not difficult, but that in itself is not enough to find all affected Spaces. The ultimate goal is a series of Spaces without gaps which fill the complete volume of the Masterplan Element. Boolean operations on solid volumes and collision checking to detect overlaps between Spaces seem to be required. To detect gaps, it is possible to subtract all enclosed Spaces from the Masterplan volume and detect remaining volumes. Their volume is then an indication of missed volumes, while their connectedness or separation into discrete â&#x20AC;&#x153;islandsâ&#x20AC;? can be used to create the missing Spaces. It is not expected that in a relative loosely coupled system of design entities all these conflicts will automatically be solved. The user carries an important responsibility to maintain a correct building model. An alternative approach could define placeholder elements together with any created Masterplan Element, which are then replaced with regular building entities during a transition. This seems a valid solution, but poses almost identical synchronization demands. There is no strict order of operations, so the user should be free to start from an intermediate Scale Level and step back and forth to other levels at any point in the design process. Forcing the complete model to be managed from one of the Scale Levels omits the goal of free exploration and design operations on any level. In [HC02] an approach for a coherent Spatial Model is discussed, although this solution is not followed in the prototype. The main reason is that this system defines the whole model only from the Spaces and thus ignores the possibility of other Scale Levels. The approach in IDEA+ makes use of the Reference Points, to enable connectivity between entities on different Scale Levels. This ensure that modifications to entities on one Scale Level are retained with their related entities on other Scale Levels. Reference Points thus serve an important role in connecting and anchoring all entities over the different Scale Levels. At any time, the designer can insert new entities, move their control points around and then merge or split the entities, to weld the Reference Points together.

324

14.2.2

Chapter 14. Transitions

Design Phase Transitions

In Design Phase transitions this is no problem, since all entities stay at their current position, while only their composition is affected. The Transition needs to transfer simple compositions to more complex ones, but only when the transition happens from a low detail to the high detail direction. The reverse transition does not modify entities, but only affects the active Representation. The Transition will also transform any remaining abstract Planar Elements to real Physical Elements. When Masterplan Elements or Spaces are created, no enclosing building elements exist. The moment the Space Scale Level is reached for the first time, new enclosing building element will be created. Horizontal elements will become Floors and vertical or slanted elements will become Walls. The upmost Spaces will also generate Roof Elements. Through the availability of conversion routines between these different types of Planar Elements, the user will have the possibility to change Elements that are not created according to the desired type. But from then on, the enclosed building elements are created and stay connected to the Spaces through the Reference Points. Design Phase Transitions then fill in more detailed information. Initially, these elements will have a default Composition and the Transition will replace the composition with more suitable ones. Floors will receive specific floor compositions, while the walls are separated into interior and exterior walls. This is a process that should be performed automatically, but only when a transition occurs from low detail to higher detail. The user can change elements to other Compositions at any time and this should not be adjusted again by the Transition. Design Phase Transitions are only allowed to replace default empty Compositions. A possible strategy is the decoupling of CAAD Entities in different parts. The initial, simple compositions only define the contour of a Planar Element, while additional sets of properties are added in a Design Phase Transition. This additional set of properties could then be ignored instead of removed in the Representation of a simpler Design Phase. A careful choice of non overlapping properties is required, so the additional set does not conflict with the simple set from the Sketch or Preliminary Design Phase. But it seems easier to simply create a small set of replacement methods, which directly adapt the CAAD Entities if needed. This is only possible because there is a complete separation between the graphical representation and the actual building elementâ&#x20AC;&#x2122;s data. This is not possible in a traditional CAD system, where the data are attributes of a graphical element. Consequently, the IDEA+ data structure stays independent from any graphical kernel or from a particular CAD-application. The representation could use solids, but it might as well be a polygonal surface model or even be based on a series of simple wireframe lines. The data structure might be even integrated into an existing CAD application, where the underlying graphical engine will be used to generate the representation of the building data.

14.2 Synchronization between Scale Levels or Design Phases

14.2.3

325

Transitions require proper Connections

As discussed in Section 7.4.3, the connections between Planar Elements need to be specified when elaborating the design into more detailed Phases. While the implementation of any possible connection between any configuration of interconnecting Planar Elements is beyond the scope of this research, a pragmatic approach has been studied, to manage common connections. Definitions To this extent, Connections between Planar Elements are defined. It is assumed that Planar Elements can contain different layers, as defined by the Layered Composition they reference. A single Composition will have multiple layers, each referencing a material and having a specified thickness. While the section of a Planar Element might be adequately described using a single Layered Composition, the element is not homogeneous at its sides. In particular, different layers from a Planar Element will have different offsets when they connect with other Planar Elements. Most Planar Elements, however, have three main layers. There is a Core layer, defining the structural components and there can be two optional Finishing layers, on either side of the Element.

Finishing B

Core

Finishing A

Finishing B

Core

Finishing A

In the implementation, these three layers will each reference a Composition, allowing the core and finishing layers to be composed of different materials. The connection will then be elaborated for the three main layers, instead of the individual composing sub-layers. Typical examples are shown in Figure 14.2.

Finishing A Core Finishing B

Cavity wall as a 3-layered structure

Interior wall as a 3-layered structure

Compound Floor as a 3-layered structure

Figure 14.2: Example of layers in Planar Elements To define how layers will interact, a Layer Priority can be defined. Layers with higher priority will be able to pass through layers with a lower priority. The Priority is a property of the layer and might be adjusted by the designer to adjust particular connections beyond the default solution. When two layers with the same priority try to join, they will both be joined and will not penetrate further into the connection. Otherwise, the layers with higher priority will always pass through the whole Connection which will not be a structurally sound construction, especially with regard to thermal capabilities.

326

Chapter 14. Transitions

The edges of Planar Elements will then be specified using a Connection class. This class will define how the different layers interconnect. When two or more Planar Elements connect, they will reference the same Connection class. This allows the elements to retrieve the necessary layout of a particular connection from the Connection class, without the need to have access to the other Planar Elements. These Connections are found whenever Planar Elements have Reference Points in common. For the chosen building model, two connection types are identified. They are illustrated in Figures 14.3 and 14.4

Figure 14.3: Horizontal Connection between Planar Elements

Figure 14.4: Vertical Connection between Planar Elements Horizontal Connections occur when single Reference Points are shared between vertical elements, such as walls. Each wall which connects to a single Reference Point needs a reference to the same Connection. All walls will have a different orientation, with regard to the Connection. This is expressed with an Angle. Additionally, the different walls might have different heights, resulting in the possibility of having multiple connections, stacked upon eachother. While not further implemented, this seems to be relatively straightforward to support, extending from the initial type. To complicate matters, each of the different walls might have a different offset relative to its Reference Line and more generally, they might not all be vertical. They might not even connect in the same coordinate, but still

14.2 Synchronization between Scale Levels or Design Phases

327

join relatively close to this point. These complications are not supported with the current implementation. Vertical Connections occur when two consecutive Reference Points are used by multiple elements, forming a Reference Line or Line Segment. This is a common connection between walls and floors. In this case, there are only four possible directions which interact. The upper wall, the lower wall (which might be identical to the upper wall) and the two possible floors, on each side of the connection. Additional complications will arise when circular edges and non-vertical elements need to be supported. The routine that joins and splits Reference Points is responsible for detecting all occurring Connections and assign them to the respective Planar Elements. Changes in a single Connection are then visible to all connected Planar Elements, without the need to access the properties of other Planar Elements. Connections as matrices The implementation will model a single connection as a matrix of cells. A Cell has a value and has a specific direction. Depending on the direction and value, a Cell can override the value of its neighbor cells. See Figure 14.5.

Connectivity between Cells

North West

CELL South

East Value + direction

Figure 14.5: A cell as the underlying object to model connections. E.g. when a cell has a neighbor cell lying to the North, with direction South and a value higher than the current value, the other cell will override the current cellâ&#x20AC;&#x2122;s value and direction. When two equal values are found, they lock each other out and the direction is turned off, preventing the resulting cell to dissipate any further. Different cells will be connected to form a Matrix , as illustrated in Figure 14.6. Each cell in the matrix initially starts as empty. Alongside the matrix are four Vectors, called North, East, South and West. They contain the priorities from the layers arriving from the different directions. These Vectors do not have to contain cells, allowing the different cells to be optionally empty. This allows the system to model a T or an L-connection with the same method.

328

Chapter 14. Transitions

5s 3s 1s 0x 0x 0x Cells matrix

North Vector 2w 4w 0x

Single Cell

5n 3n 1n

Figure 14.6: Using a matrix of cells to model a Connection A solver routine will then fill in the matrix, based on the given priorities. Higher priorities will dissipate further into the matrix, until they reach the edge of the matrix or until they meet a cell with equal priority. Cells who have been fully solved will be locked. The rows and columns of cells at the side of the matrix stay locked. An end user might influence a particular Connection by editing the values of the priorities. When a Planar Element needs to be represented, it can access the Connection and retrieve just how far each layer needs to extend. All that is required is the depth, which is the sum of the widths of the layers of the interconnection direction, up to the point where the given priority ends.

Solving the matrices The algorithm to solve the matrix will make sure that every cell inside the matrix receives a final priority value and a direction. This is implemented as a single Connection Class with the Cell as a private class, invisible for other classes. This allows independence between the classes and forces the solving process to occur without any additional requirements or knowledge over the Planar Elements. The Connection class has methods to fill in the priorities and will then generate the necessary cells. Each cell is implemented as a simple class, which has four possible neighboring cells, a current priority value and a current direction. A cell can also be locked, to indicate that it may not be recalculated any further. This is necessary for the border cells. While there are four main directions, being North, East, South and West, the implementation defines an additional direction None which indicates that the cell looses its direction. This occurs when two equal cells meet, to make sure that they stop penetrating any further. The actual algorithm is expressed from the point of view from a single cell and will be called repeatedly by the Connection class. With each step, all the cells are recalculated. The Connection class stops the calculations when no cells are being modified during a solving step.

14.2 Synchronization between Scale Levels or Design Phases

329

// 1. Do not solve locked cells! IF cell.lock IS TRUE FINISH END IF // 2. Retrieve maximum from neighbours CREATE counter1 FOR EACH neighbour IF (direction IS valid) // e.g. north cell that goes south INCREASE counter1 SET neighbour TO valid IF (neighbour.value > maximum) SET maximum TO neighbour.value END IF END IF END FOR // 3. Do not resolve a cell which is already at maximum IF (cell.direction IS NONE) AND (cell.value IS maximum) lock cell FINISH ELSE unlock cell END IF // 4. When more than one neighbour was valid // set the cell to the maximum value CREATE direction possible SET possible TO cell.direction IF (counter1 > 0) SET cell.value TO maximum END IF // 5.

Retrieve correct direction from neighbours

CREATE counter2 FOR EACH direction IF (direction IS valid) AND (direction.value IS maximum) INCREASE counter2 SET possible TO direction END IF END FOR // when more than one neighbour equals maximum IF (counter2 > 1) SET cell.lock TO TRUE SET cell.direction TO NONE ELSE SET cell.direction TO possible END IF FINISH

This implementation was tested for different matrix sizes, from two by two till four by four. A testing routine tested all possible cases and solved about 10.000 cells per second. To prevent the solver to continue forever, the steps were repeated at most 10 times, in which case an error would be reported. This allowed to finetune the algorithm to always find a valid solution. While it was not written beyond a four by four matrix, it is assumed that the algorithm is stable enough to support it. With more complex Connections, it might be interesting to have support for more cells, to allow offsets with Planar Elements but this was not tried.

330

Chapter 14. Transitions

Examples Figure 14.7 displays a few results that can be obtained. A single column, a two by two L-connection and a two by two X-connection are illustrated.

1s 1s 1s 1s

2s 1s 2s 1s 2s 1s 2x 1x 1w

2w 1w

2e 1e 2e

2x 1s 2x 1e 1x 1w 2x 1n 2x

2w 1w 2w

2n 1n 2n Figure 14.7: Example results of solved matrices

Note that higher values will not necessarily dissipate throughout the whole matrix, since they will stop when they encounter cells with equal values. A more practical examples is illustrated in Figure 14.8.

Figure 14.8: Solving a common wall-floor connection A Cavity wall and a compound floor intersect. This occurs when two consecutive Reference Points of the floor are also used by the upper and lower wall. The example illustrated how the Core of the floor element will penetrate the load-bearing wall, but will not pass through the finishing layer, including an insulation layer and the facade bricks. Also notice that the floor finishing will prevail over the wall finishing in this example. Figure 14.9 is the translation of the example which was originally displayed in Figure 7.35 on page 213. This illustrates how a more complex configurations might be solved using additional rows or columns. The algorithm is not tied to the actual amount of layers, so in theory, matrices involving 10 by 10 cells are solvable.

14.2 Synchronization between Scale Levels or Design Phases

2e 1e 6e 2e 4e

3s 3s 3s 6e 2e 4e 0x

6s 6s 6s 6x 2e 4e 0x

3s 3s 3s 3s 3s 4x 3n

331

0x 0x 1w 2w 4w

Figure 14.9: Solving a more complex walls-floors connection Limitations The order in which the matrix is solved creates an implied priority to solve opposing cells with identical priority. Currently, the North direction will prevail over the South direction. However, the final result is still a valid solved solution. On the left of Figure 14.7 the single column matrix illustrates how the order of solving cells results in the North value dissipating further than the equal South value. While the approach to use a single matrix seems to solve many different connections, it was not adapted to support full freeform connections. Especially when connecting different elements using different directions that are not orthogonal, the solution will not solve all combinations. However, as illustrated in Figure 14.9, reasonable results can be obtained for many current connections.

14.2.4

Design Phase Transitions introduce Thicknesses

In the Design Phase Transition from the Sketch to the Preliminary phase, all available Planar Elements will be replaced with real Physical Elements. These elements will have a thickness and the alignment of the elements. The exact choice of this alignment stays a responsibility of the designer, so the system will initially center all created elements around their reference line or reference plane. Each element can receive an offset, which moves the element relative to its baseline or reference plane. There are situations where the transition from a Sketch Design without thickness information to the Preliminary Design with thickness information requires the elements to be moved. This is the case when the walls from a corridor will be placed too close to each other, leaving not enough room to pass through, according to existing building regulations. It is assumed that future error checking tests would be able to discover such problems automatically, but for now this is left to the responsibility of the architect. To enable this, a more elaborate checking mechanism has to be created,

332

Chapter 14. Transitions

which is a huge undertaking. This could be a potentially interesting evaluation test to elaborate, comparable to the commercial Solibri Model Checker software, as discussed in Section 1.8 on page 41.

14.2.5

Transitions and their effect on Representations

The transition between Scale Levels and Design Phases will necessarily adjust the active Representation, since they are stored as attributes from the Representation. The result of such a transition is the forced regeneration of all graphical entities for the CAAD Entities. Because the current Scale Level and Design Phase are properties of a certain Representation, it is obvious that the Transition has to update the current Representation. This leads to certain elements not being displayed anymore, while other elements are created during the transition. Graphical Entities are created and linked to the CAAD Entity to which they relate.

14.2.6

Transitions and their effect on Spaces

When a design is started from the Masterplan Scale Level, it might make sense to generate Spaces from the Masterplan Blocks, when a transition to the Block Scale Level is being made. The division in floor levels is the only information that is available at that time. Each floor level will become one Space element, sharing the Reference Points from the Masterplan Block. Once these Spaces have been generated, they can be modified at will, which can introduce conflicts with the enclosing Masterplan Element. It can neither be allowed to generate new Spaces when the user demands a transition to the Masterplan Level and then back again to the Block Level. The Masterplan Element has to remember which Spaces it is enclosing. Since this is mainly defined by the contour, this can be recalculated from the used Reference Points. This might change during the design process, forcing the designer to be responsible for the coherence between the elements on the different Scale Levels. Once a Masterplan Element has been subdivided into floor levels, it is not the intention to generate new Spaces each time a Scale Level transition is performed. Changes to the contour of a Spaces will adjust the contour of the enclosing Masterplan Element, since they share their Reference Points. Newly inserted Reference Points have to be noticed in all related elements. When a new Reference Point is inserted between two existing Reference Points, all other CAAD Entities that reference the same two points in sequens will have to insert this new Reference Point too. Even then, the user still faces the task of making sure that both Scale Levels are valid representations of the design. Another approach could be to constrain Spaces. The acceptable adjustments of a Space could be limited to modifications that keep them fully enclosed by their

14.2 Synchronization between Scale Levels or Design Phases

333

related Masterplan Block. Typical examples of Masterplan Elements that might restrict Spaces include facades, fire compartiments, elevator shafts or staircases and the main circulation parts.

Dependencies of Spaces A Space, which is mainly defined by its contour and height, represents a simple room. They behave quite similar as the Masterplan Elements. But Spaces are also defined as an enclosed volume. The enclosing elements are the Physical Elements, which contain walls, floors and roofs. The Masters Thesis of [Van02] elaborated a method to generate the available Spaces inside a design, but required a â&#x20AC;&#x153;waterproofâ&#x20AC;? model, containing no gaps between the surfaces. If this is the case, the algorithm developed in the thesis allowed the automatic detection of all available spaces. This utilized a sweep algorithm, intersecting a mesh geometry and following all connected faces. The algorithm is generic enough to find all Spaces, but it requires an error-free model, containing no gaps or overlaps. This could be performed on the faces which represent Physical Elements, but probably only after a preprocessing step, to clean up the geometry. A simplified approach, ignoring 3D information, has been used in another Masters Thesis [Kep01], where an interactive method to enter a building layout was elaborated. This required defining the model on a grid and all walls had to connect at their endpoints. A T-connection was simplified by splitting the walls so only connections at endpoints remained in the model. Then it was straightforward to generate the enclosed areas to define the spaces. None of these algorithms have been integrated into IDEA+ at the time of writing. Instead, it was chosen to enable the user to create a correct spatial model, by using the Reference Points. Dragging these points close enough to other points and using the join command, they can be interconnected. This is an approach that is simple enough to use and yet gives enough control to the end user. That said, it would be beneficial for this research project, if this approach was more thoroughly tested in design experiments, to evaluate and possible improve this working methodology.

Correct Spatial Model There are some demands on the modeling of Spaces to enable a correct and complete Spatial Model. Spaces should not overlap and should preferably be juxtaposed without gaps in between them. [SM99] describes a method of continuous spatial subdivisions, which enforces such a result. The advantage is the coherence which ensures that spaces know about their neighbors and which ensures a fully filled building volume. The system is adaptable, yet it has some inherent limitations. It is not easy to make adjustments that encompass spaces that where not part of the same subdivision. It seems to be a tree-like system,

334

Chapter 14. Transitions

where each element in the hierarchy has one direct parent. It is not possible to switch to another parent. The current version of IDEA+ does not enforce such a method and thus relies on the user for a correct design. The joining and splitting of Reference Points and the choice of supporting a simplified geometry should allow a reasonable amount of effort to come to a correct result. This might be seen as a design interruption. However, since there is one main and straightforward approach in this prototype to ensure a correct building model, it seems workable. The user can disconnect any element at any time and refit it to another position, where it can be reconnected to the other Reference Points. This might be compared with the layout mechanisms in some software applications. In programs such as Maxon Cinema4D or Blender , the whole interface consists of rectangular panels. They can be grouped together, split or repositioned. Panels can be hidden or they can be floating freely. The whole interface can be reconfigured by the end user to allow different arrangements. While spaces in a building model are usually not limited to rectangles, the approach seems comparable. Docking panels is similar to connecting reference points.

Chapter 15

Evaluation Tests 15.1

Data Sets and Properties

Introduction In the course of a design, the architect needs to make decisions. Some decisions are made intuitively, based on both experience and personal preferences, but some decisions need to be verified by calculations. In an application supporting a digital building model, it would be worthwhile to derive the input directly from the existing building database, instead of separately creating input files for several individual tests. The integration of Evaluation Tests into the design application promises to deliver an effortless throughput of data in a format directly usable for the evaluation. Each test needs to adhere to the same rules, defined by the system. They follow similar methods and behave in a similar fashion. As long as test follow the same Interface, they will react correctly in the system. One of the necessary additions to the data structure would be the support of enhancing the entities of the building model with specific data to the test. To enable this, the system allows the creation of additional data fields at runtime, so tests can store object specific data directly inside the objects on which the test is performed. The main reason to enable this support is the impossibility of defining in advance which data are required. Most tests query their input from the existing properties, but they have no place to store the test results inside the project data. When a test is able to add the necessary data fields to existing objects, the project data are kept together in one place. This gives a few advantages: â&#x20AC;˘ The result of a test can be stored directly with the objects. This enables persistence of the test results in the exported IDEA+ files. All data that are not object specific can be stored with the Project object itself. â&#x20AC;˘ The test can store both output and input data. When a data field is calculated by the test, it can be added as a read-only value. This is visible for listings, but can not be modified by the user. On the other hand, an input value that is required by the test, but not provided by the core data structure can be added by the test as well, but specifically requiring the user to prepare these data. Since the results of the test rely on the 335

336

Chapter 15. Evaluation Tests validity of these data values, it is advised that tests rely as much as possible on existing data fields, clearly documenting the required additional input and possibly providing control operations to check the data fields before execution.

â&#x20AC;˘ No additional interfaces are required in most cases, since the generic property system already enables retrieval and editing of the values. â&#x20AC;˘ It is not necessary for tests to store complex mappings between objects and the additional data that are required. The data are stored directly with the objects. Even if an evaluation module is unavailable, the results are at least kept with the objects. If a test would store all data in a separate mapping, it not only needs to synchronize this mapping with the project data, but also needs a method to store and restore the data from external files. In the Property System, the additional values are provided as Extended Properties, as opposed to the Base Properties which are used by the core system1 . Typical examples of value types are strings, boolean values, integers and real numbers. Since Extended Properties form already a part of the core data system, operations such as copying and deleting elements maintain the data. These properties are simply copied along and the removal of an Element cleans the Extended Properties as well.

Property Links and Deep Copy A more complex utilization of adding data to the entities is embedded in the Property Links. Since a link between properties can utilize a formula or Expression, it is possible to store the actual calculation instead of the final result of a test. But the developer of such a test has to be very careful to store only formulas which give a predictable outcome. Otherwise it might be easier to just update the calculated values by simply executing the test all over again. The working of the Property System is explained in Section 12.3 on page 281. In the prototype, this functionality was initially not available. However, by relying solely on the Property System, it was written generically, without any reliance on the other modules. As a result, it was an almost isolated addition to the prototype, with little interventions in the rest of the system. There was an additional dialog to manage these links and the Paste command required an adapted feature to allow a Deep Copy of entities. This is required to create an independent copy of an entire tree of objects and properties, while keeping all internal links and references intact. While this was a non-trivial elaboration, it could be implemented as a single recursive method, in a fairly short amount of code, as illustrated in the following pseudocode. 1 This

is comparable to Extended Entity Data as provided in Autodesk AutoCAD

15.2 Test Interface

337

DeepCopy (element) { // copy data members and objects COPY basic properties FROM element COPY extended properties FROM element // create new instances of objects (not data) // only when owned by this element FOR EACH Property IN element.PropertyList DO IF (Property.type IS object) AND (Property.isOwner IS TRUE) CALL Property.DeepCopy(Property) IF (Property->type IS list) FOR EACH Item IN element.Property DO IF (Item.isOwner IS TRUE) CALL Property.Item.DeepCopy(Item) END FOR END FOR }

The development if IDEA+ relies heavily on this flexible data structure. Defining new properties or introducing new classes requires only small adjustments to the whole system, which speeds up experimenting with different concepts. At the same time, when motivated by certain improvements, the Property System itself was adapted and extended. The introduction of Property Links, as an example, was a complex addition of functionality to the core structure, but at the same time, no changes had to be made to the CAAD module, where the different design entities are defined. This flexibility and generic structure facilitates the elaboration of custom objects, to explore how they can become viable design entities in architectural design software. It is only a minor effort to introduce new design entities into the whole system. While most current commercial CAD or BIM applications offer customization options, such as scripting new library objects and adding new functions, they do this only through their Application Programming Interface (API). The API gives no access to alter the core functionality of the system. By developing a custom prototype application, these limitations are removed and new design entities can be created at will, while being easily integrated into the rest of the system. This is necessary to enrich the application with entities which are more suited to the early design stages, on different Scale Levels. While the prototype is not going to replace commercial design applications, it makes it more feasible to explore new concepts, without the proposed limitations of these existing applications.

15.2

Test Interface

Tests will each have the same interface, allowing them to all function similarily. The main methods are displayed here. Administration These methods are mostly required to identify the test. They can be used to automatically generate the necessary menu handlers inside the application GUI. This includes some functions such as GetName and a function to keep a reference to the Project, called SetProject. This allows the test to retrieve information about the entities inside the project.

338

Chapter 15. Evaluation Tests Tests will preferably be written as generic as possible, but at the same time, since they have access to the project, they can query exactly what they need.

Execution When the user requests a test, in most cases a dialog will pop up, with the method GenerateMainDialog. This is necessary, since a test is only a temporary object and the main test parameters are not a part of the project. This dialog simply displays the parameters of the test, using the same system as the regular property panels. This is possible because the test class also derives from the base object class. When the user closes the dialog, the Execute method is called, which performs the actual operations required for the test. Working with DataSets Some methods to work with the DataSets are proposed. They can be automatically called when loading a test, while the developer of the test can choose to utilize them when these DataSets are required. • The method AddDatasetsToElements allows the test to add a new dataset to certain objects or update the dataset that already exists. • For tests that do not take a long time to calculate, it might be possible to continuously re-evaluate the test, giving close to realtime feedback to the user. It might be set to be recalculated each second or every minute for more complex tests. • Different methods such as QueryDataSets, UpdateObjectsWithDataset and UpdateDatasetWithObjects are proposed for the test to efficiently update the datasets when required. Output of test To really embed the test into the design application, several output options should be provided. They depend on the desired representation of the results. When using options, such as grid or text, an appropriate GUI widget could be used. In some cases, it might be interesting to provide a list of graphical entities, which can then be displayed in the main view. Configuration Since a test derives from the regular Base class, the current export and import functionality might be used to store the settings for the test in an external XML-file.

The elaboration of tests is probably more suited to developers or researchers who are investigating certain simulation or data extraction algorithms. The data structure provides a main entrance point for evaluation test development. A few examples are actually implemented, to a level that they are functional, but they are not exploiting the whole testing interface.

15.3 Example Tests

15.3

339

Example Tests

Two Rendering Tests The test which exports the current 3D representation to the Radiance [LS98] system was explained in Section 8.2.3 on page 244. This test has a few parameters, which influences the output routine. There is an option interactive, which will ensure that the rview program will be used. This interactive rendering mode allows additional tweaking of the rendering parameters, but it is very unstable on MS Windows when using the rather old Desktop Radiance binaries. This program is not available in the current re-structured releases for Linux and OSX. However, when this option is off, the regular full rendering mode is used, which will not display anything on screen and takes a while. For convenience of the user, all exported files can be automatically cleaned up, when requested. The output is actually a series of batch files, which can be edited and called seperately by the user. In the implementation, some parts are platform-dependent, such as the generation of batch files and the external programs that are called. This is obtained with a few macros inside the source code, that make the compilation slightly different on different platforms. As a proof-of-concept, this is not a real problem. It is technially possible to wrap this into platform-independent code, using the QProcess class from the GUI framework of Qt [BS04], but the test module was deliberately created without this external dependency. It is probably a slighty better choice to delegate these functions to an abstract class and use a derived class with the additional framework-dependent calls in the prototype application. Based on the code of the Radiance-export test, an additional test was created which uses the same approach to export the geometry of the building model into the RenderMan Interface Bytestream (RIB) format [AG00], for use with a rendering application such as BMRT or Aqsis, which have been discussed in Section ?? on page ?? and following. While there are still some minor issues with this particular exporter2 , the test has indicated that a large part of the extraction code can be shared between the two tests. This resulted in the development of an abstract Render Test class from which the two specific rendering tests are derived, being Radiance and RenderMan. This evaluation test was originally created as an Add-on for ArchiCAD, using the ArchiCAD API Devkit, which allowed to generate a series of text files for Radiance directly from within ArchiCAD. The add-on does not rely on the building model of ArchiCAD, but interprets the generated 3D representation and the list of referenced materials. The main export code was reused in the IDEA+ data structure. 2 Most notably the incorrect translation of the camera orientation parameters, due to differences in coordinate systems and the order of the applied transformation matrices.

340

Chapter 15. Evaluation Tests

Test on Spaces The most common tests we can perform with Spaces are area and volume calculations which form the basis for most cost estimation tests. The Elements Method [Bou90] utilizes ratios of building elements with regard to the building area. These ratios can be estimated based on similar projects or, when more design information is available, be calculated from the actual building entities. In the Sketch Design Phase, there is usually no detailed information available, so cost estimations are mainly based on the area of the spaces and the assigned Activities. In a situation where more than one Activity is allowed for each Space, the method becomes more evolved. In the current prototype, each Space can host only one Activity. This is a limitation, which will not be valid with all design projects. In future editions, an Activity Distribution will be required, to define the percentages of Activities that will be enabled for a particular Space. This distribution should take into account a variation of Activities over time allowing differentiation between day and night or between week and weekend. There is also the distinction between properties that can be edited and other properties that are only used to store output. The area of a Space is an example of a read-only parameter, which will be updated automatically when the geometry of the Space changes.

Tests as Plugins The implementation and support of tests in IDEA+ is dependent on both the Property System and a common Test Interface. Since it is highly unlikely that the initial implementation already contains all required tests, a plugin system is necessary. By defining a common Interface, which all tests have to obey, it is possible to create the test inside a plugin. Plugins are loaded at runtime by the operating system. Plugins act differently on different Operating systems. They are implemented as Dynamic Link Libraries or DLL-files on MS Windows, as Dynamic Libraries or dylib-files on Mac OSX and as Shared Libraries on Linux and other Unix variants. They can extend the compiled system with additional methods and possibly even additional interfaces. While the current prototype makes no use of plugins, this was tested in an early version. This lead to a more extensive modularization in the data structure. By using some preprocessor macroâ&#x20AC;&#x2122;s3 the whole data structure was split in different modules. Each module could then be compiled, according to the dependencies set out from the main modular structure. Even though it is currently more convenient to create the application prototype with the data structure statically linked, the organization of the code enables it to be generated as dynamic libraries. One area that was still problematic arose when a part of the data structure was loaded at runtime, from a plugin. When this external module registers a new entity with the object factory, it lead to errors when closing down the 3 To

give instructions to the compiler, before generating the actual compiled object code.

15.4 Conclusion

341

application. An instanced object, from the factory-owned template copy, could not be cleanly removed, since the application process was not the creator of this memory. It is assumed that this could be solved by delegating the removal process of objects from a plugin back to the plugin that created them. However, for practical reasons, it was decided to create all templates from a statically linked library instead.

15.4

Conclusion

While the main test interface and structure has been set up and a few basic tests were implemented, the actual elaboration of extended tests is not a part of this doctoral research. It is assumed that in collaboration with other researchers, it would be feasible to embed some of their algorithms and methods as evaluation tests in the prototype. This would also give valuable feedback to improve the interface of these test classes.

Chapter 16

Interaction in IDEA+ 16.1

Manipulators

Introduction A Manipulator1 is a graphical element with which the user can interact. It is a user interface element that is at the same time easy to understand, yet also accurate and protecting against erroneous input. The user drags or clicks on a manipulator and connected properties can be changed. This change can be continuous, in a dragging movement or discrete, stepping through values or toggling a switch. Since the range of values a manipulator can reach is by definition finite, the user can be protected against entering errors, since only sensible data can be set with a manipulator.

Enabling manipulators in the prototype To enable manipulators, local reference points are chosen. These are similar to regular Reference Points, but instead of sharing them between CAAD Entities, they are kept locally. Each of these points is only displayed for the active entity. Dragging them around will update the underlying element. Each manipulator is linked to a property, such as the height of a column or the offset of a wall according to its reference line. To restrict the effect of manipulators, they have a constraint type. This defines the possible movement of the point. Several constraint types are defined. FREE the point can be moved freely in three dimensions. PLANAR movements are limited to a plane, giving two degrees of freedom. LINEAR movement is restricted to a line, giving one degree of freedom. TOGGLE no movement is possible, but the manipulator can function as a toggle, switching a certain parameter ON or OFF. 1 Or

gizmo as it is known in Autodesk 3ds max.

343

344

Chapter 16. Interaction in IDEA+

The position of the manipulator will be expressed relative to one or more of the regular Reference Points. It is possible to extend this with other editing tasks, should the need arise. It is currently not intended to use the splitting and joining of these points with other points, as is the case with regular Reference Points. It is assumed that property links would suffice to provide inter-object relationships. The manipulators in IDEA+ are mostly meant to explore the possibility of generic graphical manipulation of CAAD Entities. By correctly setting up a single class, the system should be able to properly react on manipulations.

Available manipulators The HOOPS Application Framework, that is applied in the prototype, provides operators. These are classes that provide a basic structure to manage interactivity. The required functionality based on mouse-interaction can be programmed as a single class. Activating an operator will switch the application into a particular state where all mouse interaction is interpreted as manipulations with a custom behavior. The prototype provides operators to create and manipulate entities. Navigate View While HOOPS provides basic view manipulation operators, such as zoom, orbit and pan, which should be familiar to all CAD users, they have been grouped inside a parent class for all custom operators. That way, all other operators inherit this behavior. These view navigation operations are all tied to the middle mouse button. This enhances usability, since it becomes possible to manipulate the view during other design operations. Create Item The creation operator will allow the user to insert Reference Points. By double-clicking or by clicking on the initial point, the operation is finished. Right-clicking cancels the operation. This operation will then generate a new Element, using the inserted Reference Points. A later enhancement made sure that the object to be created is directly inserted, so each step in the creation process will use the actual generate graphical entities of the chosen Element. This frees the prototype from worrying about drawing temporary lines or placeholder objects, since the actual Element is being used. Insert Point This operator allows the user to insert a new Reference Point in between the existing points. It uses the selected Element and will use a simple algorithm to decide which is the most valid position inside the list of points to insert into. Remove Point This operator allows the user to interactively remove a Reference Point. When there are Elements selected, other Elements remain protected. This uses a simple distance query.

16.2 Commands & events

345

Drag Point This operator will interactively translate a Reference Point and will update the connected Element. The current implementation will temporary select the first Element to be found which reference the clicked point and will then interactively update the Element while dragging the point. Drag Object This is a transformation operator, which moves all Reference points from the selected Elements. Beware that these operations are mainly wrappers to call methods from the Project class to perform that actual operations on the project data. Some of these operations are mainly used for interactive editing of the entities. Once the interactive operation is finalized, the geometry is reset and the result is called as a Command, allowing the operation to be stored in the Command History. This is explained in Section 16.2. Accuracy and input filtering There is the issue of setting exact values, when dragging in a window. A manipulator movement should always be filtered and rounded off if desired, to enable precise input with an unprecise input device, such as the mouse. It is therefore logical that the result from a mouse movement will be rounded off. This could be preferably controlled by the user, but for the prototype, a fixed accuracy is chosen, such as 0.1 meter.

16.2

Commands & events

Introduction A data structure is useless if not used inside an application. The prototype application that is being developed is both a testing environment for the data structure and an illustration of the concepts in a concrete user application. This is not meant as a fully capable CAD or modeling application, but rather as a workable testing tool. It is possible to extend it to a full commercial program, but that is beyond the capabilities of a small research group. An important aspect to make such an application usable is the way operations are executed. Instead of a long list of functions which are connected to some toolbar buttons or menus, the application needed to support a full Command structure. This was necessary to have a structured way to define operations, such as the creation and selection of entities, but also to enable a command history, allowing any command that had been executed to be undone. An undo and redo functionality is highly necessary to enable design exploration. [GHJV95] describes a command pattern, which inspired the Command class in IDEA+. This is a system where each possible event follows the same structure, defining both an execute and an unexecute method. Each command should be

346

Chapter 16. Interaction in IDEA+

able to restore the previous setting of the project data. All executed commands store all necessary data to be able to restore the situation before execution. Regardless of the way these commands are called, from menus, toolbars, macro’s or other commands, they always perform the same action. A series of commands can be grouped as a MacroCommand, which can be executed as if it was just one simple command. That enables a series of commands to be stored in the history list and to be undone as easily as a singular command. The CORE Object Model [Hen00, Section 2.3] describes some of the necessary commands and organizes them in an Object Event Table. The implementation however, was not discussed there. General Concerns The functionality of the data structure alone will not suffice to really interact with the data. This requires an application or an additional functionality layer. It was chosen to elaborate the functionality layer as a prototype application. Additional methods are required to manage and edit project data. To limit the dependence of operating systems and application frameworks, a large part of the core functionality is provided through the Events or Commands. They are implemented as a part of the data structure, for convenience and to prevent external dependencies on frameworks, although they are part of the functionality layer of the application, rather than of the data structure. The prototype application is used to create the user interface, comprised of toolbars, menu’s and views, which call upon the provided Events from the platform independent data structure. In [Hen00, Section 2.3], an initial list of possible commands was described in an Object Event Table. The implementation of such a table is done through a series of Commands. The execution of the prototype application is then largely defined by a sequence of commands. Regardless of the method with which the command is called—a menu entry, a press on a toolbar button or a sequence of scripted events—the Command History is kept as a sequence of executed commands. There is no internal limit to the size of this history list, as long as the system has enough memory to store all the additional data to enable the undo and redo operations. The redo list is as long as necessary to retrace the whole stack of operations. Not every operation inside the prototype application is performed as a command, however. Viewpoint operations and display adjustments are simply set, without the administrative overhead of relying on actual commands. Only the operations that act on the Project data are stored. Every possible command has to be able to restore the project data to the point in time right before the execution of the command. The removal of an entity, as an example, does not destroy the entity in memory, but rather places the entity outside of the active list of elements. This facilitates the undo event, since the element simply has to be moved back into the correct list, instead of having to create it all over again. This might seem a waste

16.2 Commands & events

347

of resources, but it actually enables the storage of element modifications by only storing a reference to the adjusted element and the previous value of the modified property. Otherwise, every modification operation had to store the complete element as well. The implementation relies on a system of Reference Counting, where all instanced objects keep a use count. Each time an object is being referenced, the counter is increased. The removal of a reference will first decrease the counter and only when the counter reaches zero is the element really destroyed. The implementation uses a custom system of Reference Handlers, but their behavior is similar to more elaborate Garbage Collection methods of programming languages such as Java or C] (C sharp). The advantage of using Reference Counters lies in avoiding the complex task of manually assigning and releasing memory. This is a common programming effort in the C++ programming language, which is used in IDEA+. Most objects in IDEA+ can be reference counted. Each created entity keeps an internal counter, indicating how many references exist to this instance. The Reference Handler is a wrapper around an object that can be referenced. Whenever this Reference Handler is copied around, it ensures that the reference counter is increased. When the Reference Handler is destroyed or removed, it decreases the reference counter and only removes the referenced entity when this counter reaches zero. This technique greatly simplifies memory management and makes it easier to place entities in lists, copy lists of elements and store elements in temporary buffers in commands. In fact, the Command System, which implements an undo history, relies heavily on reference counting. The removal of an entity from the project still keeps a copy of this entity in the command, which stores the reference handler. When the command is undone, it is trivial to restore the entity from this handler. Any subsequent modifications on entities are also guaranteed to occur on the same entity, since its reference is kept alongside the modification command. Reference Counting is the reason why the removal of elements from one list does not result in the complete removal of the data and thus why the history system is still able to manage these entities, even though they never store a complete copy of the data. The creation, modification and removal of one particular entity only stores the entity once, where the only necessary data overhead lies in the additional values that are set through object modifications. In IDEA+, the Project class does not only store a list of Elements, but also a list of Removed elements, a list of Selected Elements and a list of Copied Elements. Since all of these lists only store the Reference Handlers to these Elements, each single Element is only stored once in memory. Once the Project data are stored inside a file, all these additional data are cleaned up and the Command History is erased. It might be interesting to keep a full history of commands, over the border of editing sessions, but this is not implemented. There is only a small additional memory requirement for working with reference counting, since all copies reference exactly the same instance in memory and only the counter is kept. This counter is not stored in the files, as it is recreated upon object instantiation.

348

Chapter 16. Interaction in IDEA+

16.2.1

Command implementation

Commands, which are implemented according to the Command Pattern [GHJV95], which is shown in Figure 16.1, are also the approach to support a Command History, allowing the user to undo or redo the performed commands. This is necessary to give the designer a safety net, stimulating design experimentation with the assurance that the project can be restored to its previous situation.

Client

Command Execute()

Invoker

Receiver Action()

receiver

Concrete Command Execute() State

receiver -> Action()

Figure 16.1: The Command Pattern An alternative approach to implement an undo/redo queue relies on the storage of each step of the design process as a separate file, but this approach is only usable in applications which store only small amounts of data and which can be exported and imported very efficiently. This approach is not followed in IDEA+ and the current implementation uses the Command Pattern. All executed commands are automatically added to the Command History, which is kept inside the Project. It is not stored with the Project data. This list is strictly sequential and whenever an undo operation is followed by a new command, all existing commands which are kept after the current command have to be deleted. It makes no sense to keep commands for operations on the Project data, which might not be valid anymore2 . The commands in the IDEA+ prototype actually provide three methods: execute, undo and redo. The execute function performs the hard work, possible by calling other classes to do the work, such as the Project class. At the same time, additional data is stored to be able to restore the modified elements. This is usually done by keeping references to the affected elements or a mapping to relate objects or properties with the previous situation. The undo function resets the objects, using the stored values collected during the traversal of the execute function. The redo function uses the restored values again to set the data into the situation after the first call of the execute method. If the redo function would simply call the execute method a second time, chances are that the result is not identical to the original call of the execute method. This happened a few times in the implementation stage, when the execute method has to create objects. At first sight, this does not pose problems, but when this 2 It would be interesting as an application concept to support the reordering and selective removal of commands in the Command History, but the implementation and especially the results might be unpredictable. An application such as Adobe Photoshop partly supports this behavior, but it acts on a completely different type of data.

16.2 Commands & events

349

command was followed by other commands working on the generated object, it becomes important. The user can undo several execution steps, up to a point where the object was not created. When the user consequently steps through the redo list, it is imperative that the call of the redo method from the creation command uses the same object as originally. It this is not the case, the consequential modification command is being performed on a different object then the first time, leading to corrupt project data3 . Macro Command Commands can be regarded as atomic events. A series of commands which should be executed as if they were only one command is implemented in a Macro Command. This is also proposed with the Command Pattern and it follows the same interface as a regular command, so to the system there is no inherent difference between single commands and a series of grouped commands. An example of a simple Macro Command is the delete all event. Instead of defining a new command, it calls two existing commands select all and remove selection. To the user this acts as if it were one single event. The implementation of Commands is very important to ensure a consistent handling of the project data. While most Commands rely on functionality provided by the Project class, these internal methods should not be used directly by other routines. When consistently executing all operations using the Command classes, the system can keep track of the requested operations and can undo them or redo them at any time. This is important if this functionality layer would be used from external applications or routines in future development. This is also useful in the case of porting the software to a different GUI framework, since the whole functionality layer will stay a part of the data structure and does not have to be adapted.

16.2.2

Overview of Commands

CREATE <type> <subtype> <list of points> The Create command makes new elements, based on a given entity type and a list of Reference Points. The actual creation of new elements relies on the Abstract Factory Pattern, displayed in Figure 16.2. In a Factory, all the creation events are simplified. All possible entity types are registered inside the Factory. For each object type, a copy is stored, from which new instances can be created. The Factory in IDEA+ stores a std::map, where identification strings are linked to object templates. When the system wants to create a new element, such as a wall, the Factory is called, with the type string and a new copy of the template object is returned. This is added to the Project Data. The Create command primarily is used for the creation of Elements, which include CAAD Entities, such as walls, floors and spaces. The command receives a 3 Making

changes in the past may not influence the future. . .

350

Chapter 16. Interaction in IDEA+

<<interface>> AbstractFactory CreateProductA() CreateProductB()

import

Client

<<interface>> AbstractProductA ConcreteFactory1 CreateProductA() CreateProductB()

import

ConcreteFactory2 CreateProductA() CreateProductB() ProductA1

instantiate

ProductA2 import

instantiate <<interface>> AbstractProductB

ProductB1

instantiate

ProductB2

instantiate

Figure 16.2: The Abstract Factory Pattern type and subtype string. The type defines the CAAD Entity which is embedded in the Element, while the subtype is depending on the kind of CAAD Entity. For Physical Elements, the type defines the Physical Element Type, while for Common Spaces, the type is the SpaceType, which distinguishes between User Spaces and Holes. Other CAAD Entities, such as Grids do not require a subtype. The command also receives a list of Reference Points, which define the geometrical outline of the created entity. These are the endpoints of a wall or the corner points for a floor. Since the Reference Points are stored as references, they can be shared between entities, allowing different CAAD Entities to be anchored together. How the Create command works After some elementary control operations on the data input, the Create command generates an Element. This is only a container object, which stores a list of CAAD Entities. A CAAD Entity is then instanced as a copy from a template, which is stored inside the Factory, based on the given type and subtype string. This CAAD Entity might receive a subtype, if appropriate, such as with Physical Elements or Common Spaces. The CAAD Entity is added to the Element and the Element is added to the list of Elements inside the Project. The Element is also selected and the previous selected Elements are deselected. The graphical Representations for the CAAD Entities and their subtypes are also generated, so the display can be recalculated. The reverse operation or the undo method has to restore the Project data to its state right before the creation of the Element. This is, however, not the removal of the generated Element. The Element is rather transferred to a hidden list, from which it might be restored if needed. The redo operation consequently

16.2 Commands & events

351

reuses the Element and its CAAD Entities, by moving the Element back again from the hidden list to the regular list of Elements. The main reason why this approach was chosen is the realization that it is much easier to just keep the object alive, with all its settings and parameters, rather than storing all these parameters and having to apply them again when the need arises to restore the Element. The Command only has to keep a reference to the created object, in the form of an RCHandler or a Reference Counted Handler . The moment the Command is destroyed, the reference count is lowered and the Element might be really removed when this count reaches zero. The destruction of the Command happens when the user calls the undo operation and consequently performs another operation, which cleans the redo list. The Commands are also destroyed when a Project is closed or the application is shut down. CREATE LIBRARY ELEMENT <type> The creation of Library Elements, such as Materials or Compositions, does not need a list of points. Only the main type is required. This Create command generates a new Library Element, which is also instanced from a template inside the Factory and adds it to the appropriate list inside the Project. A Project keeps lists for each kind of Library Element. The properties of the Library Element are not set with the Create command, but rather through a sequence of Modify commands, which are discussed further in this section. CREATE LINK <link type> <first entity> <second entity> A link always requires two entities which are linked. Depending on the passed entities, the link might be set differently. There are several link types in IDEA+ and the implementation actually provides separate Commands for these types, since their behavior widely differs. Dependence Link This defines a Parent-Child relationship between entities. This can only happen between CAAD Entities. Each Parent can have as many children as needed, but a child can only have one Parent. Object Link These are the links as described in [Hen00, Section 2.2.2]. There are Physical Contact Links, Physical Boundary Links and Imaginary Boundary Links available. The distinction between them is made automatically, since they are defined by the entity type. Parameter Connection This is a connection between a property of any entity with a property of any other entity. This is used to store specific relations between unconnected entities. This needs an additional string with the names of both properties and an optional formula to describe the expression used to calculate the value. The functionality of these links is explained in Section 12.6.3 on page 308.

352

Chapter 16. Interaction in IDEA+

REMOVE <list of elements> The removal of any Element. This works partly as the Create command, in the sense that the removed Element is not destroyed, but rather moved to the hidden list. Together with an Element, its CAAD Entities and all the possible links are removed as well. This complicates the undo method. The removal of the Element itself is identical to the undo method of the create command, but the removal of the links is not. The links not only have to be broken, but they also have to be stored in a way that allows their recreation should the user decide to undo the removal operation, which is almost certain to happen in a design session. Even though the different link types are implemented differently, they are managed in the same way. The execute method stores the full list of links involved with the remove operation, breaks the links, so they are removed from the involved entities and then removes the entities. The undo method needs a two step process, first restoring the elements and then recreating all stored links with other entities again. The fact that all information needed to restore the link is kept inside the link itself makes this possible.

MODIFY <object> <parameter> <new value> This is the general command to make changes to any object. All user interface modifications, such as editing the value in the Property Editor or graphically changing an Element, happen through this command. This way, all modifications are kept and can be undone. The implementation of this command is not too complex, but it relies on the correct implementation of other commands. When a Modify command is called, it keeps a reference to the modified entity. If the user chooses to perform a series of undo operations, including the removal of this entity and then, as an evaluation of the current design steps, steps through the redo queue, until the point where the modify operation is called again, it is paramount that the same entity is restored. It is not enough to simply create a replacement element, since this would have a different reference and thus all commands that reference the original element would fail. The actual implementation of the Modify command is done through the Property System. A set operation uses a string to indicate the property and another string for the value to set. The command needs to store the previous value, so the undo operation simply calls another set operation with this value. It is more complex with the assignment of references, such as a Physical Element changing its reference to another Composition. This could be performed using a string, as long as this string has all information to retrieve the modified reference. This can be the ID of the entity, which is by definition unique, but the implementation also adds the name of the class, since that helps in casting and searching within the correct entity list.

16.3 Expressions & parameters

353

An interactive modification, such as dragging a point, has to take care not to store every intermediate step. This is done by performing the interactive dragging directly, without using a command at all. At the moment the interactive operation is finalized, the final value is noted, then set to the initial value and only in the end the modification command is executed, using the initial and the final value. The user will not expect the undo operation to step through all the intermediate values. TRANSFORM <type> <list of objects> <matrix> The transformation of entities, such as translating or rotating, is performed with transformation matrices. A four by four transformation matrix of homogenous coordinates [FvDF+ 93] defines the transformation between two coordinate systems. The Transform command is implemented as a special case of the Modify command. SELECT <what> FROM <list> [ WHERE { <clause> | ...} ] The command to select Elements and possibly other entities, defines a list of references to entities. This can be called directly by the user, with visual selections by picking Elements on the screen, or it can be called by other operations, prior to performing operations. The syntax of this command is inspired by the SELECT clause as used in the Structured Query Language 4 (SQL). The command needs to store the list of entities selected prior to the operation, to be able to undo the selection. It is normally used to select Elements, but can be extended with other selections, which would become useful in scripts or other commands. SELECT <what> This narrows the scope of entities to select, such as Element or Material. FROM <list> Usually from the Project, but it could be extended to support a file, the current selection or a specific zone or floor level inside the Project. WHERE <clause> To select only entities which obey to certain restrictions, such as the value of one particular property.

16.3

Expressions & parameters

16.3.1

Requirements

Expressions will consist of a combination of arguments and operators. 4

http://en.wikipedia.org/wiki/SQL

354

Chapter 16. Interaction in IDEA+

• Most arguments are simple data values, such as a string, a real number or an integer. • The operators perform a calculation on their arguments and return a result. Through inheritance, the operator is also accepted as an argument, so operators can be embedded inside other operators. Typical operators are mathematical expressions, such as a sum or a product, and goniometric operators such as sine and tangent. • References to other entities are also required. This is usually an expression in the form object.property.value. • Other common operators are control and conditional operations, such as an if...then...else structure or the equality and inequality operators. Global parameters are automatically supported through the Property System. It is possible to define Extended Parameters, which are additional runtimedefined properties. When the user adds new parameters to the Project and an entity uses one of these parameters in an expression, the user has means to globally control one or more entities. Designers can set up a custom interface for a particular design, where some preferred properties are presented as global control parameters, controlling any combination of other elements. If a certain length or height is used throughout the Project, it might make sense to define it as an Extended Project Parameter and link it to all dependent entities. Adjustments can then be easily performed from one place. A simple example of such a connection could be the definition of a reference height level. This can be defined as an Extended Parameter within the Project. A wall might then be related to this Parameter, either as a simple equality or as an Expression, e.g. defining an offset to this level.

16.3.2

Using Property Connections to enable expressions

To enable Expression in the data structure, there is the option of using a formula parser. A brief online survey has indicated that there are multiple options available. However, most of these systems are not well suited to support the parsing of formulas with included object parameters. They have to be defined as constants. While this is not a problem when creating the parser, it is more difficult to retrieve the actual property form the constant. A better and simpler alternative is to create the functions and operators as regular objects using the Property System. They can then be used in Property Connections. This is best illustrated with an example. Suppose the designer want to relate the height of one wall to the height of another wall, e.g. by indicating that the first wall is always one meter taller than the other. In a formula, this would be written as height1 = height2 + 1. While this seems simple, it actually requires a complete function parser.

16.3 Expressions & parameters

355

If the Addition Operator, however, was created as a regular object, derived from the common base class from the Property System, it could have three variables, e.g. value1, value2 and sum. The current Property System already defines a method UpdateAfterSet, which is called when a variable was modified. This is an optional method to be implemented by derived classes and is mainly used to synchronize the internal state of an object, when parameters are modified. For this Addition Operator it could recalculate the sum parameter, when one of the value parameters is changed. The following step requires two Property Connections. The value1 parameter is linked to receive the height value of the second wall. The height value of the first wall will then be linked to the sum parameter of the Addition Operator. This is made more clear in Figure 16.3. Wall 1 Height Composition Wall 2 Height Composition

Operator ADD value1 value2 result Calculate()

Figure 16.3: Creating an Expression with Property Connections Whenever the height of the second wall is modified, the Addition Operator is changed and in turn, the first wall is adapted. The current implementation of Property Connections is more than capable enough to support these constructs. A small set of basic operators will be sufficient for many common expressions, without the requirement for a full formula parser.

16.3.3

An interface for Expressions

Many design decisions can be formulated as Expressions, usually in some mathematical form. It seems inappropriate, however, to force the end user into coding, at least as the main access to these Expressions. A common remark in discussion forums on design software is that architects or artists are not coders. Even if the CAD or other design application supports scripting or programming, the majority of users refrains from using this functionality. If expressions would form an integral part of a design application, they have to be managed relatively simple and preferably visual. This can take the form of an Expression Builder, as shown in the mockup of Figure 16.4. Some of the Expressions can be created by the system, such as the heights of walls with regard to a floor level reference. Others could be pieced together as a series of building blocks.

356

Chapter 16. Interaction in IDEA+

Figure 16.4: Expression Builder mockup This is an approach which can be described as Visual Programming. Prefabricated pieces of arguments and operators can be linked together into a formula. This is a graphical and visual interface to programming tasks, which is found in quite some applications. They vary from web design software, such as Demicron Wirefusion to music software, such as Plogue Bidule and visualization software, such as Autodesk Maya or SideFX Houdini . More on these systems can be read in Section 1.13 on page 63. Some Expressions might be only temporary in nature, such as a fast intermediate calculation, which is often nothing more than a scribble on a piece of paper or a multiplication on a calculator. They are not kept as design intent. This can be found in several applications, where parameter entry optionally supports simple expressions. Examples include Maxon Cinema4D and Google SketchUp, where you can type a calculation in a value entry field. This calculation is parsed and the result stored as the final value. The actual expression is not maintained, so the underlying design information is lost. A real design decision, however, would benefit from full formulation, so it can be recalculated and maintained throughout the design process. An optimization would be the fixation or caching of an Expression. Most Expressions are not recalculated very often, since they depend on values which have been chosen and set. As a result, they are not changing continuously.

Chapter 17

The Geometric Model Introduction Even though a building is described as a full, three dimensional layout of design entities, the prototype only provides a limited graphical model. The focus in this research are the early design phases, in which a 2.5D description of the building is often good enough. Many designs can be almost fully described with a simplified model, containing mostly 2D and 2.5D information. 2.5D can best be described as 2D with added height or elevation. The result is real 3D geometry but a 2.5D modeler is not able to define elements that are not fully vertical. This has been a popular approach to add 3D to existing 2D applications, since it is adequate for most of the geometry in common building projects. However, there are obviously designs which require a full 3D geometrical description, using freeform surfaces, such as NURBS. The following sections will describe the limitations that have been applied in the prototype, regarding the geometrical model. Most building elements are created on a horizontal working plane and they receive their actual height through attributes. Walls have a height, beams and floors have an elevation and spaces are extruded vertically. It is understood that such choices limit the generality of this approach, but at the same time, these choices make the elaboration less complex.

17.1

A limited graphical model

Since the graphical representation of the building elements is only generated from the actual building data, it is possible to start with a simple representation and focus on the element properties. It is always possible to improve the representation in future prototypes. The data structure is mostly independent of the graphical engine, although the building entities have to generate some form of graphical entities. This implies that they have to know some â&#x20AC;&#x153;graphical languageâ&#x20AC;? to describe how their representation should be made. For this purpose, a set of simple graphical entities is developed. They are merely used to carry over graphical data, not the generated graphical entities. The connection with a graphical engine is then bolted on these graphical entities. This frees the display system from having to understand the intricacies of the CAAD Entities and rather focus on a global knowledge over a Project, Elements and CAAD 357

358

Chapter 17. The Geometric Model

Entities and then define translations from the graphical entities to the code needed to display anything in the scene. This can be a scenegraph framework, a CAD program or a simple graphical window. The simple graphical entities can be extended at any time, so the CAAD Entities can have more complex graphical commands. Constructions such as solids or sweeps might be coded to only carry the required data, without the actual drawing and entity generation code. This can then in turn be handled by the graphical engine, so the development of IDEA+ does not involve a geometric modeler. There is a deliberate choice to define most design entities with as few parameters as necessary. This also applies to the graphical entities. It was never meant to provide all possible geometrical objects. Most CAAD Entities are described with a combination of lines and text for their 2D representation and planar polygons for their 3D representation. A basic vertical extrusion is created from a single polygon. Polygons also support holes.

17.2

Limitations

Even though ideally, there would be no geometrical limitations in an architectural design application, practical considerations have introduced geometric limitations during the implementation of IDEA+. • Walls are vertical and normally have a constant thickness. Through the use of an additional property for the start and end height and with an additional end width property, some additional modeling freedom is allowed. • To have a correct spatial model, walls will not be modeled continuously, but split between spaces and floor levels. Through the connections of their Reference Points, they are still related. • Floors are always horizontal and have a constant thickness. • Floor Levels have a constant height. By default, the height of a wall or a column is expressed relative to the floor level, allowing them to follow floor level changes. • Roofs are almost identical to floors, but they support a slope angle. When walls are connected to the roof, the top profile of the walls should be adjusted automatically. This is possible by defining the top of the wall to be relative to the roof object or to some shared Reference Plane. The roof can then be projected onto the same Reference Plane. • Openings in Planar Elements have a simple rectangular shape and have to lie completely inside the plane. The positioning of these elements uses the UV coordinate space, rather then the normal cartesian XYZ-coordinate space, which is a preparation for more advanced freeform surfaces support, when they are added in future prototypes.

17.3 Defining geometric information as Objects

359

Motivating the limited graphical model The scope of the research is not geometrical modeling, but rather information modeling, which can be devised partly independently of the underlying geometrical engine. The problems are firstly described on a simple, conceptual level and could be extended at a later moment, if research time and budget permits. These limitations still allow a geometry that is sufficient for a large part of the common building layouts. Since IDEA+ is envisaged as a design tool, it is assumed that later extensions could enhance the geometrical scope, but it is not a research goal at the time of writing.

Expected problem areas As mentioned above, the support for buildings with a non-trivial floor level layout is expected to pose limitations. Defining a spatial model without the limitations applied from a constant floor level system also seems to be an area where problems can be expected. At all times, a design system should not release the architect from the task of maintaining the validity the building model. A design environment will at best be supportive, but design decisions stay a responsibility of the architect.

17.3

Defining geometric information as Objects

The development of the prototype raised questions on the validity of different approaches in CAD and BIM applications. When implementing architectural design solutions on top of a generic geometric modeling toolset, building information is usually added as attributes to regular, graphical entities. But at the core, the CAD roots still make it a modeler for geometry, rather than for building data. In a BIM approach, the building entities are actual objects, which will be represented with geometrical entities. The building information is not an attribute anymore, but is the actual underlying data. The geometry becomes dependent. Most applications that adhere to the BIM paradigm actually create a hybrid between the two methods. They provide Object Oriented architectural objects, such as walls, stairs and spaces and combine them with regular geometrical objects, such as line work and annotation. There are actually still advantages of the former approach, mainly in the form of geometric freedom. Anything could be interpreted as a being a specific building entity. In a geometric modeler, a wall could be modeled as a box, but also as a freeform NURBS surface. Most BIM software will not allow a wall to have a completely different form. A slab in a program such as ArchiCAD is always flat and with a continuous thickness. While this suffices for most designs, there are occasions that something else might be more appropriate. While other geometry, such as the mesh or custom scripted objects, might be used in ArchiCAD, it will not be included in listings of floor slabs.

360

Chapter 17. The Geometric Model

A possible solution to enable such design freedom in a BIM methodology is illustrated in Figure 17.1. Instead of generating preset geometry from the building element, geometry will be modeled as generic containers of information. The CAAD Entity can then reference the Geometric Object. Such geometric object will function as some kind of template. Instead of including the geometry generation in the type classes, which is how the current prototype is implemented, these types could reference arbitrary geometry.

CAAD Entity

IType Physical Element

PEType

Space

SpaceType

IGeometry list<RefPoint> refPoints list<RefPoint> localPts ... GetRefPoints():list GetLocalPoints():list GetPerimeter():double GetArea():double GetVolume():double ...

Masterplan Element Grid

...

Linear Volume

Planar Volume

Primitive Volume

Figure 17.1: Objectifying topology So what is the difference with geometry based architectural CAD software? The main data model is still based on architectural design entities. The building can be still interpreted as specific entities, carrying design information. Instead of relying on preset scripts, they will utilize geometric entities, not only for their representation but also to derive information from. The volume of such a freeform wall or space could be easily retrieved from the geometric object.

Chapter 18

Object Oriented Programming in IDEA+ 18.1

Generic approach

Research on the use of CAD in the design process is often accompanied with an implementation step. The development of a data structure and a design prototype is important to evaluate the concepts and is an important way to illustrate these concepts in a interactive setting. Some implementation goals are crucial in the realization of the prototype. Since the data structure develops at the same time as the prototype application, it was primordial to follow a flexible approach. The management of design entities in the application can not be postponed until the data structure is finalized, so a generic approach was very important. The extensibility of the data structure is a similar goal. The initial prototype only supported a small subset of the design entities, which had to be extended, without the need to fully adapt the application. The most important realization to allow this support is the Property System. This is a generic approach to manage objects and has been the basic engine to support both the editing of properties and the serialization of the project data into an XML file. Consequent use of Object Oriented Programming (OOP) aspects was the main method in the implementation. There is a required focus on programming for abstract classes, hiding the implementation details. There is also the requirement for strict independencies between different modules. The division of the data structure in modules forced a clear boundary between classes which are not allowed to know about other classes, to enhance flexibility and independency.

18.2

Programming style & techniques

This research is not about programming languages or programming techniques, but we still had to make sure that we used good coding practices and followed industry-proven coding principles. 361

362

Chapter 18. Object Oriented Programming in IDEA+

The development needed to address both the data structure to describe a digital building model and a testing environment, which is the IDEA+ prototype application.

18.2.1

Making IDEA+ in C++

The first choice was the programming language itself. It was decided early-on that the data structure would be implemented in C++. The availability of this language on all relevant computer platforms, its performance when compared to interpreted or scripted languages and the availability of usable libraries or frameworks were key motivations to implement IDEA+ using C++. Although it might be argued that languages such as Java or, more recently, C] (C Sharp) have easier memory management, more default libraries and suffer less from performance problems as they used to, C and C++ are by far the most commonly used languages, which is reflected in the wide choice of specialized libraries and frameworks, from both academic and commercial research groups. After the choice for C++ was made, a correct implementation strategy still had to be chosen. The initial CORE Object Model [Hen00, Chapter 3] used the MERODE-methodology [DS94, SDVD99] which automatically suggested an implementation in an Object Oriented Programming Language. Even then, there are many possible approaches with this project.

18.2.2

Good Coding Practice

IDEA+ makes use of standard ISO/ANSI C++ as described in [Str91] [Lip93] and [Kaf98]. It also borrows advice from [Mey97]. A second important code reference base is the Standard Template Library (STL) [MS96], which was of utmost importance to avoid implementing common management classes from scratch, especially when defining lists, strings and other container classes. This requires good template-support by the C++ compiler. This support is available with most modern compilers. Two compilers have been applied for the development of IDEA+. The gcc compiler is mostly used in Linux, Unix and Mac OSX, although it is available for many other platforms. The MS Visual C++ compiler is used for Windows development. Because the scope of IDEA+ is fairly large and the implementation would have to grow together with the research, it makes sense to follow the principles of Object Oriented Programming from the beginning. This required some planning ahead and invited us to adopt the concept of Design Patterns [GHJV95], which was an important reference in the implementation of IDEA+. A Design Pattern is an abstracted solution for a generic problem. The very nature of Design Patterns makes them good starting points to manage common design problems. They are used most noticeable in the world of computer programming, but the idea of patterns originates from the works of Christopher Alexanderâ&#x20AC;&#x2122;s Pattern Language [AIS+ 77].

18.3 Abstraction, Interface & Independency

18.2.3

363

Realtime graphics

To model and display the graphical representations of the IDEA+ data structure, a graphical engine had to be chosen. Today, there are two main leading technologies to display 3D graphics on a computer: OpenGL1 and Microsoft Direct3D/DirectX 2 . These are both graphical libraries, for the display of 2D and 3D geometry, with possible hardware support by the display adapter. Most CAD applications support OpenGL, while its competitor Direct3D, which is a subset of DirectX, is used in most computer games and many multimedia applications, but DirectX is a technology that only runs on MS Windows. It was a simple choice to apply OpenGL for the first prototype of IDEA+. This prototype was implemented directly on top of OpenGL, based on the approaches described in [Woo96] [Fos96] However, the current evolution of graphics applications is less clear. Direct3D is still a Microsoft-only technology and is only supported on the Windows operating system, while OpenGL is supported on almost any operating system. But the release of Windows Vista emphasized the pressure by Microsoft to support Direct3D. The Aero-glass interface in Vista is displayed using Direct3D and thus requires hardware acceleration by the graphics adapter to be fully supported. Additionally, running OpenGL applications inside Vista forces these applications to use OpenGL as a layer on top of Direct3D. Needless to say that this impacts performance over direct hardware support. Only when the optimized display drivers by the hardware company, such as nVidia or ATI/AMD, are used, is OpenGL fully accelerated. Although some application support both systems, it might come as no surprise that many current Windows-only applications preferably use Direct3D for display acceleration, such as Bentley MicroStation and Autodesk 3ds max/VIZ. When an application needs to be supported on multiple platforms, there is no doubt that Direct3D is not a solution. However, applications are often written utilizing a graphics library or a scenegraph library which sits in a layer between the application and the operating system. This can free the developer from having to code specifically for OpenGL or Direct3D. This is the case for the HOOPS application framework, as used in the current IDEA+ prototype. Comments on the use of HOOPS inside Vista can be read on the WorldCAD Access blog[Gra06b, See website3 ].

18.3

Abstraction, Interface & Independency

In Object Oriented Programming, classes define the common characteristics for objects, which can be considered as the instantiation of classes. Abstraction means developing a set of generic or abstract classes, which define the main functionality required in the data structure. More specialized ob1 2 3

http://www.opengl.org http://www.microsoft.com/windows/directx http://worldcadaccess.typepad.com/blog/2007/02/techsoft 3d com.html

364

Chapter 18. Object Oriented Programming in IDEA+

jects will be derived, through inheritance, from these main abstract classes to implement specific behavior. Although it looks easy to describe a hierarchical set of objects that become more and more specialized, we want to avoid dealing with a very large set of inherited and mutually dependent classes. This leads to very complex and hardly manageable sets of classes. We strive to have as few classes as possible and sharing as much functionality as possible. This is, off course, a very common goal in Object Oriented Programming. Our experience with the initial versions of the data structure made us diminish the amount of classes and functions and look for more common functionality between many of these elements. The interface of these objects is the whole of public member variables and member functions, as opposed to the protected and private data that stay hidden. The implementation of an object uses these hidden parts, but they are not exposed to other objects, so this is not part of their interface. The user only works with the public interface for the different classes. Independency means that the knowledge from some specific class about another class is very limited. Both can be further elaborated independently, as long as the interface of these classes is respected. This allows modifications of classes to be made with little or no impact on the rest of the data structure.

18.4

Modularity and Plugins

Whenever a clear interface is defined, all classes following this interface are interchangeable. This allows the program to replace certain classes with others, even at runtime, since they behave exactly the same. This approach allows the application to be modularized. One of the results of a modular approach is the possibility to load modules at runtime which can extend or replace certain application functionality. These runtime modules are commonly known as plugins or add-ons. This would allow the prototype to be split up in a Core application and additional plugins. This modularity is one of the goals in the implementation of the IDEA+ prototype. The use of plugins would then be a possibility, although this is more relevant when other developers would like to extend the application. To actually develop plugins is not necessary for this research, but the focus on modularity improves the independencies between mostly unrelated aspects of the data structure. Some commercial applications, which are usually closed-source, allow developers to extend the functionality of the application using plugins. A good example is Autodesk 3ds max , which is delivered as an open system, where many features are already created as plugins. The modules to load or export other file formats, the different material types, different objects and different modifiers are all loaded as plugins. This is a common approach in these applications, since no application has all the features required by professional users. These users might be able to build the required additions into the application themselves. Plugins in 3ds max make the program very popular. They can be written

18.4 Modularity and Plugins

365

either as compiled C++ modules or as interpreted plugin-scripts. Many other applications have similar customization possibilities. The modularity in IDEA+ is also found at the level of the data structure itself. The graphical classes extend the base classes, the CAAD classes extend and use base and graphical classes and the other modulesâ&#x20AC;&#x201D;events, extras and testsâ&#x20AC;&#x201D; extend the first three. None of the first three modules is allowed to know anything about the latter three, which sometimes poses additional problems. This is apparent in the Project class. This class is defined in the CAAD group, where it defines methods to communicate with the application. But the CAAD module is not aware of the actual implementation of the application. This is solved by creating the Project as an abstract class, with which all other modules can interact and which is then extended, through inheritance, in the prototype application. The prototype defines a Project subclass, which only implements the missing abstract communication methods, to create a message box or to write a message on the status bar. Which other modules can be noticed in IDEA+? Representations Different representation types could extend the abstract Base Representation, catering for different computer platforms, application frameworks or display systems. In the current IDEA+ application, this is used in the Render class, which defines the methods necessary to display elements on the screen. This abstract render class is used as the parent class for the specific display system renderer, such as an OpenGL renderer. Operators and Transitions The different operations that can be performed on the building data can also be modularized, allowing the functionality to be extended without changes to the application. These can be object creation operators and object modification operators. Transitions, which are essentially a combination of object creators and object modifiers, can then be added at runtime to the application. Input/Output-plugins The import of external files, such as common graphical and 3D formats, are plugins in most software applications, since it is often necessary to add support to new formats in applications. Some of these formats are already supported through the use of the application framework, but others could be added as modules. These can be exporters for 3D geometry or connections with evaluation and simulation software. Evaluation Tests These are by their very nature imagined as plugins, since the application does not have to be aware of all the possible tests in advance. Examples include the daylight evaluation and a cost estimation module. A rendering plugin is also a desirable evaluation plugin. A practical result of the focus on modularity is the potential to extend the IDEA+ prototype with additional functionality in smaller research projects, such as in the context of a masters thesis, where the application is provided as a platform for extensions.

Chapter 19

Implementing the prototype Introduction While the novelty of this doctoral research lies mostly in the way the data structure describes a building projectâ&#x20AC;&#x201D;in terms of architectural designâ&#x20AC;&#x201D;it is useless without an application. The prototype application went to several incarnations before its current form crystallized.

19.1

Overview of different prototypes

Starting as an IRIX application Initially, IDEA+ started life as an IRIX application, developed by some of my colleagues. IRIX is a Unix variant from Silicon Graphics (SGI)1 , famous for their powerful graphical oriented hardware. This first demo used the SGI Inventor toolkit, which also exists as the Open Inventor 2 toolkit. This is a common framework to develop graphical applications, based around a scenegraph concept.

Porting to MS Windows and MFC For a second version, the application code was ported to the Windows platform, which was basically a fairly straightforward effort, for the data structure. However, much effort was spent to translate all overlapping functionality in as few classes as possible. Each class initially had classes for an objectpointer, a list of objectpointers and a pointer to a list of objectpointers. Using templates, they were reduced to three classes , being a single Reference Handler class and Containers for objects and references to objects. This reduced the initial codebase significantly. While templates reduce the amount of code to maintain, they generate even more code at compile time, but this greatly optimizes development time, at the cost of some additional complexity. The graphical application had to be rewritten from scratch. This involved decoupling of the graphical engine from the basic classes, to make a more modular and flexible structure. 1 2

http://www.sgi.com http://oss.sgi.com/projects/inventor

367

368

Chapter 19. Implementing the prototype

The first tests were using the OpenGL Utility Toolkit (GLUT)3 , which is a wrapper to add a platform-independent layer around OpenGL. This enabled us to test the graphical interaction and to create and display elements visually, as illustrated in Figure 19.1.

Figure 19.1: Screenshot of the GLUT version But what was really needed was an application with a full Graphical User Interface (GUI). Initially this was a Microsoft Foundation Classes (MFC) application, which is an Object Oriented toolkit for Windows programming, which in itself is a wrapper around the regular Windows API. This API is known as the Win32 Platform Software Developers Kit (Win32 SDK). The MFC-version of IDEA+ combined a graphical 2D view, using the regular Graphics Device Interface (GDI) methods for drawing, with a realtime 3D window, using OpenGL. This is shown in Figure 19.2.

Figure 19.2: Screenshot of the MFC version for Windows 3

http://www.opengl.org/resources/libraries/

19.1 Overview of different prototypes

369

This enabled some additional features, such as a full menu and toolbar system, display of multiple windows and dialogs and additional support for file-reading and writing, amongst others.

Adding the HOOPS 3D Application Framework Even though this application performed reasonably well in terms of display rate, it proved complicated to develop a full application with the raw functionality of OpenGL alone. Since this research group has no intentions to develop a full 3D engine, for which other developers have already done tremendous efforts, we chose to utilize the HOOPS 3D Application Framework 4 . HOOPS is a toolkit used by several commercial CAD applications world wide. Although it is at its core a strict procedural C library, the concepts are similar as those of Object Oriented design. Moreover, additional modules, such as the Hoops Model-ViewOperator (MVO) module provide a real Object Oriented structure in C++, which defines a large set of application functionality. The HOOPS framework is targeted at CAD-like applications, so it was deemed a good candidate for the underlying engine in the IDEA+ prototype application. The ultimate reason that convinced us to start using this framework, was the support for multiple platforms and its free availability for academic research. The next version of IDEA+ was still based on MFC, but now incorporated the HOOPS framework. The main data structure was kept, but the graphical view was replaced by a native HOOPS window. This immediately allowed more advanced graphics, such as correct shading, easier support for camera manipulations and selections and a whole set of additional functionality, not least through a complete scenegraph organization. The difficult part was synchronizing all modifications from the IDEA+ data structure with the HOOPS representation. Other toolkits which enable scene-graph functionality are available and should the need arise, it is expected that the porting of IDEA+ to them is not too complicated, since most preparation work is performed in the main IDEA+ CORE, which stays framework and platform independent. It should be mentioned that Open Inventor has become an Open-Source toolkit, recently. There is also the Coin3D 5 toolkit, which is similar to Open Inventor and uses the same API, so source code for Open Inventor can be used almost without changes. As alternative solutions, the Visualization Toolkit (VtK)6 , OSG OpenSceneGraph 7 and OpenCASCADE 8 have been briefly evaluated, but not elected. OpenCASCADE did seem to provide the most CAD oriented features and more specifically, CAD modeling features, but it is not supported in Mac OSX, without workarounds9 . 4 HOOPS was originally produced by Autodesk, which sold it to a the German company Tech Soft Gmbh, which formed Tech Soft America (TSA). In 2006, the company was renamed to Tech Soft 3D. More info about HOOPS can be found at http://www.hoops3d.com and http://www.techsoft3d.com . 5 http://www.coin3d.org 6 http://www.kitware.com 7 http://www.openscenegraph.org 8 http://www.opencascade.org 9 http://keepcool.kf.tu-berlin.de/public/mitarbeiter/sadowski projects.html

370

Chapter 19. Implementing the prototype

Creating a cross-platform application To support multiple operating systems, the MFC toolkit is unusable. Since architects are mainly using Windows or the Macintosh OS, the choice arose for a GUI toolkit that supported them. For IDEA+ we elected the Qt toolkit [BS04] from Trolltech 10 . This is a platformindependent framework for applications, with a good and flexible GUI design. Interestingly, the toolkit has both a commercial and a GPL license. The toolkit supports MS Windows and Mac OSX, but also most variants of Linux and Unix. This toolkit has formed the basis for the KDE 11 framework, which is widely used with Linux distributions. The fact that the toolkit displays the interface using the native platform calls enables applications to inherit the common look and feel of the host platform, which is something that is often missing in other toolkits, such as TCL/Tk 12 . This is something that Java has also been doing recently, which helps the adoption and acceptation of these cross-platform toolkits. Figure 19.3 displays the application running in MS Windows and on Mac OSX.

Figure 19.3: Screenshot of the Windows and Mac OSX versions Figure 19.4 displays the application in two Linux variants; Ubuntu is using a GNOME desktop, while KUbuntu uses the KDE desktop. The application inherits the interface details of the host platform. 10 11 12

http://www.trolltech.com http://www.kde.org http://www.tcl.tk

19.1 Overview of different prototypes

371

Figure 19.4: Screenshot of the Linux version A similar approach could have been followed using wxWidgets 13 [SHC05], which also allows applications to be developed in a pure C++ fashion, releasing the programmer from the platform-specific code. This toolkit has a more liberate license, but has less coverage in tutorials or books and misses the integration Qt has in the HOOPS 3D toolkit. Considering the fairly smooth porting from the MFC application, it is assumed that this will still be a valid framework for future development.

Integrating a modeling kernel The last choice was the possible application of a graphical modeling kernel. This is a set of functions or libraries to perform geometric operations on surfaces or volumes. NURBS surfaces and solid modeling are two possibilities that might be supported by a modeling kernel. Since this is executed as mathematical operations on data structures in memory, there is no strict need for an interface or a representation, which leaves room for integration with other graphical toolkits, such as the HOOPS 3D Application Framework. Initially, a custom solid modeling kernel, using a Binary Space Partitioning Tree 14 , has been developed in house, but the prototype was not performing sufficiently for usage in a full CAD modeling application. It was assumed that 13 14

http://www.wxwidgets.org http://www.faqs.org/faqs/graphics/bsptree-faq

372

Chapter 19. Implementing the prototype

further optimizations would distract from the main focus of developing IDEA+, so the integration of this custom kernel was left out of the later versions. It is still not decided if we will integrate other modeling kernels inside IDEA+. Possible kernels are Spatial ACIS [CL01], PTC Granite or UGS Parasolid , which are the most commonly used commercial modeling kernels. However, a short evaluation of alternatives was performed. SMLib and SOLIDS++ are two alternative high-level commercial modeling kernels. Others include sgCore 15 which has a freeware edition and CADMAI 16 , which is based on OpenCASCADE and can be integrated in other applications. And then there are some freely available toolkits, such as the discontinued, but open source SVLis 17 , IRIT 18 , and GTS 19 for triangulated surfaces. Finally, there is also CGAL20 , which is strictly spoken not a modeling kernel, but a generic geometrical toolkit. It provides a set of geometrical operations that would be sufficient for IDEA+ and provides a mature and stable set of mathematical constructs for other operations[HHK+ 07]. The common problem is the limited cross-platform functionality of most of the non-commercial or open-source kernels. The commercial kernels support all required platforms. Not all of them are included in their academic licensed form, however, which is a limitation of the ACIS kernel, which is freely available for research projects. As a consequence, no additional modeling kernel is integrated in the current prototype. Should the need arise—such as when Boolean and Sweeping operations need to be included—an abstract kernel interface is being implemented, allowing the application to be linked with any chosen kernel, without any dependencies inside the data structure.

The current status of implementation At the time of writing, IDEA+ is a cross-platform data structure and a graphical prototype. The project utilizes the Qt framework to generate a GUI, while the HOOPS Application Framework is used for the scenegraph and the interactivity on screen. Custom Qt widgets have been developed to generically edit IDEA+ object properties and custom HOOPS operators are used for graphical object creation and manipulation. Two additional code libraries are embedded in the program, which are TinyXML21 , to write and read XML documents and GPC which is the General Polygon Clipper22 This clipping library is used to perform 2D Boolean operations on the IDEA+ polygons. In total, the IDEA+ source code has about 50.000 lines of code, spread over about 380 files, which include images and resources. The source code is com15 16 17 18 19 20 21 22

http://www.solidgraph.com/geometros/sgcore http://cadmai.com/html/home en.html http://www.bath.ac.uk/∼ensab/G mod/Svlis http://www.cs.technion.ac.il/∼irit http://gts.sourceforge.net http://www.cgal.org http://www.grinninglizard.com/tinyxml/index.html http://www.cs.man.ac.uk/∼toby/alan/software/ .

19.2 The Graphical User Interface

373

prised of about 20.000 commented lines, 5.000 with code and comments combined and 8.000 blank lines for legibility. The ratio between comments and code is 0.44. It has been developed simultaneously for MS Windows and Mac OSX, using MS Visual Studio and XCode respectively. While not every version was tested on Linux, the current release compiles and runs fine on Ubuntu, after some slight alterations to the code. While the HOOPS libraries are not available for every compiler and platform, Qt compiles on most platforms and compilers and IDEA+ wraps the few places with platform-specific code with some preprocessor macros, which are easily adapted when other platforms are tested.

19.2

The Graphical User Interface

The IDEA+ interface is a mixture between 3D and CAD applications. A small set of toolbars and dialogs are envisaged as generic manipulation widgets. It is planned to generate menus and toolbars automatically from the available commands and object types, but this is not implemented in the current prototype. This will enable to integrate add-ons directly in the IDEA+ interface. This section quickly describes the interface of the prototype. It is inspired by common CAD and 3D applications, since these are the tools designers are familiar with. Figure 19.5 displays a mockup of the User Interface, with all desired interface elements.

IDEA+ Application

File Edit Create Modify TestUtilities View Options Windows Help TOOLBAR

Project View

VIEW TOOLBAR

C R E A T E

GRAPHIC VIEWPORT

STATUS INFORMATION

Figure 19.5: GUI Mockup

MODIFY Properties

374

Chapter 19. Implementing the prototype

Menu The menu is structured around the available commands, which also display the assigned keyboard shortcuts. The additional menu entries follow the same structure as most common applications, which are mostly based on the style of the MS Office suite of applications23 . File All commands that manage the application and the project file. Printing commands, when available, will also be included here. Edit Common edit operations, such as cut, copy and paste, but also operations that handle selections. Create All objects that can be inserted in a project. This is subdivided in categories. • Building Elements, which are effectively the Physical Elements. • Conceptual Elements, which contain non-physical design entities, such as Spaces, Grids and Masterplan Elements. • Graphical Elements, which are used for annotation and drawing, without the requirement of a full building entity. • Scene Elements, for visualization purposes, such as lights and cameras. Modify Commands to change IDEA+ entities. These are specific design commands, including transformation commands. Test Utilities The list of integrated evaluation tests. This is dependent on the installed and loaded test modules. View Controlling the display. The visibility of user interface elements from the viewports. Window Also a common menu entry, to control the different opened views. This is especially important when more than one project file is opened. Help Access to the online help, if available. This also includes the obligatory About... dialog. Links and tutorials for users and developers will find their place here as well. This is nothing spectacular, but it creates a familiar structure. Small platform differences, such as the different Application menu in a Mac OSX application, are managed by the application framework. 23 It has to be mentioned that MS Office enhances its interface with every new release, which is an enormous influence on other software. Most people are using applications such as MS Word and MS Excel. Release 12 (or 2007) of this suite of applications, however, throws away menus and opts for a panel-based user interface. It is assumed that many other software applications will follow this style. It is also assumed that many of these style elements will be provided by application frameworks. This is clearly not the focus of this research.

19.2 The Graphical User Interface

375

It is important that menu entries display shortcuts and also the same icon as used on the toolbars. Alan Cooper [CR03] describes the valuable learning strength of placing command icons inside the menus. People usually start learning through textual menus, but at the same time start recognizing the associated icons which can also be found on the Toolbars. At the same time, the Tooltips 24 display the command name, together with a longer descriptive string which appears in the Status Bar. This functionality is almost taken for granted and is catered for by the application framework, but the lack of details might increase the learning path. It takes only little effort to be thoughtful over these details, while it decreases the time to learn an application.

Toolbars Toolbars have buttons and sometimes other widgets, which give fast access to the application settings. They can be moved, docked and hidden if required. Main Toolbar This is the common toolbar in most applications. A small subset of the menus is retrieved here for faster access. It is placed directly underneath the menu, at the top of the application interface, as shown in Figure 19.6.

Figure 19.6: Screenshot of the Main Toolbar

Modify Toolbar The different manipulation tools are grouped in the Modify Toolbar, from Figure 19.7. They contain tools for translation of entities, selection and manipulation of the Reference Points, including point insertion, point translation and point deletion.

Figure 19.7: Screenshot of the Modify Toolbar

Create Toolbar This is quite similar to the tool palette from applications such as Adobe Photoshop, although this toolbar is focused on the insertion of the different object types. It is placed at the left screen side, by default, but Figure 19.8 shows it in a horizontal layout, for legibility.

Figure 19.8: Screenshot of the Create Toolbar 24 Usually small yellow notes, which temporary appear when the user hovers the mouse over a button.

376

Chapter 19. Implementing the prototype

View Toolbars The graphical window also hosts two toolbars. One toolbar manages the display settings, Figure 19.9, while the other accesses the available Representations and the settings for the active Representation, in Figure 19.10. These toolbars stay attached to the view.

Figure 19.9: Screenshot of the Display Toolbar

Figure 19.10: Screenshot of the Representation Toolbar

Status Bar This bar, which can be found at the bottom of the application window, displays some feedback to the user, such as the current coordinate, help texts when hovering over menus or toolbar buttons and the status of the current project. This is less common with Mac OSX applications, but it is retained in this edition as well, to provide information.

Property Panel The Property or Info panel informs the user of the properties of the selected elements. Its functionality is comparable with the Command Panel from Autodesk 3ds max or the Property Panel in Autodesk AutoCAD and Nemetschek VectorWorks. When the user selects an element, it is loaded with all the properties, which happens through the abstract interface of the objects. Whatever properties the object has and whatever its type, all of the properties are added as entries into a tree-widget, where they can be queried and edited. Figure 19.11 illustrates how the selection of a single wall loads all its properties into the panel, ready for editing. At the bottom of the panel, information about the currently selected property is displayed. Some specific properties will load a separate dialog to edit their value, such as a color chooser or a file chooser. Whenever the user changes any of the properties, this modification is executed as a Command , so it is kept in the command history where it can be undone if needed.

Viewport & Representations The rest of the interface is used by the graphical display viewport. Depending on the active Representation, this will show a graphical 2D or 3D representation or a conceptual representation, such as a Schematic View. The 2D Representation uses lines, polygons and additional linestyles and hatching. This is also a view where objects without full 3D representation are displayed, such as a symbol display or a label.

19.2 The Graphical User Interface

377

Figure 19.11: Screenshot of the Property Panel The 3D Representation displays the entities as lines and surfaces, also using colors, linestyles and hatching or texturing to display characteristics such as materials or functions. An example is found in Figure 19.12, which displays the same simple scene, using a 2D and 3D representation. The 2D representation is not restricted to a Top view direction.

Figure 19.12: 2D and 3D Graphical Representation A Schematic View can display objects as boxes and relations as arrows, as shown in Figures 19.13 and 19.14. This can also take the shape of a tree or a matrix,

378

Chapter 19. Implementing the prototype

but that is left to the Representation itself.

Figure 19.13: Schematic Representation of Object Links

Figure 19.14: Schematic Representation of Dependence Links Figure 19.15 displays a small building in the 3D Representation mode, where the different Scale Levels are shown. The Entities of the current Scale Level are displayed as shaded volumes, while the elements of the other Scale Levels are displayed in a wire frame modus.

Figure 19.15: Display of different Scale Levels

19.3 The implemented Prototype

19.3

379

The implemented Prototype

This concludes the overview of the implementation of the prototype. It was deemed appropriate to position the application against existing software and to give a brief overview of the application GUI. The prototype is not complete. Some important functionality is still lacking, while real productivity can still improve. A good example is the editing of object parameters. At the moment, each object has to be selected individually to be able to display its properties. When the users needs to make more extensive adjustments, this is not efficient. A better interface would allow to make these adjustments to a group of entities at once. Some of the functionality that is inherently available, is not supported in the GUI, due to lack of time. It is sometimes possible to force a certain behavior by editing the exported file in a text editor, since it is after all just an XML ASCII document. While this is certainly not recommended for end users, it is possible. A good example is the creation of additional layers in a composition. As long as the interface for the advanced editing of lists of objects is not finished, this has to be done directly in the file. When reloading the file, the adjusted lists are correctly read, provided there are no syntax errors. Another necessary improvement lies in the end user documentation. There is a basic overview of the application included in the source code documentation but not up to a point where a novice user will have full support. This is all a matter of time and priorities. In this prototype for academic research, this was not the end goal. Since the whole source code is documented quite extensively, using the Doxygen syntax, it is possible to automatically derive a large bundle of developer documentation from the code. This systems supports different output formats, such as HTML, Windows Help Files or LATEX documents. At the time of writing, this resulted in a book containing about 500 pages, including the documentation, the diagrams and the header files contents, but without the actual source code. There are also some additional features that have been implemented in the prototype, but which are not discussed here. Some of them were possible through the use of both external frameworks. Some HOOPS-related features are listed. â&#x20AC;˘ The application supports different display modes, such as a wire frame view and a hidden line view. It can also switch between perspective and isometric projection. â&#x20AC;˘ There is basic support for the display of mapped shadows directly on the ground plane. Future releases of HOOPS will include advanced Shader support, which will improve the materials appearance considerably. The current prototype uses no textures. â&#x20AC;˘ The graphical representations allow exporting the 3D model into additional external formats, which might be used to transfer the geometry into other software.

380

Chapter 19. Implementing the prototype

• There is an interactive clipping plane, which can create realtime sections through the project. It currently lacks settings, but with some additional effort, it might be used to easily create horizontal and vertical sections. There are also a few features that are made possible by the Qt framework [BS04]. • The application can switch to a different language. This system will allow to support different languages from a single application. While this was partly completed to translate the user interface in Dutch, all strings that are generated in the data structure are not using the Qt methods and are thus not translatable with this approach. A different solution still has to be found for those text strings. • The layout of the application is automatically stored when closing down the application. There is also support for skinning of the interface, but our own preference is to stick with the GUI style from the OS, which is the default approach used in Qt. • Menus can be dragged to make them floating. Toolbars can be hidden and displayed when clicking the toolbar area. The panel can be docked, floated and hidden. • Many shortcuts are available to control the application. Some of them are single character shortcuts, which can speed up the modeling process considerably. There is still a minor problem in the OSX version, where these shortcuts interfere while trying to set the file name when saving. Using capitals is currently the only work around. While this functionality is not part of the research project, it will become more important in possible future research, when the application has to be evaluated by external designers and architects. In that case, it becomes important to follow common user interface trends and make the application reasonably user friendly, to avoid wasting too much time explaining the interface but rather focus on the approaches used in the prototype.

Chapter 20

Final Conclusions 20.1

Evaluation & Limitations

The Applications overview The first part of this doctoral research provides a long overview of design software from different disciplines. This was mostly motivated to provide better insight into the current state of the art in digital modeling and to illustrate approaches from other disciplines that architects might not be familiar with. It can be noticed that many references are made to websites and publications from outside an academic context. This has both advantages and disadvantages. Many academic sources have a tendency to have more thorough and neutral position and claims are better motivated. However, in the context of software for designers, a large part of the necessary references and information is not available within the academic publications. Since this doctoral research often references existing commercial BIM applications, it was necessary to retrieve information about them through product manuals, company websites and so called white papers. It is our opinion that these sources are valid in this research, provided that they are stripped from their marketing terms and criticism to the approaches is formulated. To learn more about the limitations of the applications and their concepts, it was important to get involved in some of the user communities, which can be found as online bulletin boards and with local user groups. Participation helps to keep contact with practising users, to understand how they manage their practices using these complex and expensive tools. It also helped a lot that I have previously worked in a few architects offices, which enabled to gain some valuable experience with the profession and with the applications that are used. It is from this experience that I gained more insight into applications such as AutoCAD, VectorWorks and ArchiCAD. Additional experience is gained through the teaching efforts in the CAAD Exercises, at the Department of Architecture, where I currently perform my research. Students of architecture, learning these applications, can provide valuable feedback on approaches that are proposed by software companies. In many cases, they struggle to efficiently use these applications to their full potential, apart from maybe a program such as SketchUp. The overview of trends and the discussion on data exchange has also grown from these experiences. While it can be argued that data exchange problems will be 381

382

Chapter 20. Final Conclusions

solved with another file format, it is important to understand the theoretical potential of a format such as IFC against the current widespread reliance on exchanging 2D CAD drawings using the DWG format from Autodesk.

The Implementation The current data structure and prototype are both still a work-in-progress. The data structure is fairly complete and provides a flexible platform for extensions. It is straightforward to introduce new design entities or to alter the behavior of existing entities. When changing the data structure, only minor adjustments have to be made to the current prototype. The prototype is also cross-platform. It has been successfully ported to the major current platforms, with different compilers. At the time of writing, IDEA+ was tested on the different platforms in Table 20.1. Table 20.1: Compatible platforms Platform Ms Windows Mac OSX Linux

Version XP and Vista 10.4.x PPC Ubuntu 7.04 64-bit KUbuntu 7.04 32-bit

Compiler MS Visual C++ 8.0/2005 XCode2 (gcc 4) gcc 4 gcc 4

During the development, other platforms and compilers have been used, including earlier versions of MS Visual Studio (6.0, 7.0/2002 and 7.1/2003) and other Linux distributions such as SuSe Linux 9.3 and OpenSuSe 10.1. In most cases, the code was ported with only minor adjustments. The use of Qt *.pro files allows the qmake program to generate valid Makefiles and Project files for different compilers. The frameworks were occasionally updated to newer versions, during the research project. This provided only minor issues with HOOPS, which went from release 11 to release 15, although the current prototype still uses release 14. Stepping from Qt 3.x to Qt 4.x was a much larger effort, but with many advantages, due to a complete internal restructuring. While it was never the aspiration of creating a complete CAD system, the current prototype at least has the potential to evolve into one, considering the foundation laid out with the Property System. This would be valuable to enable other researchers to create additional functionality, such as evaluation tests. This is currently evolved into a level that seems usable as a platform for custom functionality that might be added in the course of a Masters Thesis. Limitations and Validation The current application is oriented towards architects as end users. However, at the moment, some of its functionality is not provided through the user interface,

20.1 Evaluation & Limitations

383

such as the direct editing of lists of objects, which might be necessary for end users. At the same time, the application can not compete with existing CAD software. While that was not the intention, it might place a burden on introducing the application to other users. At this point, it might appeal more to developers, who are interested in elaborating design entities, representations or evaluation tests, rather than the architects as end users, who would need to use it as a design tool. To be able to prove the advantage of this system will require better validation. The biggest potential problem with the current system is the lack of user testing and evaluation. It would be helpful to receive feedback about the proposed concepts from practising architects, e.g. by applying the prototype in design exercises. However, it is also felt that the current state of the software might require some additional work to become usable by end users.

20.1.1

What about the Integrated Design Environment?

At the beginning of this research project, there was the ambition to investigate an Integrated Design Environment. Mitchell [MC94] and Junge [JL95] define this as a collaboration between different applications, hardware and people of the design team using a shared project database. In our proposed definition, an integrated design environment would be based around a central building database or repository, to which different external modules can connect concurrently. These can be modules for drafting and modeling, but also for evaluation tests. This is illustrated in Figure 20.1. This Figure is based on the schematic presentation of the IDEA+ environment as discussed in the CORE Object Model [Hen00, p.74, Figure 4-2]. Following the reasoning in [Hen00, Ch.4,p.73], there is a possible choice between a neutral core model and a common core model, as illustrated with Figure 20.2, originally from [Hen00]. In the common core model, each external module works directly on the same data, removing the need for additional translation between a neutral model and the external application. At this point in our implementation, we are still at the point of the neutral model, which is the IDEA+ XML file. To be able to migrate to a common core model, an additional wrapper around this file would be required. If this file is replaced by a database or not, is actually irrelevant. It might have technical advantages, by applying known Database Management technology, but at the same time, introduce stringent dependencies to the database system. When applying for systems such as MySQL, MS SQL or others, this requires database server software, possibly network access and permission control. It is also possible to use an embedded database, such as SQLite 1 , which removes many of 1

http://www.sqlite.org

384

Chapter 20. Final Conclusions

AutoCAD

Daylight Simulation

MicroStation

Cost Evaluation

ArchiCAD

data structure Framework

...

Planning

... CORE Building Database

Figure 20.1: An integrated design environment

Figure 20.2: Neutral versus Common Core Model

20.2 Future research

385

the administrative requirements of a database system, yet still allows the use of SQL queries and regular database communication. It stores the database as a single file and the whole database engine can be embedded in an application. At the same time, it is hoped that the current data structure, together with the proposed support for transitions, could form the core structure to support such an environment. Translating the application into a database driven system would probably help to reach that goal.

20.2

Future research

20.2.1

Integration with CAD applications

IDEA+ is developed as a stand alone design application. It would, however, be worthwhile to explore the possibility of integrating some of the concepts of IDEA+ within existing CAAD and BIM applications. In particular, the approach of integrating evaluation tests into a core building structure would be beneficial for many designers. Making such tests available for many different design applications would allow us to reach a wider audience than limiting it into a single application. Embedding the concepts of Reference Points and Property Connections, however, is much more complex and is not likely to be possible in all these applications, due to the restricted access that these applications provide. Programs such as Autodesk AutoCAD and Graphisoft ArchiCAD provide means to extend the application with additional modules. They have an API which defines a series of methods to extend the functionality of the application at runtime. This is quite complex, since all these commercial applications are strictly considered closed source. The actual source of these applications is not available. Through the use of libraries which can be loaded at runtime, they provide access to some predefined methods. Some applications have a long history of providing wide access to many methods, while others have only recently provided such access.

Extending existing applications There are three distinct approaches to extend the functionality of applications. Scripting & Macro Languages When an application can execute scripts at runtime, the user has a quick and easy entry point to call application methods. A widely used scripting language is AutoLisp, as embedded within AutoCAD. Scripts are defined in text files and are interpreted at runtime by the application. No compilation is required and the scripts are usually portable with only minor adjustments between application versions. Autodesk 3ds max provides the powerful MaxScript and Autodesk Maya has the MEL scripting language. These are both examples of very

386

Chapter 20. Final Conclusions extended scripting languages, which can enhance the application extensively. This is especially important in production environments, where not all the requirements are covered by the off-the-shelf application.

Embedded Programming A step further are embedded full programming environments, such as Visual Basic for Applications from Microsoft, which uses the Visual Basic programming language and which has been made available in programs as varied as Microsoft Excel, Autodesk AutoCAD, Bentley MicroStation and CorelDRAW. There are many others, but they all require a license fee from Microsoft, which explains why free versions of some of these applications, such as ProgeCAD LT, only include this module in the non-free commercial versions, such as ProgeCAD Professional. External Programming When the program allows the use of external modules, they have to be compiled, rather than interpreted, which usually boosts the performance. These are almost exclusively modules programmed in C or C++. The ObjectARX Software Developers Kit (SDK) is used in AutoCAD or AutoCAD-based programs, while Graphisoft provides the DevKit. An important limitation of compiled modules are the compiler incompatibilities. When a program is compiled and linked, the source code is translated into machine- and platform-specific object code. This forces external developers to use exactly the same compiler as the host program. This is quite commonly a version of Microsoft Visual C++. It is even as strict as forcing the developer to use the exact same version of the compiler2 . This is important even for end users, since it requires that all external modules be recompiled. Since many of these modules are not free and not open-source, this might come at an additional cost for the user for an updated version. When the company stops developing the module it is even impossible to use the module anymore in the newer releases of the host system. When users rely heavily on the functionality of these external modules, this might even prevent them from upgrading their CAD software to a new release. There is a trend in recent applications, such as Autodesk Revit, to use the .NET programming languages, usually targeting C# (C sharp) or Visual Basic.NET. Integrating IDEA+ inside CAD software Since it is likely that architects are already using an existing CAD application, it might be beneficial to think about integrating some of the functionality of IDEA+ inside such an application, instead of requiring the architect to switch applications. It is therefore interesting to create a plugin version of IDEA+, comprising two main modules. An integration module, which is embedded in the host software 2 This is one of the reasons why AutoCAD stayed compatible with modules for three full releases. The releases 2004, 2005 and 2006 all utilized the 7.0/2002-release of Visual C++. The current 2007 release stepped up to Visual C++ 8.0/2005-release.

20.2 Future research

387

and plugins for this integration module, which enable some of the functionality of IDEA+ inside the integration module. The Evaluation Tests would probably be the most realistic modules to integrate, especially the data extraction tests. A concepts scheme is displayed in Figure 20.3. This explains how the modules will be integrated inside a main CAD application. The main integration module is abstract, but is used in a concrete application plugin. It defines the interface with which the external modules can access the host application. The external modules all derive from the Module Interface, which defines the methods all external modules should support. This has a structure similar to the Test class in the regular IDEA+ framework.

Host API

ArchiCAD Host

AutoCAD Host

Revit Host

Microstation Host

IDEA+ Module Interface

Lighting Test

Cost Test

Heatloss Test

...

Figure 20.3: Integrating modules from IDEA+ in existing CAD software The system is meant to provide a generic integration module, with which the IDEA+ modules can connect. This generic integration module is then implemented as a translation layer between the CAD software and the IDEA+ kernel. All other modules will then be loaded by the integration module and can be developed further independently of the host CAD system. It is envisaged that this would be a feasible undertaking, allowing additional test modules to be programmed completely independent of the underlying CAD system. It would obviously not expose the whole CAD system functionality through the integration layer, but that is not the purpose of this concept. It would be primarily targeted at a swift development approach to test and embed new evaluation concepts, without the burden of a full support of the CAD system. The modules will have access to some generic query methods, to retrieve information from the host CAD softwareâ&#x20AC;&#x2122;s building model, such as a listing of all

388

Chapter 20. Final Conclusions

room or space areas or the volume of all walls with a brick material. Possible limitations can be identified. • It can be very complex to derive the building structure from the host application. It is probably not feasible to define a full translation module, although it prevents the requirement of cumbersome file exchange scenarios for a large part. • The API methods in the host systems are very different and using them requires good knowledge about the host. Potentially the most important hurdle will be the fact that the user might not know what information can be retrieved by the integration module. Not every single parameter of every single object type will be meaningfully translated. • The availability of the API methods is widely differing between applications. The Architectural Desktop API is not available in the same way as the regular AutoCAD ObjectARX API. It requires separate license fees. The compiler requirements are also different, as explained earlier. The worst case scenario is where all host systems require several compiler versions to at least support the latest versions of these systems. Since IDEA+ itself is largely independent from the used compiler, this might be a minor issue. It is assumed that a first proof-of-concept should be developed to identify the potential difficulties caused by the integration, before any other step will be taken. This does not have to cater for all possible CAD hosts, but it is assumed that more than one system will have to be tried. Difference with an Integrated Design Environment? This integration approach is different than the proposed Integrated Design Environment. In such an environment, it is assumed that many different applications and users could all interact on a shared database. With this integration, however, each design application stays independent and continue to use its own internal database. Integrating IDEA+ in external CAD software will add functionality to the external software, rather than using the external software as interfaces or clients to a central database. However, this might be an approach that is easier to implement, while still being beneficial to many different designers.

20.2.2

Integration with DYNAMO

DYNAMO is the acronym for a Dynamic Architectural Memory Online [HN00]. DYNAMO is an online multimedia platform, which supports architects by sharing a growing online collection of concrete design cases. It is based on applying concepts of Case-Based Reasoning (CBR) into the field of architectural design. Despite that fact that experience with Case Based Design (CBD) tools seems

20.2 Future research

389

to have shown limited results so far, there is also the reassurance of the validity of using cases in architectural design [HN03]. During the early design stages, architects rely on projects from the past. Previous design cases provide an underlaying context to evaluate design options and to motivate design decisions. However, experiments with architects in different contexts and at various levels of expertise have shown DYNAMO to suffer from some major limitations. The platform is completely separated from the regular design applications, which hinders its consulting during the design stage. At the same time, it takes skill and effort to properly prepare a project for inclusion in this database. It is assumed to be beneficial to combine the potential of this structured cases repository with an actual design application. The integration with DYNAMO could take the form of an embedded design window, directly from within the IDEA+ application. It is more than browsing through the cases. By tagging projects and keywords, the designer can capture the reference context for the ongoing design. This will allow to review the design later on, with the same external references to exemplary design cases. It should provide an approach to link design decisions in a structured way to reference projects that served as inspiration. At the same time, through the interconnections of projects in DYNAMO, it will become easier to discover related design projects, to provide additional reference content, serving as â&#x20AC;&#x153;design recommendationsâ&#x20AC;?3 .

20.2.3

Adding additional functionality

The development of a complete architectural design application is a large task, which is impossible to complete in a single research project. Even then, there are still many possible improvements and extensions. Based on the elaborate overview of design applications, some possible future functionality will be described. Some of these features will be easier to integrate than others. To improve the potential of IDEA+ as a development platform, it would be interesting to provide a more modular and data driven system. Instead of defining the functionality of the different design entities directly in the source code, a more dynamic approach could be imagined.

Plugin structure The whole application could be restructured to enable a wider use of plugins. Only the generic functionality would stay a part of the core application, while the different Representation types, the different object types and the different commands would be dynamically loaded during the startup phase. 3 This Section is based on a project outline for the K.U.Leuven Research Funds, but was not retained.

390

Chapter 20. Final Conclusions

This would enforce a more flexible application structure and would allow to automatically create the application interface, providing the different toolbars and menu entries from these plugins. External Design Entities This can even be taken a step further, by defining these external plugins in a text-based format, rather than requiring them to be compiled. When each design entity is loaded at runtime, from an external file, possibly using an XML-syntax, the end user could more easily experiment with different types of design objects. It would be possible to extend the application with new CAAD Entities, without altering the source code. The external file could contain the necessary administrative information to identify the entity and provide some kind of script which will generate a suitable representation. The same file could than expose the available user parameters, which would be available in the regular user interface. This is largely inspired by the flexibility of a tool such as Shaderman, as discussed on page 24, where the different building blocks of the application are merely external data files. Integration of a Solid Modeling Kernel While there is a reasonable variety of modeling functionality present in the current implementation, this takes a considerable development effort. More flexible and powerful modeling could be enabled with the integration of an external modeling kernel. The current graphics module could then serve as an intermediate translation layer, to make the application independent of the used kernel. At the time of writing, the OpenCASCADE kernel seems to be a good candidate, since it is available with its source code. However, it is currently not available for the OSX platform, although one of the users has managed a partial porting. This would make the support for NURBS surfaces, lofting and Boolean Operations more easily obtainable. While it is technically possible to write a custom modeling kernel, history has learned that most applications will rather rely on existing kernels, due to the high complexity to create a reliable and performing system. Procedural and Parametric Approaches While the current system is not started from a procedural methodology, some possibilities to enable this are starting to emerge. The support for Property Connections, combined with custom Operator objects promises at least support for custom relations between arbitrary objects, which would benefit from a better schematic representation, to allow a form of Visual Programming.

Bibliography [Abl03]

Dan Ablan. [digital] Cinematography & Directing. [digital] Series. New Riders, 2003.

[Ach97]

Henri Achten. Generic Representations. TU/Eindhoven, 1997.

[ADT06a]

ADT Website. http://www.autodesk.com/adt , 2006.

[ADT06b]

ADT Wiki. http://www.tripleddesign.com/wiki/index.php/ ADT Main , 2006.

[AEC06]

AECCaf´e. http://www.aeccafe.com , 2006.

[AG00]

Anthony Apodaca and Larry Gritz. Advanced RenderMan: Creating CGI for Motion Pictures. Morgan Kaufmann, 2000.

[AIS+ 77]

C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel. A Pattern Language. Oxford University Press, New York, 1977.

[Ale65]

Christopher Alexander. A City is Not a Tree. Architectural Forum, 122(1):58–62, Apr 1965.

[Ale66]

Christopher Alexander. A City is Not a Tree. Architectural Forum, 122(2):58–62, May 1966.

[ALK+ 07]

Kristian Agger, Michael Lassen, Nikolaj Knudsen, Ruben Borup, Jens Rimestad, Peter Norholdt, and Nikolaj Bramsen. Bprocessor. Building Information Design and Management. In Joachim Kieferle and Karen Ehlers, editors, Predicting the Future, Proceedings of the 25th eCAADe Conference, pages 43–50. eCAADe, Sep 2007.

[ARC06]

ARCHIdigm. http://www.archidigm.com , 2006.

[Art06]

Inc. Artifice. ArchitectureWeek. http://www.architectureweek. com , 2006.

[Atk02]

Dwight Atkinson. Illustration in ArchiCAD. Graphisoft R&D, Hungary, first edition, 2002.

[Atk05]

Dwight Atkinson. LightWorks in ArchiCAD: The things You Need to Know. Beginner-No-More Publishing, Vancouver, Canada, 2005. 391

PhD thesis,

392

BIBLIOGRAPHY

[Aub06]

Paul Aubin. http://www.paulaubin.com , 2006.

[Aug95]

Godfried Augenbroe. The COMBINE project: a global assessment. In M. Fisher, K. Law, and B. Luiten, editors, Modeling of buildings through their life-cycle, CIB Proceedings, Publication 180, pages 163–171, Stanford California, USA, Aug 1995.

[BF00]

Alexander Bicalho and Simon Feltman. Mastering MAXScript & the SDK for 3D Studio MAX. Sybex, Netherlands, dutch translation edition, 2000.

[BFF+ 95]

Suresh K. Bhavnani, Ulrich Flemming, Diana E. Forsythe, James H. Garrett, Doris S. Shaw, and Albert Tsai. CAD usage in an architectural office: from observations to active assistance. Automation in Construction, 5:243–255, 1995.

[BG05]

Zafer Bilda and John S. Gero. Do we need CAD during conceptual design? In Bob Martens and Andre Brown, editors, Proceedings CAAD Futures 2005, pages 155–164. CAADFutures, Springer, 2005.

[Bir00]

Jeremy Birn. [digital] Lighting & Rendering. [digital] Series. New Riders, 2000.

[Bj¨ o92]

B. C. Bj¨ ork. The topology of spaces, space boundaries and enclosing structures in building product data models. In Drana Vanier, editor, Computer-Integrated Construction, Papers from CIB W78 workshop, pages 56–92, Montreal (Canada), May 1992. CIB.

[Bj¨ o94]

B. C. Bj¨ ork. The RATAS project - developing an infrastructure for computer integrated construction. ASCE Journal of Computing in Civil Engineering, 8(4):401–419, Oct 1994.

[BLK97]

B. C. Bj¨ ork, K. L¨ownertz, and A. Kiviniemi. ISO 13567, The proposed international standard for structuring layers in computer aided building design. In Computers in the Practice of Building and Civil Engineering, Proceedings of the Worldwide ECCE Symposium, pages 85–89, Finland, Sep 1997.

[Boj05]

G´ abor Boj´ar. The GRAPHI-story. Graphisoft, 2005.

[Bou90]

Stichting Bouwkwaliteit. Elementenmethode ’91. bouwkwaliteit, Rijswijk (Netherlands), 1990.

[BS04]

Jasmin Blanchette and Mark Summerfield. C++ GUI Programming with Qt3. Bruce Peren’s Open Source Series. Prentice Hall Professional Technical Reference, fourth edition, 2004.

[BTM01]

Frances Bonnet, Ben Tucker, and Scott MacKenzie. Panel 5 : The Stata Center at MIT. In Ann Heylighen, editor, Pockets of Innovation. Real Estate, Construction and the Internet, pages 25–28. Harvard Design School, Nov 2001. ISBN 0-935617-58-2.

Stichting

BIBLIOGRAPHY

393

[BW91]

B. C. Bj¨ ork and J. Wix. An introduction to STEP. VTT and Wix Mclelland Ltd., 1991.

[CAD06a]

CAD Digest. http://www.caddigest.com , 2006.

[cad06b]

cadalyst. http://www.cadalyst.com , 2006.

[CC05]

Michael E. Cohen and Dennis R. Cohen. The Mac Xcode 2 Book. Wiley Publishing Inc., 2005.

[CIB86]

CIB. CIB-W74 Information co-ordination for the building process, A Practice Manual on the use of SfB. An Foras Forbartha, Dublin (Ireland), 1986.

[CK94]

G. Carrara and Y. E. Kalay, editors. Knowledge-based ComputerAided Architectural Design, Proceedings of the Symposium, Rome, Italy, May 1994. CNR, Elsevier Science.

[CL01]

Jonathan Corney and Theodore Lim. 3D Modeling with ACIS. Saxe-Coburg Publications, 2001.

[CMH05a]

Humberto Cavallin, W. Mike Martin, and Ann Heylighen. This is not a Caucus-Race; Or why upgrades in GUIs will (not necessarily) make users (instantly) more productive. Computer-Aided Design & Applications, 2(1–4), 2005.

[CMH05b]

Humberto Cavallin, W. Mike Martin, and Ann Heylighen. This is not a Caucus-Race; Or why upgrades in GUIs will (not necessarily) make users (instantly) more productive. In Proceedings of the 4th Social Intelligence Design Workshop (SID2005), volume CD-Rom. Stanford University, Mar 2005.

[Coo95]

Alan Cooper. About Face: The Essentials of User Interface Design. IDG Books Worldwide, Inc., 1995.

[CR03]

Alan Cooper and Robert Reimann. About Face 2.0: The Essentials of Interaction Design. John Wiley & Sons, 2003.

[Cro82]

Nigel Cross. Designerly ways of knowing. 3(4):221–227, 1982.

[DeL00]

Mark DeLoura, editor. Game Programming Gems I. Charles River Media Inc., 2000.

[DeL01]

Mark DeLoura, editor. Game Programming Gems II. Charles River Media Inc., 2001.

[Dem02]

Owen Demers. [digital] Texturing & Painting. [digital] Series. New Riders, 2002.

[DNHS89]

Frank De Troyer, Herman Neuckermans, D. Havenne, and F. Simon. Rapport C: BB/SfB en de grafische voorstelling van ontwerpbeslissingen bij het computergesteund ontwerpen, Toepassingsmogelijkheden voor de Regie van Gebouwen, Rapport in

Design Studies,

394

BIBLIOGRAPHY het kader van het studiecontract K.U.Leuven MOW Regie der Gebouwen. Regie der Gebouwen, Leuven, Belgium, 1989.

[DNHS90]

Frank De Troyer, Herman Neuckermans, D. Havenne, and F. Simon. BB/SfB Tabellen. Regie der Gebouwen, Brussels, Belgium, 1990.

[Do00]

Ellen Yi-Luen Do. Sketch that Scene for Me: Creating Virtual Worlds by Freehand Drawing. In Promise and Reality: State of the Art versus State of Practice in Computing for the Design and Planning Process, Proceedings of the 18th eCAADe Conference, pages 265–268, Weimar (Germany), june 2000. eCAADe. ISBN 0-9523687-6-5.

[DP04]

Matthias Kalle Dalheimer and Jesper Pedersen. Practical Qt. dpunkt.verlag, first edition, 2004.

[DS94]

Guido Dedene and Monique Snoeck. M.E.R.O.D.E.: A Model-driven Entity-Relationship Object-oriented DEvelopment method. ACM SIGSOFT Software Engineering Notes, 19(3), 1994.

[dVA02]

Bauke de Vries and H.H. Achten. DDDoolz: Designing With Modular Masses. Design Studies, 23(6):515–531, 2002.

[EB95]

L. Eggli and B.D. et al Bruderlin. Sketching as a Solid Modeling Tool. In C. Hoffmann and J. Rossignac, editors, Third Symposium on Solid Modeling and Applications, pages 313–321. ACM, 1995.

[EF00]

Anders Ekholm and S. Fridqvist. A concept of space for building classification, product modelling and design. Automation in Construction, 9(3), 2000.

[Ekh96]

Anders Ekholm. A conceptual framework for classification of construction works. Electronic Journal of Information Technology in Construction (ITcon), 1, 1996. Stockholm: Royal Institute of Technology.

[Ekh01]

Anders Ekholm. Information systems for architectural design. Experiences from the BASCAAD and ACTIVITY projects. Nordic Journal of Architectural Research, 14(3), 2001.

[ES95]

C. M. Eastman and A. Siabiris. A generic building product model incorporating building type information. Automation in Construction, 3:283–304, 1995.

[FBW00]

T. Fischer, M. Burry, and R. Woodbury. Object-Oriented Modelling Using XML in Computer-Aided Architectural and Educational CAD. The Problem of Interoperability Exemplified in Two Case Studies. In Proceedings of the Fifth Conference on Computer Aided Architectural Design Research in Asia, CAADRIA, pages 145–155, Singapore, May 2000. CAADRIA. ISBN 981-04-2491-4.

BIBLIOGRAPHY

395

[FCF94]

U. Flemming, R. Coyne, and S. et al Fenves. SEED: A Software Environment to Support the Early Phases in Building Design. In Proceeding of IKM ’94, pages 5–10, Weimar (Germany), 1994.

[Fer01]

Robin Stuart Ferguson. Practical Algorithms for 3D Computer Graphics. A K Peters LTD, 2001.

[Fos96]

R. Fosner. OpenGL Programming for Windows 95 and Windows NT. Addison-Wesley, 1996.

[FR06]

Anthony Frausto-Robledo. Architosh. http://www.architosh.com , 2006.

[FvDF+ 93]

James D. Foley, Andries van Dam, Steven K. Feiner, John F. Hughes, and Richard L. Phillips. Introduction to Computer Graphics. Addison-Wesley, 1993.

[Gal95]

Per Galle. Towards integrated, “intelligent” , and compliant computer modeling of buildings. Automation in Construction, 4:189– 211, 1995.

[Gee03]

Benjamin Geebelen. Daylight availability prediction in the early stafes of the building design process. PhD thesis, K.U.Leuven, Dept. ASRO, Belgium, 2003.

[GHJV95]

E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns, Elements of Reusable Object-Oriented Software. AddisonWesley, 1995.

[Gie88]

Wim Gielingh. General AEC reference model (GARM) an aid for the integration of application specific product definition models. In Per Christiansson and Henry Karlsson, editors, Conceptual Modelling of Buildings, Papers from CIB W75+W78 workshop, pages 165–178, Lund, Sweden, Oct 1988. CIB.

[GM06]

L.F G¨ ul and M.L. Maher. Studying Design Collaboration in DesignWorld: An Augmented 3D Virtual World. In E. Banissi, M. Sarfraz, M.L. Huang, and Q. Wu, editors, Proceedings of 3rd International Conference on Computer Graphics, Imagining and Visualization Techniques and Applications (CGIV06), pages 471– 476. IEEE Computer Society, 2006.

[GN00]

Emden R. Gansner and Stephen C. North. An open graph visualization system and its applications to software engineering. Software — Practice and Experience, 30(11):1203–1233, 2000.

[Gol06]

H. Edward Goldberg. AEC from the Ground Up—IFCs in Action. http://aec.cadalyst.com/aec/article/articleDetail.jsp?id= 306852 , 2 2006.

[Gra04]

Ralph Grabowski. An Outside Look in at IntelliCAD. http://www.intellicad.org/WorldMeeting2004/presentations/ OutsideLookAtIntelliCAD.pdf , sep 2004.

396

BIBLIOGRAPHY

[Gra06a]

Ralph Grabowski. upFront.eZine. http://www.upfrontezine.com , 2006.

[Gra06b]

Ralph Grabowski. WorldCAD Access. http://worldcadaccess. typepad.com , 2006.

[Gra06c]

Graphisoft Website. http://www.graphisoft.com , 2006.

[GvN05]

Benjamin Geebelen, M. van der Voorden, and Herman Neuckermans. Fast and accurate simulation of long-term daylight availability using the radiosity method. Lighting Research and Technology, 37(4):295–321, Dec 2005.

[Hav05]

Sven Havemann. Generative Mesh Modeling. PhD thesis, Universit¨ at Braunschweig (Germany), Nov 2005.

[HC02]

Jie-Eun Hwang and Jin-Win Choi. SpaceCore: Metadata for Retrieving Spatial Information in Architecture. In Thresholds— Design, Research, Education and Practice, in the Space Between the Physical and the Virtual, Proceedings of the 2002 Annual Conference of the Association for Computer Aided Design In Architecture, pages 197–215, Pomona (California) USA, Oct 2002. ACADIA.

[Hen00]

Ann Hendricx. A Core Object Model for Architectural Design. PhD thesis, K.U.Leuven, Dept. ASRO, Belgium, 2000.

[HHK+ 07]

Susan Hert, Michael Hoffmann, Lutz Kettner, Sylvain Pion, and Michael Seel. An adaptable and extensible geometry kernel. Computational Geometry, 38:16–36, 2007.

[HN00]

A. Heylighen and H. Neuckermans. DYNAMO: A Dynamic Architectural Memory On-line. Journal of Educational Technology and Society, 3(2), Apr 2000.

[HN03]

A. Heylighen and H. Neuckermans. (Learning from Experience)2 —Promises, Problems and Side-effects of CaseBased Reasoning in Architectural Design. International Journal of Architectural Computing, 1(1):60–71, Jun 2003.

[HW98]

Paul Harmon and Mark Watson. Understanding UML, The Developer’s Guide. Morgan kaufmann, 1998.

[Int06]

International Alliance for Interoperability. iai-international.org , 2006.

[JL95]

Richard Junge and Thomas Liebich. New Generation CAD in an Integrated Design Environment: A Path towards Multi-Agent Collaboration. In Milton Tan and Robert Teh, editors, Sixth International Conference on Computer-Aided Architectural Design Futures, pages 277–290, Singapore, Sep 1995. CAADFutures.

http://www.

BIBLIOGRAPHY

397

[JL04]

Roland Juchmes and Pierre Leclercq. Esquise-sma: un syst`eme multi-agents pour l’interpr´etation d’esquisses architecturales. In IHM 2004: Proceedings of the 16th conference on Association Francophone d’Interaction Homme-Machine, pages 179–180, New York, NY, USA, 2004. ACM Press.

[JWS99]

T. Jozen, L. Wang, and T. Sasada. Sketch VRML - 3D Modeling of Conception. In Architectural Computing from Turing to 2000, eCAADe Conference Proceedings, pages 557–563, Liverpool (UK), Sep 1999.

[Kaf98]

D. Kafura. Object-Oriented Software Design and Construction with C++. Prentice-Hall, 1998.

[Kal89]

Yehuda E. Kalay. The Hybrid Edge : A Topological Data Structure for Vertically Integrated Geometric Modeling. Computer Aided Design, 21:129–139, Apr 1989.

[Kep01]

Frederik Keppens. Grafisch Interactieve Invoer voor Kosten- en Kwaliteitsevaluatie. Master’s thesis, K.U.Leuven, Dept. ASRO, Belgium, 2001.

[Khe06]

Lachmi Khemlani. AECbytes. http://www.aecbytes.com , 2006.

[Koc06]

David Koch. Architect’s Desktop. blogspot.com , 2006.

[Kur98]

D. Kurmann. Sculptor - How to Design Space. In T. Sasada et al, editor, CAADRIA 1998 Proceedings, pages 317–325, Osaka (Japan), Apr 1998.

[Lai06]

Jerry Laiserin. TheLAISERINLetter. http://www.laiserin.com , 2006.

[Lam94]

Leslie Lamport. LATEX, A Document Preparation System. nd Addison-Wesley, 2 edition, 1994.

[Lan06]

Geoffrey Moore Langdon. Architectural CADD Consultants. http://www.architecturalcadd.com , 2006.

[Lar00]

Kent Larson. Louis I. Kahn: Unbuilt Masterworks. The Monacelli Press, Inc., New York, USA, 2000.

[Lee01]

Kim Lee. Inside 3ds max 4. New Riders Press, 2001.

[Lip93]

Stanley B. Lippman. Leerboek C++. Addison-Wesley Nederland, dutch edition, 1993.

[Llo03]

Noel Llopis. C++ for Game Programmers. Game Development Series. Charles River Media Inc., 2003.

[Loo00]

Bart Lootsma. Superdutch - De tweede Moderniteit van de Nederlandse Architectuur. SUN, Nijmegen, 2000.

http://architects-desktop.

398

BIBLIOGRAPHY

[LS98]

Greg Ward Larson and Rob Shakespeare. Rendering with Radiance: The Art and Science of Lighting Visualization. Morgan Kaufmann, 1998.

[Mae99]

George Maestri. [digital] Character Animation 2 : Essential Techniques. [digital] Series. New Riders, 1999.

[Mae02]

George Maestri. [digital] Character Animation 2 : Advanced Techniques. [digital] Series. New Riders, 2002.

[Mar00]

R. Martin. Design Principles & Design Patterns. Technical report, http://www.objectmentor.com , 2000.

[MBG+ 06]

M.L. Maher, Z. Bilda, L.F. G¨ ul, D. Marchant, and H. Yinghsiu. Comparing Distance Collaborative Designing Using Digital Ink Sketching and 3D Models in Virtual Environments. In K. Brown, K. Hampson, and P. Brandon, editors, Clients Driving Construction Innovation: Moving Ideas into Practice, pages 133–143, Brisbane: Cooperative Research Centre for Construction Innovation, 2006. Icon.Net Pty Ltd.

[MC94]

William John Mitchell and Malcolm Mac Cullough. Digital Design Media. John Wiley and Sons, second edition, 1994.

[Mey97]

S. Meyers. Effective C++. Addison-Wesley, 1997.

[MP02]

Bob Martens and Herbert Peter. Developing Systematics Regarding Virtual Reconstruction of Synagogues. In Thresholds— Design, Research, Education and Practice, in the Space Between the Physical and the Virtual, Proceedings of the 2002 Annual Conference of the Association for Computer Aided Design In Architecture, pages 349–356, Pomona (California) USA, Oct 2002. ACADIA.

[MP03]

Katja Malfliet and Ward Poelmans. Het koppelen van de semantische en de grafische component van ontwerpentiteiten op het niveau masterplan. Master’s thesis, K.U.Leuven, Dept. ASRO, Belgium, 2003.

[MP04]

Bob Martens and Herbert Peter. ArchiCAD Best Practice: The Virtual Building Revealed. Springer Architecture, 2004.

[MS96]

D. Musser and A. Saini. STL Tutorial and Reference Guide, C++ Programming with the Standard Template Library. AddisonWesley, 1996.

[MT06]

Bob Martens and Ziga Turk. CumInCAD. http://cumincad.scix. net , 2006.

[NC00]

David Nicholson-Cole. The GDL Cookbook. Marmelade Graphics, Nottingham (UK), 3d edition, Dec 2000.

[Nei04]

Neil Leach et al. digital tectonics. WILEY-ACADEMY, 2004.

BIBLIOGRAPHY

399

[Neu92]

Herman Neuckermans. A conceptual model for CAAD. Automation in Construction, 1(1):1–6, 1992.

[New06]

Randall S. Newton. AECnews.com. http://www.aecnews.com , 2006.

[OG96]

Oscar Riera Ojeda and Lucas H. Guerra. Hyper-Realistic Computer Generated Architectural Renderings. NIPPAN, 1996.

[Ope06]

Open Design Alliance. http://www.opendesign.com , 2006.

[OS03]

J.-Y. Oh and W. Stuerzlinger. Intelligent Manipulation Techniques for Conceptual 3D Design. In Human Computer Interaction: Interact ’03, pages 319–326. IFIP & IOS Press, Sep 2003. ISBN 158603363-8.

[OS05]

J.-Y. Oh and W. Stuerzlinger. Moving Objects with 2D Input Devices in CAD Systems and Desktop Virtual Environments. In Inkpen, van de Panne, and AK Peters, editors, Graphics Interface 2005, pages 195–202, May 2005. ISSN 0713-5424.

[Owe93]

Jon Owen. STEP - An Introduction. Information Geometers, 1993.

[PAdVvW05] Sviataslau Pranovich, H.H. Achten, Bauke de Vries, and J. van Wijk. Structural Sketcher - Representing and Applying WellStructured Graphic Representations in Early Design. International Journal of Architectural Computing, 3(1):75–91, 2005. [Pen03]

Hannu Pentill¨ a. Architectural-IT and Educational Curriculumns– A European Overview. International Journal of Architectural Computing, 1(1):102–111, Jun 2003.

[Pet96]

Charles Petzold. Programming Windows 95. Microsoft Press, 1996.

[PM01]

Yoav I. H. Parish and Pascal M¨ uller. Procedural Modeling of Cities. In Proceedings of the 28th annual conference on Computer Graphics and Interactive Techniques, pages 301–308. SIGGRAPH, ACM Press, 2001. ISBN 1-58113-374-X.

[Pow05]

Gavin Powell. Beginning Database Design. Programmer to Programmer. Wrox Press (John Wiley & Sons, Inc.), 2005.

[Pra04]

Sviataslau Pranovich. Structural Sketcher, A Tool for Supporting Architects in Early Design. PhD thesis, TUEindhoven, May 2004.

[Pro96]

Jeff Prosise. Programming with MFC for Windows 95. Microsoft Press, 1996.

[PT96]

Les A. Piegl and Wayne Tiller. The NURBS Book. SpringerVerlag, second edition, 1996.

[Rev06a]

Revit Website. http://www.autodesk.com/revit , 2006.

400

BIBLIOGRAPHY

[Rev06b]

Revit Wiki. http://www.tripleddesign.com/wiki/index.php/RB Main , 2006.

[Rev06c]

RevitCity. http://www.revitcity.com , 2006.

[RJC76]

A. Ray-Jones and D. Clegg. CI/SfB - Construction indexing Manual. RIBA Publications, London (UK), 1976.

[RPS05]

Juchmes R., Leclercq P., and Azar S. A Multi-Agent System for the Interpretation of Architectural Sketches. Computers and Graphics Journal, 29(5), 2005.

[Rul96]

Keith Rule. 3D Graphics File Formats, A programmer’s Reference. Addison-Wesley, 1996.

[RW73]

H. W. J. Rittel and M. M. Webber. Dilemmas in a general theory of planning. Policy Sciences, 4:155–169, 1973.

[Sab07]

Francis Sabu. Web Based Collaborative Architectural Practice Using a Fractal System. In Joachim Kieferle and Karen Ehlers, editors, Predicting the Future, Proceedings of the 25th eCAADe Conference, pages 727–734. eCAADe, Sep 2007.

[SDVD99]

Monique Snoeck, Guido Dedene, Maurice Verhelst, and AnneMarie Depuydt. Object-Oriented Enterprise Modelling with MERODE. Leuven University Press, Leuven (Belgium), 1999.

[SGB00]

J. Szuba, E. Grabska, and A. Borkowski. Graph visualisation in ArchiCAD. Application of Graph Transformations with Industrial Relevance, LNCS 1779, pages 241–246, 2000.

[SHC05]

Julian Smart, Kevin Hock, and Stefan Csomor. Cross-Platform GUI Programming with wxWidgets. Bruce Peren’s Open Source Series. Prentice Hall Professional Technical Reference, 2005.

[Shi96]

Naai-Jung Shih. A study of 2D- and 3D-oriented architectural drawing production methods. Automation in Construction, 5(4):273–283, 1996.

[SM99]

Georg Suter and Ardeshir Mahdavi. Performance-Inspired Building Representations for Computational Design. In Building Simulation 1999, Kyoto (Japan), Sep 1999. International Building Performance Simulation Association.

[SM04]

Todd Stauffer and Kirk McElhearn. Mastering Mac OS X. Mastering. SYBEX Inc., third edition, 2004.

[Smi06]

Susan Smith. AEC WEEKLY. http://www10.aeccafe.com/nbc/ articles/view weekly.php?previous issue=1 , 2006.

[SSB02]

J. Szuba, A. Sch¨ urr, and A. Borkowski. GraCAD Graph-Based Tool for Conceptual Design. In A. Corradini, H. Ehrig, H.-J. Kreowski, and G. Rozenberg, editors, First International Conference

BIBLIOGRAPHY

401

on Graph Transformation (ICGT 2002), volume 2005 of LNCS 2505, pages 363–377. Springer-Verlag, 2002. [ST03]

Mark Snoswell and Leonard Teo, editors. Expos´e 1 : Finest digital art in the known universe. Expos´e Series. Ballistic Publishing, Australia, first edition, 2003.

[Ste99]

Martijn Stellingwerff. SketchBoX. In Architectural Computing from Turing to 2000, eCAADe Conference Proceedings, pages 491–497, Liverpool (UK), Sep 1999. eCAADe. ISBN 0-95236875-7.

[Ste05]

Martijn Stellingwerff. virtual context. PhD thesis, TUDelft, Mar 2005.

[Str91]

Bjarne Stroustrup. The C++ Programming Language. AddisonWesley, 2nd edition, 1991.

[Ten06]

Tenlinks. http://www.tenlinks.com , 2006.

[TJ07]

Kostas Terzidis and Jan Jungclaus. Predicting the Future: Open Source CAAD? In Joachim Kieferle and Karen Ehlers, editors, Predicting the Future, Proceedings of the 25th eCAADe Conference, pages 815–819. eCAADe, Sep 2007.

[Tro01]

Frank De Troyer. Bouweconomie—Cursusnota’s Deel 1 en Deel 2. Course notes (in dutch), K.U.Leuven, Dept. ASRO, Heverlee, 2001.

[Van02]

Hans Van Laer. Ontwikkeling van een algoritme om automatisch ruimtes te detecteren. Master’s thesis, K.U.Leuven, Dept. ASRO, Belgium, 2002.

[WH05a]

Daniel Wade and Paul Hellard, editors. Elemental 2 : The World’s best Autodesk art. Elemental Series. Ballistic Publishing, Australia, first edition, 2005.

[WH05b]

Daniel Wade and Paul Hellard, editors. Expos´e 3 : Finest digital art in the known universe. Expos´e Series. Ballistic Publishing, Australia, first edition, 2005.

[Wit02]

Pieter Withouck. Toetsen van een gebouwmodel: Kostprijsberekening in de verschillende ontwerpstadia. Master’s thesis, K.U.Leuven, Dept. ASRO, Belgium, 2002.

[Woo96]

M. Woo. OpenGL Programming Guide, ARB. Addison-Wesley, 1996.

[WS04a]

Daniel Wade and Mark Snoswell, editors. Elemental : The World’s best Discreet art. Elemental Series. Ballistic Publishing, Australia, first edition, 2004.

402

BIBLIOGRAPHY

[WS04b]

Daniel Wade and Mark Snoswell, editors. ExposÂ´e 2 : Finest digital art in the known universe. ExposÂ´e Series. Ballistic Publishing, Australia, first edition, 2004.

[WTC98]

WTCB. Algemene Grafische Symbolen voor de Bouw. Rapport 3, WTCB, Brussels, Belgium, 1998. D/1998/0611/04.

[Yan03]

QZ. Yang. IFC-compliant Design Information Modeling and Sharing. ITcon, 8, 2003.

[Yan06]

Chris Yanchar. Between the Walls. http://blogs.autodesk.com/ adt , 2006.

[Zoo06]

Chris Zoog. Revitlution Blog. http://revitlution.blogspot.com , 2006.

Publications [BGN02] S. Boeykens, B. Geebelen, and H. Neuckermans. Design phase transitions in object-oriented modeling of architecture. In Connecting the Real and the Virtual - design e-ducation, 20th eCAADe Conference Proceedings, pages 310–313, Warsaw (Poland), Sep 2002. eCAADe. [BN03a] S. Boeykens and H. Neuckermans. Implementation of an Architectural Design Environment. The development of IDEA+. In E-activities in design and design education, 9th EuropIA International Conference, page 6, Istanbul (Turkey), Oct 2003. EIA. [BN03b] S. Boeykens and H. Neuckermans. Implementation Strategy for an Architectural Design Environment, Issues in the development of IDEA+. In Ghassan Aouad and Les Ruddock, editors, Connecting the Real and the Virtual - design e-ducation, 3rd International Postgraduate Research Conference in the Built and Human Environment, pages 761–771, ESAI Lisbon (Portugal), Apr 2003. University of Salford (UK). [BN05] Stefan Boeykens and Herman Neuckermans. Scale Level and Design Phase Transitions in a Digital Building Model. In Jos´e Pinto Duarte, Gon¸calo Ducla-Soares, and A. Zita Sampaio, editors, Digital Design: The Quest for New Paradigms, 23d eCAADe Conference Proceedings, pages 829–836, Lisbon (Portugal), Sep 2005. eCAADe. [BN06] Stefan Boeykens and Herman Neuckermans. Improving Design Workflow in Architectural Design Applications. International Journal of Architectural Computing, 4(4):1–19, Dec 2006. [BN07] Stefan Boeykens and Herman Neuckermans. A Generic Data Structure for an Architectural Design Application. In Joachim Kieferle and Karen Ehlers, editors, Predicting the Future, 25d eCAADe Conference Proceedings, pages 303–310, Frankfurt (Germany), Sep 2007. eCAADe. [Boe02] Stefan Boeykens. Design Phase Transitions in object-oriented modeling of architecture. Poster Presentation with abstract, Dec 2002. PhD. Symposium, Faculty of Engineering, K.U.Leuven. [Boe03] Stefan Boeykens. Implementation of an Architectural Design Environment with focus on transitions between different design phases and scale levels, and integration of evaluation tools. Presentation, Mar 2003. Doctoral Seminar, CAAD, Design and Building Methodology, K.U.Leuven. 403

404

Chapter 20. Publications

[Boe05] Stefan Boeykens. Integrated Design Environment for Architecture. Poster Presentation with abstract, Apr 2005. PhD. Symposium, Faculty of Engineering, K.U.Leuven. [Boe06] Stefan Boeykens. Improving Design Workflow in Architectural Design Applications. Presentation, Jun 2006. Doctoral Seminar, CAAD, Design and Building Methodology, K.U.Leuven. [NGB05] H. Neuckermans, B. Geebelen, and S. Boeykens. Virtual Engineering in Architectural Design. In Nagib Callaos and William Lesso, editors, WMSCI 2005, volume III of The 9th World Multi-Conference on Systemics, Cybernetics and Informatics, pages 36â&#x20AC;&#x201C;40, Orlando (Florida) USA, Jul 2005. ISBN:980-6560-55-8.

Curriculum Vitae Stefan Boeykens (16 augustus 1973) is een ingenieur-architect uit Leuven. Hij studeerde af voor ingenieur-architect aan de K.U.Leuven in 1996. Hierna werd nog een kort wetenschappelijk project uitgewerkt, in het verlengde van de thesis, onder supervisie van professor Frank De Troyer. Na de studies ging hij in 1997 als zelfstandig architect aan de slag bij de bureaus Pascal Van Dooren (Merchtem), Jan Florizoone (Leuven) en Cerulus & Desmedt (Leuven). Tijdens deze periode werd de stage afgewerkt, terwijl hij ondertussen ook werkte aan enkele kleinere projecten onder eigen naam. In deze periode werd ervaring opgedaan met diverse bouwdossiers voor verbouwingen en nieuwbouw, van ontwerp en bouwaanvraag tot werfopvolging, inclusief presentaties en visualisaties. In de diverse bureaus werden ook het computersysteem en de werkmethodes aangepakt. Eind 2000 werd hij ingeschakeld in een onderzoeksproject aan de onderzoeksgroep Ontwerp- & Bouwmethodiek, onder toezicht van professor Herman Neuckermans. Dit vormde de aanzet voor het doctoraatsonderzoek rond digitale gebouwmodellering. Stefan is getrouwd en heeft drie kinderen. Zijn eigen interesses gaan uit naar 3D visualisatie, muziek spelen en componeren en grafisch ontwerp. Hij heeft uitgebreide ervaring met een breed gamma aan computer-applicaties voor Computer Aided Design, 3D modellering en animatie, programmering, webontwikkeling, grafisch ontwerp en Desktop Publishing maar evenzeer voor multimedia toepassingen met audio, video en beeld en dit op verschillende computerplatformen.

405

Part IV

Appendices

407

CAD & 3D Database During the course of this research, a database of design applications has been elaborated. An extract from this database is displayed here, for reference purposes. A selection of CAD applications, which might be of interest to architects, is displayed. For each application, a short description, accompanied with references to functionality and availability is shown. The following extract only displays applications which are categorized as Building Information Modeling solutions. However, the full database covers a much wider selection of applications.

409

410

Appendix . CAD & 3D Database Table 2: Extracted list of BIM Applications

Software 2D 3D BIM Viz 5D Presenter NO NO NO NO From TenLinks Press Release: “The new 5D Presenter features tighter integration with Cost Manager and Control, and an overall enhanced performance. It also displays the projected cash flow based on estimate and schedule defined in Estimator 2007 and Control 2007.” Commercial http://www.vicosoftware.com/products Allplan YES YES YES NO BIM solution from Nemetschek. Exists in different prices (with a great difference in functionality). Powerful modelling tools, complex to use. Commercial — Windows http://www.nemetschek.com ARC+ YES YES YES NO Architectural CAD. The plans and sections are generated from the 3Dmodel but are not cross-linked to the model like some other CAAD-tools. Commercial — Windows http://www.arc-techno.com/products/2K5 1st.php ARC+ Premium3 YES YES NO NO See ARC+ Commercial — Windows http://www.arc-techno.com/products/premium3.php ArchiCAD YES YES YES YES Virtual Building - Very complete cross-platform architectural CAD-tool. The GDL-language forms the base for library-objects and all geometry generation. Version 8 was a (partial) rewrite and introduced Solid Modelling with construction history. Version 9 included LightWorks Rendering and many productivity improvements. Version 10 merged PlotMaker into the main application and cleaned up the interface. It also introduced slanted elements and walls over multiple stories. For real freeform modeling, MaxonForm is available (based on Cinema4D) or SketchUp models can be imported. Version 11 adds Virtual Trace and many smaller improvements to aid the conversion from 2D to BIM. Some of the longer standing issues with the BIM model still stand. Continued on next page

411 Software 2D 3D BIM Viz Commercial — Windows MacOS http://www.graphisoft.com/products/archicad ArchiCAD Startedition YES YES YES YES Information about this version is hard to find and it is unclear in which markets it is made available. Could be a cheap way to begin with ArchiCAD, though. Commercial — Windows MacOS ArchiFM YES YES YES YES Discontinued Facility Management solution. Did not penetrate outside of the UK and Sweden. Was never marketed world wide. Commercial — Windows ArchiTECH.PC YES YES YES YES Architectural CAD. Was once based on the ArchiCAD-kernel but developed in its own way. Somehow a bit more cumbersome and limited, but they also have one model where you can generate views and sections. When you need to work in the sections, you disconnect the section from the model, so it becomes a 2D-linedrawing. Commercial — Windows http://www.softcad.com ArchiTECH.PC Lite-Color YES YES YES YES Everything from ArchiTECH.PC, except anti-aliasing, terrain import, 3D Hatching, Bill Of Materials, Animation and limited to 256-color rendering. Commercial — Windows http://www.softcad.com ArchiTECH.PC Lite-List YES YES YES NO Everything from ArchiTECH.PC, except anti-aliasing, terrain import, 3D Hatching, Animation and Rendering. Commercial — Windows http://www.softcad.com Architrion YES YES YES NO Does it still exist? The webpage is last updated in 1997, that’s prehistoric! A part of Architrion seems to have emerged into BOA. Still contained a promising toolset (ACIS solids, rendering, ?) Commercial — MacOS http://www.architrion.co.uk ARCHline XP YES YES YES NO Architectural BIM application, which seems to be inspired by ArchiCAD? Student version available. Commercial — Windows http://www.archlinexp.cc Continued on next page

412

Appendix . CAD & 3D Database

Software 2D 3D BIM Viz Arcon YES YES YES YES 3D Architectural CAD tool from Germany. Rather cheap but looks very usable. Commercial — Windows http://www.arcon-software.com Arkey YES YES NO YES Strange but effective dutch Architectural CAD. Still has its DOS-like interface and some rather cryptic concepts, but works very efficient because of its hierarchical library system. Updates are very seldomly seen lately and users are in doubt if this company will succeed in keeping the software alive. Commercial — Windows http://www.arkey.nl/ARKEY.htm ARRIS Studio YES YES YES YES ARRIS Studio is ARRIS CAD + the collection of all plugins. Commercial — Windows Linux http://www.arriscad.com AutoCAD Architecture YES YES YES YES AutoCAD + Architectural module. From massing model to presentation and construction drawings. Still too limited to produce technically correct sections. Raytracing, Radiosity and Animation courtesy of the included VIZ Render (based on VIZ/3ds max) Since 2007 rebranded as “Architecture”. The VIZ Render module has been removed, as Mental Ray is integrated into AutoCAD. Commercial — Windows http://www.autodesk.com/architecturaldesktop AutoCAD MEP YES YES YES YES Special version of Autodesk Architectural Desktop, for engineering (AEC but also HVAC and structural). Formerly known as Autodesk Building Systems? Commercial — Windows http://www.autodesk.com/buildingsystems Bentley Architecture YES YES YES YES BIM, using Triforma as parametric modeling platform. The complete solidmodel of the building is used to generate sections, construction drawings (more or less) and also the bill of materials and the quantity calculations. Using Microstation as a base, it is a very powerful modeler. Trivia: Triforma was originally developped in Belgium by Brics, but bought by Bentley to form the core for their Architecture platform. Continued on next page

413 Software 2D 3D BIM Viz Commercial — Windows http://www.bentley.com/architecture BOA YES YES YES NO Promises a very intuitive architectural solid-modeller with cross-linked sections and 2D-plans. Has some inheritance from Architrion, but not clear if this application is still in active development? Commercial — Windows MacOS Bricscad Architecturals YES YES YES YES Module for IntelliCAD or AutoCAD. Creating a 3D Building Model with intelligent behaviour. Commercial — Windows Linux http://www.bricscad.com Chief Architect YES YES YES YES 2D/3D architectural application (CAAD) including rendering and quantity calculations Commercial — Windows http://www.chiefarchitect.com Chief Architect Base YES YES YES YES 2D/3D architectural application (CAAD) including rendering and quantity calculations Limitations compared to the full version: no library editing, no 3D-import/export, no DWG, no VRML, limited libraries Commercial — Windows http://www.chiefarchitect.com Constructor YES YES YES YES Including ArchiCAD and Estimator. A construction-targeted bundle of ArchiCAD and cost estimating and site planning tools. 5D-building, as they like to call it. Based on technology Graphisoft had acquired/licensed from a specialized simulation company. From TenLinks Press Release: “The new version of Constructor is based on award-winning Archicad 10, which introduces new functionality that increases modeling freedom and productivity. The software also includes performance enhancements such as improved integration with Graphisoft Control. Constructor includes the new MEP Modeler, a full mechanical, electrical cable tray and plumbing modeling module. The MEP Modeler is accurate and easy to use, and contains a detailed library of duct, pipe, fittings and equipment with standard sizes. Duct routes are automatically delimited by the components available from the specification library.” Continued on next page

414

Appendix . CAD & 3D Database

Software 2D 3D BIM Viz Commercial — Windows http://www.vicosoftware.com Control NO NO NO NO From TenLinks Press Release: “Control 2007 features a more transparent visualization of Critical Path Method links and calculations, a powerful new dependency engine and schedule optimization tools. The software links to traditional scheduling tools, including MS Project, Primavera and PowerProject. In addition, Control 2007 features improved connections to 5D Presenter to display model objects that are late, or at risk of being late.” Commercial http://www.vicosoftware.com Cost Manager NO NO NO NO From TenLinks Press Release: “Cost Manager 2007 is a new product which aids both visual and detailed cost analysis. It enables visual presentations on estimating information for client purposes, and it visually compares one version of the estimate to another one, or to the target costs. The software also performs target cost analysis on the overall project and individual systems with full drill-down capabilities for accessing the detailed cost breakdown information. The software allows users to import estimating information from MS Excel or Estimator 2007, and connects to 5D Presenter. Cost Manager 2007 is designed as a standalone and independent product.” Commercial http://www.vicosoftware.com Domus.CAD Pro YES YES NO NO 3D Architectural CAD-tool for MAC (Windows version in beta). Promises an excellent mix of features, like interactive, realtime walkthroughs and full 3D-control (sections, perspectives, ...). Rendering is done using plugins for external software. Not really OpenGL, but uses Apple Quickdraw3D (which is less used these days) to generate realtime views. Commercial — Windows MacOS http://www.interstudio.net/DomusCadE.html Estimator YES YES YES YES Sits between ArchiCAD and Constructor. An ArchiCAD version with a dedicated pricing estimation module integrated. More targeted at construction companies than at architects, since it requires a different approach to the building model From TenLinks Press Release: “Estimator 2007 now supports Bid Package functionality, including defining, receiving and awarding packages. Awarded bid packages override estimated unit costs in the reports. In addition, Model Versions, published from Constructor, are now logged and maintained in Estimator, allowing users to see when a version was published and if or when it was imported into the estimate. Categories and content are now easier to read thanks to banded cost reports: categories and cost items are shown with a specific color which makes it easier to recognize and interpret the cost report.” Continued on next page

415 Software Commercial — Windows

BIM

Viz

FINE YES YES NO NO Product suite of advanced electromechanical engineering tools, based on AutoCAD or IntelliCAD. * FineHVAC = integrated environment for HVAC design * FineSANI = integrated environment for SANITARY design * FineELEC = integrated environment for ELECTRICAL design * FineLIFT = integrated environment for ELEVATOR design Commercial — Windows IDEA YES YES YES YES From the website: “IDEA is the IntelliCAD based BIM solution for Architectural Building Design, covering all the range of the Architectural needs (model creation, rendering and virtual walkthrough), within a high productivity, user friendly, environment. IDEA introduces new standards in the AEC industry, as it proposes an effective and powerful BIM approach, based on the IntelliCAD engine, offering practically the interface expected by any AutoCAD or IntelliCAD user.”WalkIDEA and PhotoIDEA are extensions (included) for visualization (renderings and walkthroughs) Commercial — Windows http://www.4msa.com/products/idea.htm ideCAD YES YES YES YES Architectural and structural design, with collaboration between different partners. Commercial — Windows http://www.idecad.com Revit Architecture YES YES YES YES Parametric Builder for Architecture. It is evolving fast and has quite some potential. Includes Accurender as a rendering engine. Revit relies on the “change-engine”where connections are layed out between objects and maintained during the changes in the design. After the Autodesk aquisition, a lot of things happened, but the software is gaining momentum and users and surpasses Architectural Desktop in functionality (not in user-base). After the full support of IFC and the addition of an API, this is one of the best BIM tools on the market. Continued on next page

416

Appendix . CAD & 3D Database

Software 2D 3D BIM Viz Commercial — Windows http://www.autodesk.com/revitbuilding Revit Structure YES YES YES YES Structural Engineering version of Revit Commercial — Windows http://www.autodesk.com/revitstructure SmartArchitect YES YES YES NO Similar to Autodesk Architectural Desktop, but based on AutoCAD LT Commercial — Windows http://www.drcauto.com Speedikon YES YES YES NO Architectural CAD (also available for AutoCAD + Microstation). Claims to make a virtual building model, but in practice it is said to be rather cumbersome to generate estimations with it. Commercial — Windows http://www.bentley.com/architecture STAR YES YES YES NO STAR focuses more on GIS and urban planning, but there is (was?) an Architecture-solution as well. Commercial — Windows Linux VectorWorks Architecture YES YES YES YES VectorWorsk + architecture-module and translated in Dutch (for Flanders and Netherlands). This is a major reworked version with a lot of added functionality for architects. They also developed versions for electricity, for interior design, for mechanical design and for landscape design. Commercial — Windows MacOS http://www.design-express.be

IDEA+ File format Instead of using the different classes as tags in the XML-syntax, generic tags are defined, as shown in Table 3, covering basic data types and only a small subset of entity classes. All specific class names and attributes are applied as attributes with the generic tags, with the property values as the field values. This drastically reduces the amount of tags to cover in the importer and exporter routines. This small set of tags does not change when new classes are added to the data structure or when new properties are registered. Table 3: Tags in the IDEA+ file format

TAG IDEA CBASE

CRCHANDLER

BASEVAR EXTENDEDVAR PROP

CONTAINER

IDEA+ XML Format Tags Attributes Description <none> Root tag, to identify possible IDEA+ files classname Used to create an instance from the factory. id Temporary but unique ID, used by references. <none> If already referenced elsewhere, only the ID is repeated as value. Otherwise, the full set of properties is added as child tags. <none> List of basic properties <none> List of extended properties type Property Type. Data type (double, integer, string, Boolean) or Object type (base, CRCHandler, container) name Property Name (as registered) type Vector, List or other (using STL) elementType Expected type inside list (e.g. CRCHandler) size Amount of elements in list

With this set of tags, any combination of objects and their properties can be described. There are additional concerns, however. The serialization of a projectâ&#x20AC;&#x2122;s data is specific for the current release of the application. There are currently no 417

418

Appendix . IDEA+ File format

features to support different format revisions. Introducing new properties will generate files that are not readable in older versions of the software. This is something that should be solved in a possible future public release. An excerpt from an IDEA+ file is displayed in the following listing. <?xml version="1.0" standalone="no" ?> <IDEA> <CBASE classname="Project" id="68"> <BASEVAR> <PROP type="container" name="activities"> <CONTAINER type="vector" elementType="CRCHandler" size="1"> <CRCHANDLER> <CBASE classname="Activity" id="39"> <BASEVAR> <PROP type="integer" name="BB/SfB Maintable">1</PROP> <PROP type="string" name="BB/SfB code"></PROP> <PROP type="base" name="Display Color"> <CBASE classname="Color" id="40"> <BASEVAR> <PROP type="double" name="blue">+0.50</PROP> <PROP type="double" name="green">+0.50</PROP> <PROP type="integer" name="id">40</PROP> <PROP type="double" name="red">+0.50</PROP> </BASEVAR> <EXTENDEDVAR /> </CBASE> </PROP> <PROP type="string" name="Name">Default Activity</PROP> <PROP type="integer" name="Required amount of people">0</PROP> <PROP type="double" name="Required area">+0.00</PROP> <PROP type="double" name="Required volume">+0.00</PROP> <PROP type="integer" name="id">39</PROP> </BASEVAR> <EXTENDEDVAR /> </CBASE> </CRCHANDLER> </CONTAINER> </PROP> <PROP type="container" name="compositions"> ... </PROP> <PROP type="container" name="elements"> <CONTAINER type="vector" elementType="CRCHandler" size="2"> <CRCHANDLER> <CBASE classname="Element" id="98"> <BASEVAR> <PROP type="integer" name="BB/SfB Maintable">1</PROP> <PROP type="string" name="BB/SfB code"></PROP> <PROP type="container" name="CAADEntities"> <CONTAINER type="vector" elementType="CRCHandler" size="1"> <CRCHANDLER> <CBASE classname="PhysicalElement" id="94"> <BASEVAR> <PROP type="enum" name="Agent">Architect</PROP> <PROP type="integer" name="BB/SfB Maintable">1</PROP> <PROP type="string" name="BB/SfB code"></PROP> <PROP type="integer" name="Building Phase">1</PROP> <PROP type="enum" name="CAAD Phase">Phase01</PROP> <PROP type="enum" name="CAAD State">Existing</PROP> <PROP type="string" name="Name">CAAD 94</PROP> ... <PROP type="CRCHandler" name="Type"> <CBASE classname="Column" id="97"> <BASEVAR> <PROP type="CRCHandler" name="Composition">63</PROP> <PROP type="double" name="Length">+0.30</PROP> <PROP type="container" name="Reference Points"> <CONTAINER type="vector" elementType="CRCHandler" size="1"> <CRCHANDLER>

419

<CBASE classname="ReferencePoint" id="91"> <BASEVAR> <PROP type="CRCHandler" name="RefHeight"> <CBASE classname="ReferenceHeight" id="92"> <BASEVAR> <PROP type="integer" name="id">92</PROP> <PROP type="double" name="z">+0.00</PROP> </BASEVAR> <EXTENDEDVAR /> </CBASE> </PROP> <PROP type="integer" name="id">91</PROP> <PROP type="double" name="x">+0.00</PROP> <PROP type="double" name="y">+0.00</PROP> </BASEVAR> <EXTENDEDVAR /> </CBASE> </CRCHANDLER> </CONTAINER> </PROP> <PROP type="double" name="height">+3.0</PROP> <PROP type="bool" name="height absolute">true</PROP> <PROP type="integer" name="id">97</PROP> <PROP type="bool" name="m_bCircular">false</PROP> <PROP type="double" name="width">+0.30</PROP> </BASEVAR> <EXTENDEDVAR /> </CBASE> </PROP> <PROP type="CRCHandler" name="child dependence link" /> <PROP type="integer" name="id">94</PROP> <PROP type="CRCHandler" name="parent dependence link" /> <PROP type="container" name="representation links"> <CONTAINER type="vector" elementType="CRCHandler" size="2"> <CRCHANDLER> <CBASE classname="RepresentationLink" id="3877"> <BASEVAR> <PROP type="integer" name="id">3877</PROP> </BASEVAR> <EXTENDEDVAR /> </CBASE> </CRCHANDLER> <CRCHANDLER> <CBASE classname="RepresentationLink" id="3880"> <BASEVAR> <PROP type="integer" name="id">3880</PROP> </BASEVAR> <EXTENDEDVAR /> </CBASE> </CRCHANDLER> </CONTAINER> </PROP> <PROP type="bool" name="visible">true</PROP> </BASEVAR> <EXTENDEDVAR /> </CBASE> </CRCHANDLER> </CONTAINER> </PROP> <PROP type="string" name="Name">Element 93</PROP> <PROP type="integer" name="id">98</PROP> </BASEVAR> <EXTENDEDVAR /> </CBASE> </CRCHANDLER> ... </CONTAINER> </PROP> ... <PROP type="integer" name="id">68</PROP> <PROP type="container" name="materials">

420

Appendix . IDEA+ File format

... </PROP> <PROP type="container" name="project links"> <CONTAINER type="vector" elementType="CRCHandler" size="1"> <CRCHANDLER> <CBASE classname="PropertyLink" id="510"> <BASEVAR> <PROP type="integer" name="id">510</PROP> <PROP type="string" name="name">posY</PROP> </BASEVAR> <EXTENDEDVAR> <PROP type="CRCHandler" name="baseObj 1">299</PROP> <PROP type="CRCHandler" name="baseObj 2">91</PROP> <PROP type="bool" name="masterBool 1">true</PROP> <PROP type="bool" name="masterBool 2">true</PROP> <PROP type="string" name="propName 1">y</PROP> <PROP type="string" name="propName 2">y</PROP> </EXTENDEDVAR> </CBASE> </CRCHANDLER> </CONTAINER> </PROP> <PROP type="container" name="reference points"> <CONTAINER type="vector" elementType="CRCHandler" size="2"> <CRCHANDLER>91</CRCHANDLER> <CRCHANDLER>299</CRCHANDLER> </CONTAINER> </PROP> <PROP type="container" name="representations"> <CONTAINER type="vector" elementType="CRCHandler" size="2"> <CRCHANDLER> <CBASE classname="Representation" id="72"> <BASEVAR> <PROP type="integer" name="BB/SfB Maintable">1</PROP> <PROP type="string" name="BB/SfB code"></PROP> <PROP type="integer" name="Building Phase">2</PROP> <PROP type="integer" name="Building Stage">1</PROP> <PROP type="integer" name="Design Phase">0</PROP> <PROP type="integer" name="Display Scale">100</PROP> <PROP type="string" name="Name">3D View</PROP> <PROP type="integer" name="Scale Level">2</PROP> <PROP type="integer" name="View Type">1</PROP> <PROP type="integer" name="id">72</PROP> </BASEVAR> <EXTENDEDVAR /> </CBASE> </CRCHANDLER> ... </CONTAINER> </PROP> </BASEVAR> <EXTENDEDVAR /> </CBASE> </IDEA>

Index 2.5D, xvii, 15, 357 3DS, 101, 103, 107, 108, 247 3DXML, 101 4D, xvii, 8, 34 5D, xvii, 8

Base Properties, 282, 336 BB/SfB, xvii, 131, 140, 181, 202, 251, 277, 287, 298, 304 Bentley, 34 Generative Components, 59, 68 MicroStation, 9, 10, 28, 59, 98, AccuRender, 28 137 ACIS, 6, 7, 15, 17, 81, 100, 160, 372 BIM, xvii, xxxix, 4, 15, 30, 33, 37, 58, Action, 320, 322 104, 114, 123, 129, 135, 143, Activity, 131, 223, 233, 284, 289, 290, 144, 172, 175, 190, 236, 264, 292, 294, 295, 318, 340 286, 302, 337, 359, 381, 385 Adobe, 89 Blender, 78, 334 Acrobat, 101 BOM, xvii, 176, 177 AEC, xvii, 8, 35, 36, 87, 90, 144, 190 bottom-up design, 185, 189, 195, 319 AJAX, xvii, 32 BricsCAD, 14, 36, 207 Alias, 8, 88, 103 CAAD, xvii, 58, 112, 123 Alibre, 82 CAAD Entity, 129, 284 API, xvii, 81, 337, 368, 388 Grid, 133, 296 Arkey, 138 Masterplan Element, 219, 293 Arup, 62 Physical Element, 287 assembly, 12, 19, 52, 58, 164, 170 Space, 221, 287 Autodesk, 5, 10, 88 Space Assembly, 291 3ds max, 3, 29, 85, 103, 134, 217, User-Defined Entity, 297 266, 309, 364, 385 ADT, 28, 35, 98, 135, 138, 144, CAD, xvii, xxxix, 3, 4, 28, 37, 76, 91, 92, 97, 98, 112, 143, 156, 160, 190, 201, 202, 243, 254, 288, 201, 247, 337, 359, 361, 382, 295 385 Architectural Studio, 48 CAM, xvii, 5 AutoCAD, 9, 10, 36, 86, 98, 336 CATIA, 5, 21, 53, 56, 94 AutoLisp, 385 cell, 327 Impression, 47 CG, xvii, 21 Inventor, 88 Classification Information, 201 Lightscape, 22 Maya, 21, 68, 79, 88, 94, 103, 170, collada, 104 Command, 345, 346, 349, 376 217, 309, 356, 385 Revit, 28, 37, 55, 88, 136, 139, Command History, 346 155, 192, 207, 255, 288, 296, compositing, 68 Composition, 131, 132, 302 309 Conceptual Element, 130 VIZ, 29 constraint, 52 AVID CORENET ePlanCheck, 42 Softimage, 68, 87 CSG, xvii, 5 Axis, 198 421

422 DCC, xvii, 9, 15, 25, 65, 78, 92, 103, 108, 112, 300 Dependence Link, 214, 308, 322 DESI-III, 76 Design Phase, 116, 185, 193, 277, 298, 313, 324, 325, 331, 332 Construction Design, 184 Preliminary Design, 184 Sketch Design, 116, 183, 187, 212, 234, 269, 312, 313, 331, 340 DGN, 98, 107 Digital Project, 56 dimension driven design, 255 Direct3D, xvii, 26, 363 drag-and-drop, 253 DTP, xvii, 8, 89, 94, 103 DWF, xvii, 9, 31â&#x20AC;&#x201C;33, 38, 102, 106 DWG, xvii, 36, 58, 81, 98, 107, 108, 138, 219, 382 DXF, 98, 100, 107, 108, 138 DYNAMO, xvii, 388

INDEX ArchiCAD, 28, 35, 101, 135, 151, 191, 204, 256, 288, 295 GDL, 35, 101, 151, 191, 256, 299 MaxonForm, 18, 50 GUI, xviii, 4, 113, 165, 254, 278, 301, 337, 349, 368, 379 GUID, xviii Hole, 306 HOOPS, 101, 369, 371, 372 HMF, 100 HSF, 100 Houdini, 68 HVAC, xviii, 87, 157 IDEA+, xviii, 128, 242, 275 IFC, xviii, 39, 90, 104, 107, 115, 123, 128, 201, 219, 247, 249, 382 IGES, 5, 100 Imaginary Boundary Link, 215, 224, 231 IntelliCAD, 36, 81, 86 ISO, xviii, 104, 123, 139, 201

ERP, xviii expression, 260, 353 JTOpen, 102 Extended Properties, 241, 282, 298, 336 Factory, 301, 340, 349, 417 FAQ, xviii, 76 FBX, 103 FEA, xviii feature, 52 Filter, 320 floor level, 134 FM, xviii, 185 Foster & Partners, 62 FreeCAD, 77 GDL, xviii Gehry, Frank O., 55, 94 Genometri GenoForm, 62 GIS, xviii GNU, xviii, 76 GPL, xviii, 76, 370 GPU, xviii, 9, 25, 28 Granite, 372 Graphical Entity, 129 Graphisoft

Kahn, Louis I., 22 KPF, 62 layer priority, 325 layers, 9, 16, 98, 137, 142, 147, 152, 201, 251 LightWorks, 28 links, 214 Macro Command, 349 Macromedia, 89 manipulators, 112, 253, 343 Material, 131 material, 22, 26, 30, 68, 103, 110, 130, 131, 147, 149, 158, 169, 179, 194, 217, 241, 247, 267, 280, 302, 313, 325, 364, 388 matrix, 163, 264, 278, 282, 298, 327, 328, 353, 377 Maxon Cinema4D, 6, 18, 50, 79, 87, 163, 167, 263, 334, 356 MCAD, xviii, 12, 19, 50, 58, 76, 82, 88

INDEX McNeel Rhino, 17, 21, 50, 91, 94, 160, 253, 263, 266 MEP, xviii, 35, 37 MERODE, xviii, xli, 119, 362 Microsoft, 87 Direct3D, see Direct3D MFC, xviii, 281, 367, 368 Visual Basic, 81, 105, 243, 386 Moment of Inspiration, 50

423 Project, 129 Property Connection, 216, 260, 308 Property System, 169, 241, 249, 275, 279, 299, 303, 304, 321, 336, 340, 352, 354, 361, 382 Qt, 339, 370, 372, 380, 382

radiosity, 22 RCHandler, 279, 351 Reference, 197, 234 Reference Counting, 279, 313, 347, 351 Nemetschek, 87 VectorWorks, 7, 15, 28, 87, 88, 138, Reference Height, 323 Reference Line, 197 376, 381 NURBS, xviii, 5, 15, 16, 20, 39, 50, Reference Point, 189, 197, 199, 215, 237, 258, 291, 300, 305, 322, 160, 263, 266, 297, 307, 357, 326, 330, 332, 343, 344, 349, 359, 390 358, 375, 385 Reference Volume, 197 OBJ, 101, 103, 108, 247 RenderMan, 23, 68, 241, 339 Object Event Table, 346 Representation, 131 Object Link, 215, 309 Rule, 320 ODA, xviii, 86, 98 OOP, xviii, xli, 77, 275, 277, 359, 361– RuleSet, 320 364, 368, 369 SALOME, 78 OpenCASCADE, 77, 369 OpenGL, xviii, 7, 26, 28, 161, 363, 365, SAT, 100 Scale Level, 118, 133, 149, 182, 185, 368, 369 195, 199, 215, 277, 298, 311, 313, 319, 322, 332, 378 Parameter Expression, 217, 309 Block, 118, 182 Parasolid, 6, 15, 160, 372 Masterplan, 118, 170, 182, 293 part, 52 Space, 118, 182, 290 PDF, xviii, 9, 38, 85, 89, 101–103, 106, scenegraph, 248, 278, 298, 311, 358, 153 363, 367, 369, 372 PDM, xviii, 7 SDK, xix, 368, 386 Physical Boundary Link, 215 SGI Physical Contact Link, 215 IRIX, 367 Physical Element, 130, 131, 169, 193, Open Inventor, 367, 369 215, 217, 285, 286, 302, 306, Shaderman, 68 318, 320, 350, 352 Shared Entity, 131 Physical Element Type, 131 Planar Element, 169, 193, 195, 202, SideFX Houdini, 62, 79, 172, 356 209, 215, 218, 224, 234, 237, Simulation, 40 243, 269, 287, 290, 297, 303, Sketch Design, 112 306, 320, 324, 328, 358 SketchUp, 8, 17, 29, 34, 46, 50, 75, PLE, xix, 79 84, 89, 94, 113, 134, 170, 231, PLM, xix, 7, 102 257, 263, 356, 381 POV-Ray, 247 SmartGeometry, 59, 62 PowerSHAPE, 82 Solibri, 42, 200, 332

424 SolidWorks, 28, 62 Space Assembly, 223, 292 Space Boundary Link, 224 SQL, xix, 250, 353, 383 STEP, 104 STL, 107, 280, 362 Style, 132 surface, 137 top-down design, 185, 189, 195, 215, 218, 225, 319 tree, 16, 165, 168, 248, 279, 302, 333, 336, 376, 377 Type, 302 U3D, 101 UML, xix, 320 Visio, 86, 99 VRML, xix, 65, 103, 107, 247, 249 winged edge, 215 Wright, F.L., 27 WRL, see VRML X3D, 103 XML, xix, 32, 101, 106, 171, 248â&#x20AC;&#x201C;250, 252, 299, 338, 361, 372, 379, 383, 390, 417 XVL, 101

INDEX