GenerativeDesignforBuildingInformationModelingweb.ist.utl.pt/antonio.menezes.leitao/ADA/documents/...GChasseveralwaysofuserinteraction,taking...

Generative Design for Building InformationModeling

Bruno Ferreira1, António Leitão21,2INESC-ID/Instituto Superior Té[email protected]@ist.utl.pt

Generative Design (GD) is a programming-based approach for Architecture thatis becoming increasingly popular amongst architects. However, most GenerativeDesign approaches were thought for traditional Computer Aided Design (CAD)tools and are not adequate for the Building Information Modeling (BIM)paradigm. This paper proposes a solution that extends GD to be used with BIMapplications while preserving and taking advantage of its ideas. The solution willbe evaluated by developing a connection between Revit, a well-known BIM tool,and Rosetta, a programming environment for GD, and by implementing thenecessary programming language features that allows GD to be used in thecontext of BIM tool.

Keywords: Generative Design, BIM, Revit, Rosetta, Racket, ProgrammingLanguages

INTRODUCTIONComputer Aided Design (CAD) applications in-creased the efficiency of design activities and al-lowed architects to produce more accurate andprecise drawings that could be more easily editedwithout the need of manually erasing and redrawingparts of the original design.

Nevertheless, modeling complex and creativegeometry can still be a challenge in a CAD tool andchanging the model continues to present some diffi-culties as the degree of flexibility provided by thesetools is not sufficient. Generative Design (GD) is usedas a solution to these problems (McCormack et al.2004).

GD can be described as form creation throughalgorithms (Terdizis 2003). This approach allows thegenerationof different solutions just by changing theconstraints and the requirements implemented in a

givenprogram. Theseprogramscan include complexalgorithms that generate geometry that is very diffi-cult to create by manual means.

Recognising the advantages of theGDapproach,many toolswere developed that allow the creation ofGDprograms. These toolswere also tailored for archi-tects with basic programming experience, reducingthe programming skills needed to use them.

Rosetta is one of those tools. It provides a pro-gramming environment for GD, allowing the devel-opment of scripts using different programming lan-guages. These scripts can then be used to generatemodels in different CAD tools.

Nowadays, Building Information Model (BIM)tools are replacing the traditional CAD tools. Firstly,because they offer a set of features that go beyondCAD, and, secondly, because many governments aremaking the use of BIM obligatory in projects.

BIM - Early Design - Volume 1 - eCAADe 33 | 635

Unfortunately, tools like Rosettawere developedfor CAD applications, and thus, are not adequate forthe BIM paradigm.

This happens because CAD tools only deal withgeometry while BIM objects are far more than that.They are definedby theparametric rules they containas well as by their properties like materials, finishes,manufacturer specifications and even price.

These properties allow BIM tools to detect prob-lems in the design, such as a pipe that is placed in thesame location as a window. The parametric rules al-low the object to adapt to its usage when inserted ina project.

Finally, all the information about the project lifecycle is stored in theseobjects andcanbeused to cre-ate documents related to fabrication, cost estimationand even building management.

CAD tools do not require this information butBIM does. This fact alone changes the way users in-teract with BIM and also changes how GD programshave to bewritten. GD tools that only work with CADtoolsmust allowall these features inorder to commu-nicate with a BIM tool but most of them do not havethe proper support for that.

Developing a GD program for BIM is a problemthat exists nowadays and the solution offered by BIMtools, like Revit, is an Application Programming Inter-face (API). The API provides a way to use BIM witha programming approach. Unfortunately, the useof the API requires knowledge of programming lan-guages, like C# or C++, and computer science con-cepts, such as transactions andpolymorphism,whichassumes considerable programming experience.

The objective of this paper is to present a solu-tion that allows novice programmers towriteGDpro-grams for BIM applications.

RELATEDWORKSeveral tools were analysed to guide us in the devel-opment of our solution. The main focus was on toolsthat allow users to write GD programs for BIM appli-cations. This includes tools that are already availablein BIM applications as well as plug-ins developed for

the same purpose.

Grasshopper 3D and LyrebirdGrasshopper 3D is a graphical programming lan-guage developed for architects as a plug-in forRhinoceros 3D CAD.

Programs written in this language represent adata flow graph that consists of a group of compo-nents and the connections between them. Thesecomponents can be selected from a series of menusand dragged to the working environment. The com-ponents can represent functions, parameters or evengeometry and they are connected with lines. This al-lows the users to create complex algorithms by com-bining components with the connectors.

It is important to notice that the components arenot the onlyway touseGrasshopper's functionalities.They can also be extendedby using scripting compo-nents to write code using VB.NET, C# or Python pro-gramming languages (Payne and Issa 2009).

Because it is a graphical language, Grasshopperis easier to learn and start using, which made it pop-ular amongst architects. However, the graphical as-pect of the language is also a disadvantage because,as programs grow, the amount of connections be-tween components makes the program difficult tounderstand and even features such as sliders stopworking as intended due to performance issues. Fig-ure 1 shows a complex program that illustrates theproblems mentioned.

Figure 1An example of acomplex parametricmodel inGrasshopper.Retrieved from [3]on June 2015.

636 | eCAADe 33 - BIM - Early Design - Volume 1

AlthoughGrasshopper was designed to be used onlywith Rhinoceros, it can also be extended with plug-ins. This feature allowed the development of plug-ins, such as Lyrebird, that made possible the usage ofthe language with other applications, including BIMtools.

Lyrebird is a plug-in developed by LMN Archi-tects as an interoperability tool between Grasshop-per 3D and Revit. This plug-in enables the usage ofGrasshopper to structure the information needed toproduce the desiredmodel in Revit. This informationis then used to identify and instanciate the correctfamilies with the correct rules and parameters.

As a result, Lyrebird is more focused on sendingthe correct data between the applications, instead oftranslating the geometry between them [1]. There isonlyonecomponenton theGrasshopper side that re-ceives the information and then sends it to the Revitside. There, a command is selected to add a new ob-ject or manage an existing one.

For example, to create a column, a line is usedas input. Next, on the output of the component, thefamily to use in Revit is specified. On the Revit side,the information is received and the user confirms thecreation of the new element. A column of the speci-fied family is then created, using the line as input. Theline is used as abstract information that, combinedwith the family of the BIM object, allows the creationof the actual object.

DesignScriptDesignScript is a programming language that isheavily influenced by design principles. It was cre-ated by Robert Aish to be, not only a productionmodeling tool, but also a full-fledged programminglanguage and a pedagogical tool (Aish 2012).

As a programming language, DesignScript isseen as an associative language as it maintains agraph of dependencies between the variables usedin a program. Any change in one of the variablesis propagated throughout the program. This meansthat if we have a variable a, and if b is defined as a +1, a change in awill also modify the value of b. This is

a change-propagationmechanism, similar to the up-date mechanisms available in associative CAD tools.The language is also a domain-specific language as itcontains primitives for design and geometry.

As a modeling tool, DesignScript tries to intro-duce concepts that are easily understood by usersthat are not accustomed to design with the help of aprogramming language. This is achieved by allowingthe developers to use its logical framework in orderto produce the design models, and also facilitatingan exploratory approach to the tool involving refac-toring of the produced models (Aish 2012).

Finally, DesignScript aims to be a pedagogicaltool, as it allows the evolution of the programmingskills of its users. Users unfamiliar with programmingare able to use a direct approach with a graph nodediagramming interface that is simple and requires lit-tle to no understanding of programming concepts(Aish 2013). Figure 2 shows a program created withthe graph approach. However, as their design be-comes more complex, users might feel the need tolearn more advanced programming concepts. Thenode-to-code functionality of DesignScript allows atransition between the graph representation and ascript that initially presents a logic very similar to theoriginal graph. For users that desire to producemorecomplex programs, this scriptmight be changed intoa normal script.

Figure 2An example of aprogram created inDesignScript.Retrieved from [4]on December 2014.


DynamoDynamo is a plug-in for Revit that is strongly influ-enced by graphical programming languages such asGrasshopper for Rhino.

Just as Grasshopper, users create a workflow byintroducing nodes that are connected to each otherthrough wires associated with the ports that eachnode contains. A port from an element can onlybe connected to another port of a matching type.Thismeans that the input and output portmust havecompatible types.

Nodes can represent several Revit elements,such as lines, or functions, such as mathematicalfunctions. Users can also define custom nodes in or-der to extend the functionality provided by Dynamo.

Figure 3 shows a programwritten with Dynamonodes and its result.

Dynamo also supports the use of code blocks,which are elements containing small scripts writtenin a textual programming language, such as Python.These code blocks allow the creation of small algo-rithms that introduce more complex functionalitiesthat are not possible to create with the other nodes.

Geometric Description LanguageGeometric Description Language (GDL) is a paramet-ric programming language for ArchiCAD that allowsthe creation of scripts that describe objects, whichare called library parts.

This language, similar to BASIC, requires thedefinition of several scripts that include the modeldescription and the parameters of the new object(Nicholson-Cole 2004).

Each object is describedwith a sequence of com-mands that describe its geometry. In similarity toOpenGL, a matrix stack implements transformationslike translations, rotations and scales. The transfor-mations currently in the stack when creating a shapeare the ones that are going to influence it.

Figure 4 shows a program written in GDL. Theeditor shows the sequence of commands that pro-duces the result, visible on the top left corner of theimage.

Figure 3A program writtenwith Dynamo andits result. Retrievedfrom [5] onDecember 2014.

Figure 4A GDL program thatcreates a bedcanopy. Retrievedfrom [6] on May2015.

However, GDL only allows the creation of simple ge-ometry and does not take advantage of the BIM func-tionalities of ArchiCAD.

GenerativeComponentsGenerativeComponents (GC) is a parametric and as-sociative system developed for Bentley's Microsta-tion.

This system is propagation-based so the user hasto determine the rules, relationships and parametersthat define the desired geometry. This propagation-based system consists of an acyclic directed graphthat is generated by two algorithms: one that is re-sponsible for ordering the graph and the other thatpropagates values through it (Aish and Woodbury2005).


GC has several ways of user interaction, takinginto consideration his skills. The first one is a Graph-ical User Interface (GUI) that allows direct manipula-tion of geometry. The second one is by defining re-lationships among objects with simple scripts in GC-Script. The third and final one, is by writing programsin C#, allowing the definition of complex algorithms.

GC shows that a graphical language might beeasier to learn but as the user wants to producemorecomplex models, he will start to produce scripts in atextual programming language.

GENERATIVE DESIGN FOR BIMMost of the tools analysed in the previous sectionshave disadvantages. The major one is the fact thatthey are associated with a specific application. Theprograms created with them are not portable, whichis something that wewant to solve with our solution.

Another disadvantage is the programming lan-guage that they use. Lyrebird and Dynamo, for ex-ample, primarily use Graphical Programming Lan-guages. These languages, although easy to learn, donot scale well with the program complexity.

A Textual Programming Language is more flexi-ble butmight introduce a barrier for newcomers. Thechosen languagemust be easy to learn and fit for be-ginners. GC, for example, usesC#which is a very com-plex language, and GDL uses a language similar toBASIC which is obsolete. This is something that weaddress in our approach.

In the following subsections our proposed solu-tion is described. It aims to give an approach thatallows users to write portable GD programs for BIMtools.

The primary components of the solution are anIntegrated Development Environment (IDE), an ab-straction layer anda communication component. Wewill now discuss these components.

Integrated Development EnvironmentOur solution uses a programmatic approach basedon textual programming languages since they aremore flexible and scale betterwith the programcom-

plexity. For this reason users need an editor in whichthey write their code.

The language of the editor must be fit for a be-ginner. For example, the Python language is verypopular and is being used to teach beginners howto program. Also, languages like Python have anIDE that help users write and debug their programs.These features are very important for beginners sincethey have difficulties writing their first programs andthese IDEs help them overcome some initial barriers.

Abstraction LayerTowrite GD programs, users need functions that giveaccess to BIM functionality. These functions must al-low users to instantiate BIM objects and define all theinformation needed in order to produce an accurateproject.

For example, to produce a wall with a door in it,theremust be a function that createswalls. This func-tion might receive the height, length, position andthe type of wall in order to create the correct BIM ob-ject. Then, a function that creates the door is usedand it must receive, not only the position, height andtype of door but also the wall that will serve as hostof this object.

In addition to this, to indicate positions and cre-ate lines and arcs, abstractions for these concepts areneeded as well as functions that allow their creationand usage.

All these functions as well as others that createand manipulate BIM objects are included in an ab-straction layer, so that they can be used in all sup-ported BIM tools.

However, some features are unique to certainBIM tools, so we will offer them as functions that willbe available only to that specific BIM. The user canchoose to use them, giving up the portability of theirprograms, but gaining the ability to take advantageof the specific features the tool has to offer.

BIM CommunicationFinally, in order to execute the user programs andgenerate the result in the desired BIM tool, a compo-nent that communicates with the tool is needed.


Since most of the BIM tools have an API that ex-poses their features in a programatic way, this com-ponent can be a plug-in for the tools writtenwith theaid of that API.

All the functions of the abstraction layer have acorrespondent one in this component. When one ofthem is used, the needed information is sent to thiscomponent and then the correspondent function isexecuted. Taking advantage of the API, these func-tions will then produce their results in the BIM tool.

Figure 5 shows all the components of our solu-tion and how they are related.

EVALUATIONIn this section, we perform an evaluation of our so-lution resorting to an implementation that uses Re-vit. This implementation takes advantage of Rosettaand Revit connecting the two of them and introduc-ing the latter as a new back-end for Rosetta.

Rosetta Programming EnvironmentRosetta already has a development environment de-signed for beginners and provides many conceptsthat architects already use on a day to day basis.

By using Rosetta, users are able to choose thelanguage in which they want to program. Racket,Python, Javascript and Processing are some exam-ples of languages that are already available. This

helps users to overcome the need of learning a newprogramming language if they already know onethat is available. If they have yet to learn how toprogram they can choose any of the languages avail-able since most of them are pedagogical languages.The Rosetta IDE also supports debugging and syntaxhighlighting for all the languages available as front-ends.

Also, by using Rosetta, we can take advan-tage of many functionalities without the need of re-implementing them. One example are the coordi-nate systems.

Of course, in order to add a BIM, such as Revit,as a back-end, new functions and abstractions mustbe created in Rosetta since the current ones were de-veloped for CAD tools. These new functions and ab-stractions must be included in an abstraction layerexplained in the following section.

Abstraction LayerThis layer contains all the functions and abstractionsthat can be used to produce results in BIMs, in thiscase Revit. All these were created taking into consid-eration the way architects do their work in order tofacilitate their understanding and usage when writ-ing their programs.

Since Revit can produce Project and Family doc-uments, we created different functions that can beused in each one.

Figure 5Overview of thearchitecture of thesolution.


For Family documents, we have functions thatcreate simple geometry. These functions are verysimilar to the ones available for CAD tools in Rosetta.This allows users to port some of their algorithms di-rectly to the new back-end and produce their com-plex geometry in it. This geometry can then be usedto define new families and family instances that canbe used in Project files.

Figure 6 shows a program that was originallywritten for a CAD, now being used with Revit. To dothis we simply re-implemented the geometry func-tions to work with BIM tools.

The functions and abstractions for Project filesare where the main differences between BIM andCAD are felt. In these files the user creates instancesof families and uses them to develop their project. Sothese are BIM objects and not simple geometry.

To have BIM objects, concepts like walls, doorsand windows must be introduced. Also, the func-tions thatdealwith these concepts aredefined takinginto consideration how these objects are created bythe user in the graphical interface. To create a simple

wall, for example, the user draws a line between twopoints and awall of the selected type is created alongthat line. So, the function that creates thewall is usedin a similar manner, receiving points that define theline where the wall will be created.

Another significant difference between the CADand BIM tools is the restrictions and the relationshipsbetween objects. When creating a wall with a door,we know that they are related because of their place-ment. In a CAD tool, the door is placed in a positionwhere the wall is but they are not related. When cre-ating the GD program for CAD tools, we use restric-tions that make everything fit in the right place butthese restrictions are only in the code and not in thegenerated model. In BIM tools these relationshipsare present in the generated objects. For example,a door cannot be createdwithout a host. A wall mustbe given as a host and the BIM tool will create andmodify the necessary properties for the door to fitperfectly.

So all the operations take this into account andrequire all the elements necessary to create these re-

Figure 6A truss generated inRevit with a GDprogram.


lationships. To create a floor the user must indicatein which level it will be placed. To create a door, hemust say in which wall it will be hosted.

Figure 7 shows a script on the left that creates atower with slabs and columns to support them. Theresult in Revit can be seen on the right side of the im-age.

This example uses functions included in the ab-straction layer that create BIM objects. The levels arecreated with the height specified by the user. Afterthat, the floors are created in those levels with a func-tion that creates round slabs taking into account thecenter of the slab and a radius. Finally, the columnsare created in a specified position and their height isdetermined by the two levels indicated by the user.The first level is where the base of the column is andthe other is on the top.

As seen in the example, all these functions have avisual result in Revit. In order to achieve this, Rosettamust comunicate with the desired BIM tool and sendall the information that is necessary to produce themodel. All the information is serialized using Google

Protocol Buffers and transmitted to the BIM tool viasockets. This guarantees that all information is sentin a format that can be easily reconstructed on theother side. There, the information is used in a plug-inthatwas developed for Revit, whichwewill explain indetail in the following section.

Revit Plug-InThe plug-in was created using the RevitAPI madeavailable by Revit. This plug-in communicates withRosetta in order to receive all the information neededto create the objects.

This plug-in is written in C# and was developedusing the Microsoft Visual Studio programming en-vironment. The abstraction layer previously men-tioned was developed to hide the complexity of theAPI.

All the functions in Rosetta have a correspon-dent one in the plug-in and these are the ones thatcommunicate directly with the BIM and create allthe needed elements. In order to produce theseelements, the information received from Rosetta

Figure 7A tower generatedwith BIM objectswith a GD program.


must be read from the socket and deserialized withthe Protocol Buffers to reconstruct the information.Then, this information is used as parameters for theAPI functions that create theobjects in theBIM. Thesefunctions return an identifier that is serialized andsent to Rosetta allowing the user to reference thoseobjects in the future.

To create a more explorative interaction, thisplug-in is non-blocking which means that Revit willnot block while the user is executing his program.This means that it is possible to interact with Revitwhile the program is running, for example, to seethe results using a different perspective. However,this comes with a penalty in performance. If the userwishes better performance, a blocking mode can beused that does not allow to interact with Revit untilthe program finishes.

An important feature provided by Rosetta is theRead-Eval-Print-Loop (REPL). This is an interactivewindow visible in the bottom left of Figure 6, wherethe user can test functions and see the results in theBIM without the need of writing another script. TheREPL receives the user input, evaluates it and showsthe result to the user, then becoming ready to receiveanother input. If the user wants to see how a certainfunction works with a specific parameter, he can usethe REPL and quickly see if the function behaves ashe expects.

CONCLUSIONSThe GD approach created for CAD applicationsproved very useful but nowadays these tools are be-ing replaced with BIM. This paradigm is very differ-ent from CAD, so the approach originally created nolonger fits.

To solve this problemwe propose a solution thatallows users to create GD programs with a set of ab-stractions designed for BIM tools. Our solution ex-tends Rosetta, a IDE for GD. By taking advantage ofRosetta, users have a development environment fitfor the needs of beginners. Due to the many front-ends available, users can pick the programming lan-guage they prefer. Also, since the abstraction layer

we implemented takes into consideration genericBIM concepts and not the concepts that are exclusiveof a given tool, we expect that users will be able tocreate portable programs that explore different BIMtools.

We are currently evaluating our solution with a agroupof architects that are alsonoviceprogrammers.In futureworkweplan to expand this solution addingmore functionality to the BIM abstraction layer. Also,we plan to support aditional BIM back-ends such astheArchiCADback-end,which is alreadybeingdevel-oped.

ACKNOWLEDGEMENTSThis work was partially supported by national fundsthrough Fundação para a Ciência e a Tecnolo-gia (FCT) with reference UID/CEC/50021/2013, andby the Rosetta project under contract PTDC/ATP-AQI/5224/2012.

REFERENCESAish, R. 2012 'DesignScript: origins, explanation, illus-

tration.', Computational Design Modelling, SpringerBerlin Heidelberg, pp. 1-8

Aish, R. 2013 'DesignScript: Scalable Tools for DesignComputation', eCAADe 2013: Computation and Per-formance–Proceedings of the 31st International Con-ference on Education and research in Computer AidedArchitectural Design, Delft, The Netherlands, pp. 18-20

Aish, R. andWoodbury, R. 2005 'Multi-level interaction inparametric design', Smart Graphics, Springer BerlinHeidelberg, pp. 151-162

Azhar, S., Hein, M. and Sketo, B. 2008 'Building Infor-mation Modeling: Benefits, Risks and Challenges',Proceedings of the 44th ASC National Conference,Auburn, Alabama, USA

Eastman, C., Teicholz, P., Sacks, R. and Liston, K. 2008, BIMHandbook: A Guide to Building InformationModelingfor Owners, Managers, Designers, Engineers and Con-tractors, John Wiley & Sons, Hoboken, New Jersey

Ibrahim, M., Krawczyk, R. and Schipporeit, G. 2004, 'TwoApproaches to BIM: A comparative study', eCAADeConference, 22, pp. 610-616

Leitão, A., Santos, L. and Fernandes, R. 2014 'Pushing theEnvelope: Stretching the Limits of Generative De-


sign', Blucher Design Proceedings, pp. 235-238Lopes, J. and Leitão, A. 2011 'Portable Generative Design

for CAD Applications', Proceedings of the 31st annualconference of the Association for Computer Aided De-sign in Architecture, pp. 196-203

McCormack, J., Dorin, A. and Innocent, T. 2004 'Gener-ative design: a paradigm for design research', Pro-ceedings of Futureground, Design Research Society,Melbourne

Nicholson-Cole, D. 2004, Introduction to Object Makingwith Archicad: GDL for Beginners, Graphisoft R&D

Payne, A. and Issa, R. 2009, The grasshopper primer. Zen‘Edition, Robert McNeeI & Associates

Terzidis, K. 2003, Expressive form: a conceptual approachto computational design, Spon Press, London andNew York

[1] http://lmnts.lmnarchitects.com/bim/superb-lyrebird/

[2] http://dynamobim.com/learn/[3] https://11arch461.files.wordpress.com/2011/10/d

ef_extent.jpg[4] http://through-the-interface.typepad.com/.a/6a0

0d83452464869e20192ac16a8d2970d- pi[5] http://inthefold.autodesk.com/.a/6a017c3334c51a

970b019b01bc21de970c-pi[6] http://helpcenter.graphisoft.com/guides/archica

d-18-int-reference-guide/user-interface-reference/dialog-boxes/gdl-geometric-description-language/gdl-object-editor/


GenerativeDesignforBuildingInformationModelingweb.ist.utl.pt/antonio.menezes.leitao/ADA/documents/...GChasseveralwaysofuserinteraction,taking...

Documents

Transcript of GenerativeDesignforBuildingInformationModelingweb.ist.utl.pt/antonio.menezes.leitao/ADA/documents/...GChasseveralwaysofuserinteraction,taking...