Conference PaperPDF Available

'GHShot': a collaborative and distributed visual version control for Grasshopper parametric programming

Authors:

Abstract and Figures

When working with parametric models, architects typically focus on using rather structuring them (Woodbury, 2010). As a result, increasing design complexity typically means a convoluted parametric model, amplifying known problems: `hard to understand, modify, share and reuse' (Smith 2007; Davis 2011). This practice is in contrast with conventional software-programming where programmers are known to meticulously document and structure their code with versioning tool. In this paper, we argue that versioning tools could help to manage parametric modelling complexity, as it has been showing with software counterparts. Four key features of version control: committing, differentiating, branching, and merging, and how they could be implemented in a parametric design practice are discussed. Initial user test sessions with 5 student designers using GHShot Grasshopper version control plugin (Cristie and Joyce 2018, 2017) revealed that the plugin is useful to record and overview design progression, share model, and provide a fallback mechanism.
Content may be subject to copyright.
‘GHShot’: a collaborative and distributed visual version
control for Grasshopper parametric programming
Verina Cristie1, Sam Conrad Joyce2
1,2Singapore University of Technology and Design
1verina_cristie@mymail.sutd.edu.sg 2sam_joyce@sutd.edu.sg
When working with parametric models, architects typically focus on using rather
structuring them (Woodbury, 2010). As a result, increasing design complexity
typically means a convoluted parametric model, amplifying known problems:
`hard to understand, modify, share and reuse' (Smith 2007; Davis 2011). This
practice is in contrast with conventional software-programming where
programmers are known to meticulously document and structure their code with
versioning tool. In this paper, we argue that versioning tools could help to
manage parametric modelling complexity, as it has been showing with software
counterparts. Four key features of version control: committing, differentiating,
branching, and merging, and how they could be implemented in a parametric
design practice are discussed. Initial user test sessions with 5 student designers
using GHShot Grasshopper version control plugin (Cristie and Joyce 2018,
2017) revealed that the plugin is useful to record and overview design
progression, share model, and provide a fallback mechanism.
Keywords: Version Control, Parametric Design, Collaborative Design, Design
Exploration
INTRODUCTION
The field of architecture is traditionally interdisci-
plinary and has adopted many technologies; from
new materials in the industrial age, to software and
algorithmic approaches in the digital era. CAD sys-
tems were first proposed in 1960s; and to further
manipulate geometries, associative parametric pro-
gramming was introduced in 1990s. This graph-
based interface was popularised by tools such as
Generative Components, Grasshopper, and Dynamo,
where instead of using conventional text-based pro-
gramming, visual programming is used.
Parametric modelling and software develop-
ment bear similarities, particularly in their work-
flow and development cycle. Code produces soft-
ware, while parametric modelling produces geom-
etry. Hence, manipulating code results in change
in software output, much like manipulating param-
eter and links between component results in change
in geometry. Both software and parametric models
are developed through iteration cycles. Modern soft-
ware development practices ‘Agile’ method (Huo et.
al, 2004) where code is developed in iterative cycle of
building and testing; a parallel to an iterative process
of design solution generation and evaluation.
Design - ALGORITHMIC AND PARAMETRIC 3 - Volume 3 - eCAADe 37 / SIGraDi 23 |35
Complexity in Software Development and
Parametric Modelling
With the rise in use and complexity in programming,
similar challenges have been faced managing this in
both fields: software code reached millions of lines,
and equally parametric models to many hundreds
of components and thousands of links in commer-
cial projects. Tangled links or ‘spaghetti’ paramet-
ric model (see Fig. 1) is a classic example of unman-
ageable models (Davis et. al, 2011). Large paramet-
ric models are often inflexible (simple change often
breaks models); model’s changes are often not eas-
ily found/detectable, and model reuse and sharing
problematic (Smith, 2007).
Cheaper and more powerful computers in the
1960s allowed for wider use of software, and larger
more complex software requirements, driving the
software industry into the so-called ’software crisis’
(Dijkstra, 1972). Software crisis is identified as incom-
plete and degrading software performance due to
unmaintainable software complexity (Valdez, 1988).
The most popular case was the decade long IBM 360
Operating System development between 1960 and
1970 that resulted in a multi-million-dollar project
overrun; the reaction to which catalysed a structured
transformation of the software development process
to software engineering (Brooks, 1995). Key good
practices resulting were object-oriented program-
ming (OOP) and source code control system (SCCS)
(Rochkind, 1972) were both developed during this
period of time. Both of which will be further dis-
cussed in later parts of this paper, but these com-
bined user-best-practices and technical solutions re-
sulted in the ubiquitous software development ap-
proach we have today; where it is not uncommon to
have tens to even thousands of people collaborating
on code bases millions of lines long to build scalable
complex software projects from the ’80s onwards.
However, in architecture, this structured usage focus
has been mainly on CAD or BIM model complexity
and only recently has parametric modelling begun
to exhibit acute issues in similar ways. For example,
in March 2019, Autograph[1] plugin was released to
help automatic arrangements of objects in Grasshop-
per canvas, signifying growing complexity in para-
metric modelling. A thread in Grasshopper forum [2]
in April 2018 showed large grasshopper files design-
ers generate, ranging from 1000 to even 20,000 com-
ponents. Hence, there is a growing critical drive to
start looking into adopting not only the technologies
in software design, but also the good practices of the
software development process to parametric design.
Figure 1
Grasshopper model
with 1,234
components
(Picture credit:
Lukasz Domagala)
Adoption of Object-Oriented Programming
(OOP)
In OOP practice, programming complexity is reduced
by splitting up code into functional reusable man-
ageable pieces called ‘objects’; i.e.: to encapsulate
data and functions that operate on it into mod-
ules. Modularity and encapsulation are two princi-
ples of OOP. Which uses nouns to explain compo-
nents/data, and verbs to explain function action. This
makes it clearer what is happening within code; re-
ducing mental overhead whilst programming. Davis
(2013) recommended parametric models to adopt
this modularity to address inflexibility. An inflex-
ible parametric model breaks or needs substantial
remodelling even for minor changes, as lack of hi-
erarchy and separation of variables and functions
means a lot of interconnected networks. By parti-
tioning parametric models into separate logical ele-
ments according to their functions, models are eas-
ier to understand, edit, and reuse; even as design
develops, especially in the case of later contributors.
Pena (2014), further emphasized that with separa-
36 |eCAADe 37 / SIGraDi 23 - Design - ALGORITHMIC AND PARAMETRIC 3 - Volume 3
tion of functionality, parametric models could use
internal and external code to communicate and ex-
tend the functionality of the model, much like the
use of different libraries in software. A recent exam-
ple of this OOP practice can be seen in a ‘distributed
data model’ (Wortmann and Tunçer, 2017) paradigm
used in the Morpheus Hotel project (Muscettola et
al, 2017), where the model was divided into hun-
dreds of parametric model and geometry files, of
which each is processed individually before combin-
ing them again, to manage its 1,668,301 different
parts of building structures and façade systems.
Next: Adoption of Version Control System?
Figure 2
Three generations
of code versioning
system: local
(locking) system
(left), centralised
system (middle),
and distributed
system (right).
While OOP practice has a growing adoption and
positive impact specifically in organised commer-
cial parametric modelling practice, SCCS (more com-
monly called version control systems) are so not well
known and even less so applied in parametric design
circles. In software development, version control is
now almost ubiquitously used to maintain different
versions of code and collaboration.
The fundamental concept of versioning revolves
around code saving (pushing) and code download-
ing (pulling) to and from a shared repository between
collaborators. There are three types of versioning sys-
tems (see Fig. 2): local (locking), centralised, and dis-
tributed. I n a locking system, many versions could be
created but only one user is allowed to access code at
a time (only one channel of push and pull). In a cen-
tralised system, everyone can pull code at any time,
but before pushing to the repository, one should al-
ways have the latest version. If currently user A and
user B are editing the same code, and user A pushes
his/her edit first, user B will need to first download
that edit before able to push his/her own edit. In this
manner, a single central latest version is alwaysmain-
tained. Lastly, in a distributed system, each machine
has a local repository and manages its own version-
ing of code. Users can make local checkpoints (‘com-
mits’) before sending (‘pushing’) them to the server,
and multiple files of the same version can exist. Users
only need to merge them when they choose to do so.
Locking system is the earliest versioning sys-
tem developed and in practice, it is rarely used as it
doesn’t allow collaborators to work in parallel. Aish
(2000) proposed centralised versioning system for
design in Bentley’s Digital Project (currently named
as Project Wise) as there is a need for a clear record
of action - who did what in the project. Compara-
bly, Burry and Holzer (2009) also implemented a cen-
tralised sharing system to allow ease of parametric
model sharing in Gehry Technologies. However, the
project had an issue with the binary file merging and
thus in its implementation, a locking system was used
instead. Both implementations, nevertheless, were
BIM-based, and more apt for the later stage of design;
and as such could not support creative process well.
PARAMETRIC MODEL VERSIONING
‘GHShot’ was developed to realise a distributed
versioning system for parametric modelling in
Grasshopper (Cristie and Joyce 2018, 2017). It con-
sists of (1) a custom Grasshopper component de-
veloped to allow users to send design progression
directly from their modelling environment, and (2) a
cloud repository to store the sent parametric models
and its attributes. This cloud server provides web-
page views for users and others to view and navi-
gate projects and designs, as well as give feedback
and download models. In the next part, common
practices in distributed versioning systems - namely
committing, branching, differentiating, and merging
code, and what these practices mean for parametric
modelling, and how it could be translated into para-
metric modelling practice will be further discussed.
Design - ALGORITHMIC AND PARAMETRIC 3 - Volume 3 - eCAADe 37 / SIGraDi 23 |37
Figure 3
Figure 3 - Code
versioning example
of a simple addition
program written by
two programmers.
User_A started by
writing code that
will take two
numbers and print
them (1). User_B
wrote add function
to add both
numbers by
branching the code
(2) and merge it
back (4). User_A
also modified part
of the code (3).
Action records are
historically tracked
(left).
Parametric Model Development Progres-
sion Capture (Committing)
In software versioning, when code is committed a
checkpoint is created, an internal ‘save as’ functional-
ity so that programmers don’t have to create a nam-
ing convention system/structure for each commit. In-
stead, the programmer creates a commit message,
which is a message describing the changes in the
current commit. This is helpful for the code owners
themselves and other programmers who look at the
code as they will be able to understand what inten-
tions are of the changes in that specific commit. Once
the code is committed, the owner then can push the
code to the server so that the code is saved in the
repository. By periodically pushing the changes all
collaborators who have access to the cloud can un-
derstand the progression of the code and pull to work
on their own versions based on someone else’s code.
In addition, should the code break in a way that can’t
be understood or fixed, a previous commit can be
pulled where the state of the code worked before and
developed from here.
Meanwhile, without a versioning system, gener-
ally files of different versions are maintained by mak-
ing copies and giving each file a different name. For
example, designers making modification to their de-
signs could name their Grasshopper files: file_1.gh,
file_2_v2.gh, file_3_finalfinal.gh, and so on. This ir-
regular naming convention failed to describe rela-
tionships between the files (e.g. how is file_1 related
to file_3_finalfinal?). On the other hand, while in a
typical BIM environment, files are strictly named -
coding everything from project code, level, location,
classification, etc (see Fig. 4), this system is unwieldy
and difficult to enforce in the early design stage. Ad-
ditionally, it also lacks visual representation of each
file that could represent the design progression bet-
ter. Temporal design versions per designers’ commit
are especially important to monitor design evolution,
identify individual contributions, and combine and
reuse concepts (Aish, 2000). Work by Sakai and Tsun-
oda (2015) demonstrated how a history tree can be
used to track collaborative house design progression
visually in 3D WebGL. This is a good starting point
towards a better design history documentation and
managing design complexity; despite the limitation
of 3D web-based geometry editor for producing de-
signs. GHShot expands on these ideas to bring a bet-
ter design versioning practice to the wider commu-
nity of parametric designers with the commonly used
Grasshopper.
Figure 4
BIM System naming
convention (Source:
[3])
GHShot implemented a distributed versioning sys-
38 |eCAADe 37 / SIGraDi 23 - Design - ALGORITHMIC AND PARAMETRIC 3 - Volume 3
tem as it is important for designers to work on their
own versions during exploration stage and not be
confined to the central master version. However, un-
like traditional distributed system that has both lo-
cal and cloud repository, local repository was not im-
plemented. Parametric modelling is mostly done on
a workstation connected to an online system unlike
programming’s remote work. Hence, commit and
push operations are combined into a save operation
on the GHShot Grasshopper component button. This
was also chosen remove overhead of designers hav-
ing to learn another local versioning system. Upon
clicking, the parametric model and its attributes will
be sent to the URL set and designers can immediately
see what they have just sent in the web. Users can
commit their designs at any relevant point during the
design progression, and other designers can down-
load the models and modify them. Designs commit-
ted are shown in a tree visualisation on the web so
that design progression can be traced.
Parametric Model Change Detection (Dif-
ferentiating)
In software versioning the ‘Diff’ (short for difference)
utility tool (Hunt and Mcllroy, 1976) and its many
derivatives is a popular tool to compare and dis-
play differences between two files. By being able
to understand what changed between an old and a
new version, programmers are able to identify lines
of code that made up the new features in the soft-
ware, and/or contributed to a new error in the soft-
ware. Given that many versions/options of design are
saved, a parametric ‘diff’ would be helpful to under-
stand the change in between the parametric model
- such as what components and links are deleted,
added, or changed, and designers could potentially
see how that change relates to the geometric differ-
ence.
To show changes, Diff tool highlights deleted
lines of code from the old version in red and added
lines in the new version in green. In the tool ‘MACE’,
Zaman et. al (2017) focused on making an inter-
face that could highlight differences of nodes (com-
ponents) and edges (links) between different design
alternatives. However, the tool is built on top of
a stand-alone 2D parametric pattern generator tool
and doesn’t provide end-to-end support for para-
metric modelling process. In GHShot, changed com-
ponents and links in between commits are high-
lighted in red (deleted), green (added), and yellow
(changed attributes inside components) for a down-
loaded model.
Parametric Model Alternative Generation
(Branching)
Both parametric modelling and software suffer from
the challenge of unclear goals in the beginning and
changing goals throughout development. For exam-
ple, a new software feature could suddenly be re-
quested while the software has already been used for
the client’s daily operation. A versioning system facil-
itates this by allowing programmers to write the code
for the new feature in a ‘branch’. By doing so, this new
feature could be tested separately and would not dis-
rupt the master (stable) code used currently. Simi-
larly, programmers could also develop different fea-
tures in different branches so they would not disrupt
each other’s work.
In parametric modelling environment, we be-
lieve this branching practice embodies two types of
design activities, both resulting in creation of design
alternatives: (1) exploring a different but parallel de-
sign direction and (2) exploring a range of compara-
ble design options within a parametric exploration
(changing parameters). Generation of alternatives
is a core activity in parametric modelling, and this
should be done seamlessly in any versioning system
for these systems. In GHShot implementation, True/-
False Toggle is used. A designer can choose to set
as true or false while committing the design. Set-
ting to true means that a new design concept/op-
tions is generated, while setting to false means a nor-
mal commit of progression and not branching.
Design - ALGORITHMIC AND PARAMETRIC 3 - Volume 3 - eCAADe 37 / SIGraDi 23 |39
Parametric Design Convergence from mul-
tiple alternatives (Merging)
In software practice features or fixes done on code
branches are eventually merged back into the mas-
ter code if they are useful or abandoned if they are
deemed not useful. However, in the early paramet-
ric design phase there is unlikely to be a ‘master’ ver-
sion yet. As many design alternatives are explored,
design branches could be created. Merging practice
then could be seen as making a new design iteration
inspired by previously created (two or more) alterna-
tives.
Software code is text-based and automatic
merge from two different branches could be done as
long as there is no ‘conflicts’, or different code in the
same line number. Grasshopper parametric model
is XML-based, and hence is also text-based. How-
ever, simply adding components and links from one
Grasshopper file to another could cause the paramet-
ric model not to work correctly. A better way of merg-
ing is then for a designer to copy parts from other files
to his/her own file to further develop the design.
With parametric model versioning tool in place,
parametric design progression is now captured,
stored in the cloud repository. Parametric model
‘snapshots’ mean empirical data of who did what de-
sign, at what time. In the next part, what could be
done with this data, and how this data could facilitate
a design exploration process will be discussed.
BEYOND CODE AND PARAMETRIC MODEL
VERSIONING
Analytics and User Feedback
Although Git [4] is a popular versioning tool, dis-
tributed versioning didn’t gain its ubiquity and im-
portant position until the rise of Github [5]. Git
is typically installed in programmer’s local machine,
and programmers can push and pull their code to
and from Github cloud repository, essentially sharing
their code to their teams or wider programmer com-
munity. As of May 2019 [6], there are over 39 million
user accounts and over 29 million projects on Github.
One important additional feature of Github on top of
Git is code analytics; where an overview of the num-
ber of commits done by each user, code frequency,
traffic of code, and other project-related information
are given and visualised in graph format. Having this
feature gives a team insight to monitor their project
and streamline their processes. In addition, with the
community-driven (public) repository, feedback or
issues may be quickly gathered and acted upon, im-
proving the software in faster iterations.
Figure 5
Parametric model
commits and
difference
detection. From
initial three existing
lines (1), two lines
are deleted (2) –
highlighted in red.
Length of
horizontal and
vertical intersecting
lines are modified
(4) – highlighted in
yellow.
40 |eCAADe 37 / SIGraDi 23 - Design - ALGORITHMIC AND PARAMETRIC 3 - Volume 3
Figure 6
Parametric Model
Branching and
Merging Practice.
Commit (2) has 3
branches (3,4,5)
based on its
diagonal pattern.
Commit (6) is the
merge from (4) and
(5)
Inspired by features in the Github repository, the
web repository of GHShot consists of four main views:
(1) snapshot view (see Fig. 7), (2) history tree (see Fig.
8), (3) design analytics (see Fig. 9), and (4) 3D model
view with commenting and rating feature (see Fig.
10). Snapshot view gives a quick overview of latest
designs uploaded. The histor y tree provides relation-
ship between designs, showing the project’s para-
metric model progression and exploration. Analytics
view allows comparison of quantitative or categori-
cal performance attributes of design options. The 3D
viewer enables users to give feedback on the design;
this dual view is analogous to the duality of objec-
tivity and subjectivity in design - there is no ‘true’ or
‘false’ solution, but ‘good’ or ‘bad’. Design, after all
is a ‘wicked problem’ (Rittel and Webber, 1973), and
will stop when a satisfacing solution is found. Further,
as a difference in code could produce a difference in
software outcome and performance, different design
schema produces different geometry and its perfor-
mance output. Versioning parametric model allows
progressive modelling (Wang et. al, 2019) - paramet-
ric models of different design schema can now be
compared for optimisation effort.
GHShot User Test Session and Interview
To understand how designers would interact with
a parametric design versioning tool, and how the
tool could likely affect design exploration process, we
conducted GHShot user test session followed by in-
terview after. Five student designers (undergraduate
and postgraduate) with 2-10 years of Grasshopper
experience were to explore a simple tower structure
parametric model (approximately 20 components)
individually, making models of their liking while still
minding the performance value (deflection and uti-
lization). One -hour time limit was given, and GHShot
was to be used in the process.
Table 1
Summary of
designer’s profile
and GHShot use
Designers were asked if GHShot was easy to use; as
an easier tool means less learning curve and likelier
for designers to integrate GHShot tool into their de-
sign workflow). Most designers found the tool to be
easy to use (see Table1), except D1 who gave 5/10 be-
cause of technical difficulties - the slow speed send-
ing model from Grasshopper to the server. Designers
Design - ALGORITHMIC AND PARAMETRIC 3 - Volume 3 - eCAADe 37 / SIGraDi 23 |41
were observed to be saving their progression period-
ically and creating branches as they made design al-
ternatives (see Table 2). D1 and D4 were asked why
they didn’t make any branches, and it was because of
the 1-hour time limit. As they did not save too many
options, linearly saving was enough and consistent
with their linear exploration. Should they be given
a longer time and to collaborate with other design-
ers, they would use the branching feature more. D5
asked if it was possible to modify the tree history (by
deleting or moving designs). In this manner, GHShot
was treated as a ‘design gallery system’ (Woodbury et
al, 2017), where designers filter and manage design
options they generated.
Below is feedback on GHShot extracted from the
interview after the design session:
On branching and design history view:
Helpful to understand the link between the
geometry and parametric, to remind yourself
why you change certain things (D1)
Idea of making branches and versions is really
easy to understand. Other people can look at
your work and understand how you started
at one point and came up with certain option
(D3)
On analytical graph:
• Useful to compare designs (D1), and see
trends (D5)
Useful to see how change in elements affect
performance (D2)
On 3D Viewer:
Easily sending and viewing my model online
means I could free up my machine’s graphic
resources (D4)
Good to see progress, especially for collabora-
tion or presentation (D5)
Others:
Convenience of having backup copies should
the current version doesn’t work (D2)
Figure 7
Snapshot View
Figure 8
History Tree
Figure 9
Design Analytics
Figure 10
3D Viewer
42 |eCAADe 37 / SIGraDi 23 - Design - ALGORITHMIC AND PARAMETRIC 3 - Volume 3
Unlike going back and forth with undo and
redo, having different copies of your designs
allow you to think about your overall design
(D3)
The tool allows not only to look at immediate
previous design iteration, but also the over-
all design iteration from the beginning, allow-
ing you to choose alternatives that might not
be the best performance, but good perfor-
mance enough to continue developing inter-
esting design (D5)
Overall, the feedback received seemed to be posi-
tive, leveraging on the GHShot’s capability to capture
end-to-end design progression and design options
as they are generated, and thus potentially giving de-
signers the capability to navigate their exploration
process better. Despite the individual user test ses-
sion conducted, designers mentioned how the tool
can be useful in a collaborative environment, which
will be conducted in our future testing.
CLOSING
We started by laying out the similar pattern of grow-
ing complexity faced by the software development
field and parametric modelling. Object-oriented pro-
gramming (OOP) and code versioning system were
born out of the need to improve collaboration and
manage the complexity that comes with bigger and
more complex software projects. Parametric mod-
elling has started to adopt the paradigm of modular-
ity - a concept of OOP, where there is a clear separa-
tion of functions inside parametric model, resulted in
a more structured/organised design schema. In par-
allel to modularity, we are proving a powerful next
step to take is for the design community to explore
the potential adoption of a design versioning tool.
The current state-of-the-art distributed version-
ing system provided a clear picture of how a ver-
sioning system can be used as a design support tool
during the exploration phase, especially in collabo-
rative environments where options are generated in
parallel. Four features of a versioning system: com-
mitting, differentiating, branching, and merging, had
been discussed on how it could be implemented in
a parametric modelling environment. A pilot study
with GHShot Grasshopper plugin and 5 student de-
signers revealed positive responses despite the short
one-hour testing. Parametric modelling versioning
system has the potential to provide a clear progres-
sion of design progress (especially for design docu-
mentation and presentation), to allow ease of sharing
and thus faster feedback and iteration process in a
collaborative environment. In additional, parametric
model progression visualisation and analytics could
give better insight and navigation of the whole de-
sign process.
Finally, we are reminded that both software de-
sign and architectural design are of different worlds.
Architectural design often has ambiguity and needs
interpretation (Vardouli, 2014). In this work, we es-
sentially tap on the fact that parametric models share
explicit externalisation (Aish and Woodbury, 2005) - a
similar trait to source code. And hopefully, in the long
run, with versioning system, ‘transparency in infor-
mation architecture’ (Hirschberg, 2003) could be cap-
tured, and hence, in the long run, the empirical data
(design) captured could contribute to design process
improvement. Future works involve releasing our
plugin to food4Rhino, a Grasshopper plugin reposi-
tory, to receive feedback from the wider Grasshopper
community.
REFERENCES
Aish, R 2000 ’, Collaborative Design using Long Transac-
tions and “Change Merge”, Proceedings of eCAADe 18
Aish, R and Woodbury, R 2005 ’Multi-level interaction
in parametric design’, International symposium on
smart graphics, pp. 151-162
Burry, J and Holzer, D 2009 ’). Sharing design space: Re-
mote concurrent shared parametric modeling’, Pro-
ceedings of the 27th eCAADe, pp. 333-340
Cristie, V and Joyce, SC 2017 ’Capturing And Visual-
ising Parametric Design Flow Through Interactive
Web Versioning Snapshots’, IASS Annual Symposium,
Hamburg, Germany
Cristie, V and Joyce, SC 2018 ’GHShot: 3D Design Ver-
sioning for Learning and Collaboration in the Web,
Extended Abstracts of the 2018 CHI Conference on
Design - ALGORITHMIC AND PARAMETRIC 3 - Volume 3 - eCAADe 37 / SIGraDi 23 |43
Human Factors in Computing Systems, Montreal, p.
LBW107
Davis, D 2013, Modelled on software engineering: Flexi-
ble parametric models in the practice of architecture.,
Ph.D. Thesis, RMIT
Davis, D, Burry, J and Burry, M 2011, ’Understanding vi-
sual scripts: Improving collaboration through mod-
ular programming’, . International Journal of Archi-
tectural Computing, 9(4), pp. 361-375
Dijkstra, EW 1972, ’The humble programmer’, Commun.
ACM, 15(10), pp. 859-866
Hirschberg, U 2003, ’Transparency in information archi-
tecture: Enabling large scale creative collaboration
in architectural education over the Internet’, Interna-
tional journal of architectural computing, 1(1), pp. 12-
22
Hunt, JW and McIlroy, MD 1976 ’An algorithm for dif-
ferential file comparison’, Bell Telephone Laboratories
CSTR #41
Huo, M, Verner, J and Babar, MA 2004 ’Software quality
and agile methods’, In Computer Software and Appli-
cations Conference, pp. 520-525
Brooks Jr, FP 1995, The Mythical Man-Month: Essays on
Software Engineering, Pearson Education India
Pena De Leon, A 2014, Separation of concerns: strategies
for complex parametric design modelling, Ph.D. The-
sis, RMIT
Muscettola, V, Salvi, M, Mutyaba, M, van der Hei-
jden, R, Tai, A and Levelle, E 2017 ’The Mor-
pheus Hotel: From Design to Production’,
www.rhino3d.com/go/morpheus
Rittel, HW and Webber,MM 1973, ’Dilemmas in a general
theory of planning’, Policy Sciences, 4(2), pp. 155-169
Rochkind, MJ 1975, ’The source code control system’, IEEE
transactions on Software Engineering, 4, pp. 364-370
Sakai, Y and Tsunoda, D 2015 ’Decentralized Version
Control and Mass Collective Collaboration in design-
A Case Study of a Web Application Utilizing the Diff
Algorithm and Automated Design Generation’, Pro-
ceedings of eCAADe 33, pp. 207-214
Smith, R 2007 ’Technical Notes from ex-
periences and studies in using Para-
metric and BIM architectural software’,
http://www.vbtllc.com/images/VBTTechnicalNo
tes.pdf
Valdez, MEP 1988, A gift from Pandora’s box: The software
crisis, Ph.D. Thesis, University of Edinburgh
Vardouli, T and Buechley, L 2014 ’Open source architec-
ture: an exploration of source code and access in ar-
chitectural design’, Leonardo 47(1), pp. 51-55
Verina, C and Joyce, SC 2018 ’GHShot: 3D Design Ver-
sioning for Learning and Collaboration in the Web,
Extended Abstracts of the 2018 CHI Conference
Wang, L, Janssen, P and Ji, G 2019 ’Progressive Modelling
for Parametric Design Optimization’, Proceedings of
the 24th CAADRIA, pp. 400-409
Woodbury, R 2010, Elements of Parametric Design, Rout-
ledge
Woodbury, R, Mohiuddin, A, Cichy, M and Mueller, V
2017, ’Interactive design galleries: A general ap-
proach to interacting with design alternatives’, De-
sign Studies, 52, pp. 40-72
Wortmann, T and Tuncer, B 2017, ’Differentiating para-
metric design: Digital workflows in contemporary
architecture and construction’, Design Studies, 52,
pp. 173-197
Zaman, L, Stuerzlinger, W and Neugebauer, C 2017
’MACE: A New Interface for Comparing and Editing
of Multiple Alternative Documents for Generative
Design’, Proceedings of the 2017 ACM Symposium on
Document Engineering, pp. 67-76
[1] https://www.food4rhino.com/app/autograph
[2] https://discourse.mcneel.com/t/whats-your-largest-
grasshopper-script-the-hall-of-shame/60594
[3] https://bimportal.scottishfuturestrust.org.uk/level1/
stage/8/task/47
[4] https://git-scm.com/
[5] https://github.com/
[6] https://github.com/search?l=&o=desc&q=followers:
%3E-1&ref=advsearch&s=joined&type=Users
44 |eCAADe 37 / SIGraDi 23 - Design - ALGORITHMIC AND PARAMETRIC 3 - Volume 3
... These glyphs themselves can be charts such as radar or bar charts, or they can even be images. This is common in the fields of design and engineering where qualitative aspects such as geometry need to be considered along with quantitative criteria [19], [20]. In many tools such as DesignExplorer [21] and Dreamlens [22], users are often able to access these multiple views simultaneously to visualise different aspects of the same solution space. ...
... Three ranges for the number of dimensions (3,5,10) and options (5,10,20) were used to generate the questions. Although 40 options were used in an initial pilot study, this was later removed as respondents deemed some visualizations using 40 options too difficult to read. ...
... We used four common chart types, namely heat maps, radar charts, SPLOMs, PCPs, and a combination of three dimension (3,5,10) and three option (5,10,20) sets. Participants chose an option from a data set in the context of a multi-objective decision that involved a complex tradeoff. ...
Article
Decision-makers across many professions are often required to make multi-objective decisions over increasingly larger volumes of data with several competing criteria. Data visualization is a powerful tool for exploring these complex solution spaces, but there is little research on its ability to support multi-objective decisions. In this paper, we explore the effects of visualization design and data volume on decision quality in multi-objective scenarios with complex trade-offs. We look at the impact of four common multidimensional chart types (scatter plot matrices, parallel coordinates, heat maps, radar charts), the number of options and dimensions, the ratio of number of dimensions considered to the number of dimensions shown, and participant demographics on decision time and accuracy when selecting the optimal option. As objectively evaluating the quality of multi-objective decisions and the trade-offs involved is challenging, we employ rank- and score-based accuracy metrics. Our findings show that accuracy is comparable across all four visualizations, but that it improves when users are shown fewer options and consider fewer dimensions in their decision. Similarly, considering fewer dimensions imparts a speed advantage, with heat maps being the fastest among the four charts types. Participants who use charts frequently were observed to perform significantly faster, suggesting that users can potentially be trained to effectively use visualizations in their decision-making.
... To understand this design process better, a time-dependent analysis is critically needed. Prior work by authors (15,16,17) has demonstrated how this time-dependent design progression data can be captured. This paper aims to investigate and develop frameworks to understand this data better. ...
... Students were to explore this model individually before discussing and continuing to develop the model as a group on the third though to the fifth day of the workshop. The GHShot Grasshopper plugin versioning tool (15,16) , was used to record student's design progression throughout the workshop. At any point in the design development, students could send their current parametric model to cloud platform. ...
Conference Paper
Full-text available
Despite the plenty of data collected through collaborative design exercises in pedagogy settings, very few of these data were utilized for further studies. This occurrence is in contrast with the software development settings where software repositories are often mined to find insights on programmer’s software building pattern. In this work, we implemented exploratory time-series data analysis through design versions data collected from a parametric design workshop of 44 students in groups of five. A framework to discover design change pattern through in-between change count was developed. The result revealed three different change patterns the group exhibit: premature fixation, constant change, and last-minute work. Finally, it is found that constant change pattern corresponds to higher instructor-given final design computation score, as students were encouraged to explore sufficient design ideas in the workshop.
... GHShot [8][9][10], was developed as a versioning system for Grasshopper Parametric Modelling software. GHShot stands for Grass-Hopper Snapshot; the idea was that designers could send the snapshot of their design (design version) easily to the cloud as their design progress. ...
Article
Many design versions are produced during design exploration. However, these versions are typically maintained manually often using an individual's self-determined logic, and thus hamper design workflow when a specific file cannot be located, similar ideas and mistakes revisited, or even loss of a potentially good design direction. These issues, in contrast, have been effectively addressed in software engineering by using a versioning system. In this work, we propose that integrating a versioning system into parametric design exploration workflow provides following benefits: (1) version control, (2) cross-iteration versions comparison, (3) feedback platform, and (4) design project analytics. A computational design workshop facilitated with our customised cloud-based ver-sioning tool revealed student's positive responses of versioning as a personal documentation and group collab-oration tool.
Preprint
Full-text available
Architectural design practice has radically evolved over the course of its history, due to technological improvements that gave rise to advanced automated tools for many design tasks. Traditional paper drawings and scale models are now accompanied by 2D and 3D Computer-Aided Architectural Design (CAAD) software. While such tools improved in many ways, including performance and accuracy improvements, the modalities of user interaction have mostly remained the same, with 2D interfaces displayed on 2D screens. The maturation of Augmented Reality (AR) and Virtual Reality (VR) technology has led to some level of integration of these immersive technologies into architectural practice, but mostly limited to visualisation purposes, e.g. to show a finished project to a potential client. We posit that there is potential to employ such technologies earlier in the architectural design process and therefore explore that possibility with a focus on Algorithmic Design (AD), a CAAD paradigm that relies on (often visual) algorithms to generate geometries. The main goal of this dissertation is to demonstrate that AR and VR can be adopted for AD activities. To verify that claim, we follow an iterative prototype-based methodology to develop research prototype software tools and evaluate them. The three developed prototypes provide evidence that integrating immersive technologies into the AD toolset provides opportunities for architects to improve their workflow and to better present their creations to clients. Based on our contributions and the feedback we gathered from architectural students and other researchers that evaluated the developed prototypes, we additionally provide insights as to future perspectives in the field.
Conference Paper
Full-text available
Although parametric modelling and digital design tools have become ubiquitous in digital design, there is a limited understanding of how designers apply them in their design processes (Yu et al., 2014). This paper looks at the use of GHShot versioning tool developed by the authors (Cristie & Joyce, 2018; 2019) used to capture and track changes and progression of parametric models to understand early-stage design exploration and collaboration empirically. We introduce both development history graph-based metrics (macro-process) and parametric model and geometry change metric (micro-process) as frameworks to explore and understand the captured progression data. These metrics, applied to data collected from three cohorts of classroom collaborative design exercises, exhibited students' distinct modification patterns such as major and complex creation processes or minor parameter explorations. Finally, with the metrics' applicability as an objective language to describe the (collaborative) design process, we recommend using versioning for more data-driven insight into parametric design exploration processes.
Conference Paper
Full-text available
The potential of parametric associative models to explore large ranges of different designs is limited by our ability to manually create and modify them. While computation has been successfully used to generate variations by optimizing input parameters, adding or changing ‘components’ and ‘links’ of these models has typically been manual and human driven. The intellectual overhead and challenges of manually creating and maintaining complex parametric models has limited their usefulness in early stages of design exploration, where a quicker and wider design search is preferred. Recent methods called Meta Parametric Design using Cartesian Genetic Programming (CGP) specifically tailored to operate on parametric models, allows computational generation and topological modification for parametric models. This paper proposes the refinement of Meta Parametric techniques to quickly generate and manipulate models with a higher level of control than existing; enabling a more natural human centric user-directed design exploration process. Opening new possibilities for the computer to act as a co-creator: able to generate its own novel solutions, steered at a high-level by user(s) and able to develop convergent or divergent solutions over an extended interaction session, replicating in a faster way a human design assistant.
Conference Paper
Full-text available
During the process of design, copies of files are often stored to track changes and design development or to ensure that previous work will not be lost. In software design field, such process is supported using versioning system, where source code is saved intermittently when features are added or modified for individual or group use. We argue that similar versioning system will also benefit the design community when applied to 3D design files, to see how their designs progress and collaborate. In this paper we outline a implemented web based open ecosystem allows designers to similarly collaborate but with a lower bar for adoption than comparable software versioning system. Our system is to be applied to a classroom setting, where architecture students learn to make structural designs; they are then able to see, modify, and give feedback to each other's work.
Article
Full-text available
This paper examines Parametric Design (PD) in contemporary architectural practice. It considers three case studies: The Future of Us pavilion, the Louvre Abu Dhabi and the Morpheus Hotel. The case studies illustrate how, compared to non-parametrically and older parametrically designed projects, PD is employed to generate, document and fabricate designs with a greater level of detail and differentiation, often at the level of individual building components. We argue that such differentiation cannot be achieved with conventional Building Information Modelling and without customizing existing software. We compare the case studies' PD approaches (objected-oriented programming, functional programming, visual programming and distributed visual programming) and decomposition, algorithms and data structures as crucial factors for the practical viability of complex parametric models and as key aspects of PD thinking.
Conference Paper
Full-text available
Parametric design systems model a design as a constrained collection of schemata. Designers work in such systems at two levels: def- inition of schemata and constraints; and search within a schema collec- tion for meaningful instances. Propagation-based systems yield ecient algorithms that are complete within their domain, require explicit speci- fication of a directed acyclic constraint graph and allow relatively simple debugging strategies based on antecedents and consequents. The require- ment to order constraints appears to be useful in expressing specific de- signer intentions and in disambiguating interaction. A key feature of such systems in practice appears to be a need for multiple views onto the con- straint model and simultaneous interaction across views. We describe one multiple-view structure, its development and refinement through a large group of architecture practitioners and its realization in the system Generative Components.
Conference Paper
We present a new interface for interactive comparisons of more than two alternative documents in the context of a generative design system that uses generative data-flow networks defined via directed acyclic graphs. To better show differences between such networks, we emphasize added, deleted, (un)changed nodes and edges. We emphasize differences in the output as well as parameters using highlighting and enable post-hoc merging of the state of a parameter across a selected set of alternatives. To minimize visual clutter, we introduce new difference visualizations for selected nodes and alternatives using additive and subtractive encodings, which improve readability and keep visual clutter low. We analyzed similarities in networks from a set of alternative designs produced by architecture students and found that the number of similarities outweighs the differences, which motivates use of subtractive encoding. We ran a user study to evaluate the two main proposed difference visualization encodings and found that they are equally effective.
Article
Designers work by exploring alternatives. While extant parametric modelers theoretically define alternatives, their interfaces generally provide access to designs serially. Our goal is to change this near-universal feature of parametric interfaces to support exploration using multiple alternatives. We built a prototype gallery system on a web browser that supports saving alternatives from three graph-based parametric modeling tools. Users can retrieve alternatives from the gallery, share them with others, and combine them to generate more alternatives. We evaluated this system qualitatively in a workshop with ten expert designers working on their own design problems. We learnt that users prefer the gallery to their accustomed workarounds. The study produced several directions for new user interface designs.
Book
With contributions from Brady Peters, Onur Yuce Gun and Mehdi Sheikholeslami Design is change. Parametric modeling represents change. It is an old idea, indeed one of the very first ideas in computer-aided design. In his 1963 PhD thesis, Ivan Sutherland was right in putting parametric change at the centre of the Sketchpad system. His invention of a representation that could adapt to changing context both created and foresaw one of the chief features of the computer aided design (CAD) systems to come. The devices of the day prevented Sutherland from fully expressing what he might well have seen, that parametric representations could deeply change design work itself. I believe that, today, the key to both using and making these systems lies in another, older idea. People do design. Planning and implementing change in the world around u one of the key things that make us human. Language is what we say; design and making is what we do. Computers are simply a new medium for this ancient enterprise. True, they are the first truly active medium. They are general symbol processors, almost limitless in the kind of tool that they can present. With much craft and care, we can program them to do much of what we call design. But not all. Designers continue to amaze us in with new function and form. Sometimes new work embodies wisdom, a precious commodity in a finite world. To the human enterprise of design, parametric systems bring fresh and needed new capabilities in adapting to context and contingency and exploring the possibilities inherent in an idea. What is the new knowledge and skill designers need to master the parametric? How can we learn and use it? That is what this book is about. It aims to help designers realize the potential of the parameter in their work. It does so by combining basic ideas of parametric systems themselves with equally basic ideas from both geometry and computer programming.
Article
This paper reports on research involving researchers and senior undergraduate students investigating the potential for sharing parametric digital design models via a central server using version control software for file sharing and locking. The innovation is introducing remote shared flexible modeling in very early design to observe firstly, the negotiation of protocols for working together in this environment and secondly the generative and constraining impacts of working in a flexible relational model with other unseen hands at work.
Article
If our goal is implement collaborative engineering across temporal, spatial and discipline dimensions, then it is suggested that we first have to address the necessary pre-requisites, which include both the deployment of "enterprise computing" and an understanding of the computing concepts on which such enterprise systems are based. This paper will consider the following computing concepts and the related concepts in the world of design computing, and discuss how these concepts have been realised in Bentley Systems? ProjectBank collaborative engineering data repository: Computing Concept Related Design Concept Normalisation Model v. Report (or Drawing) Transaction Consistency of Design Long Transaction Parallelisation of Design Change Merge Coordination (synchronisation) Revisions Coordination (synchronisation) While we are most probably familiar with the applications of existing datadase concepts (such as Normalisation and Transaction Management) to the design process, the intent of this paper to focus
Capturing And Visualising Parametric Design Flow Through Interactive Web Versioning Snapshots
  • Cristie
  • Joyce
  • Sc
Cristie, V and Joyce, SC 2017 'Capturing And Visualising Parametric Design Flow Through Interactive Web Versioning Snapshots', IASS Annual Symposium, Hamburg, Germany