Content uploaded by Aikaterini Chatzivasileiadi

Author content

All content in this area was uploaded by Aikaterini Chatzivasileiadi on Sep 28, 2018

Content may be subject to copyright.

Topologic

A toolkit for spatial and topological modelling

Wassim Jabi1, Robert Aish2, Simon Lannon3,

Aikaterini Chatzivasileiadi4, Nicholas Mario Wardhana5

1,3,4,5Cardiff University 2University College London

1,3,4,5{jabiw|lannon|chatzivasileiadia|wardhanan}@cardiff.ac.uk 2robert.

aish@ucl.ac.uk

This paper describes non-manifold topology (NMT) as it relates to the field of

architecture and presents Topologic, an open-source software modelling library

enabling hierarchical and topological representations of architectural spaces,

buildings and artefacts through NMT. Topologic is designed as a core library and

additional plugins to visual data flow programming (VDFP) software. The

software architecture and class hierarchy are explained and two domain-specific

demonstrative tools (TopologicEnergy and TopologicStructure) are presented to

illustrate how third-party software developers could use Topologic to build their

own solutions. The paper concludes with a reflection on the benefits and

limitations of NMT in the design and simulation workflows and outlines future

work.

Keywords: Non-manifold topology, Visual data flow programming, Building

performance simulation, Structural analysis, Computational design, Building

information modelling

WHY NON-MANIFOLD TOPOLOGY

While the ﬁeld of topology is a vast and fascinating

area of study in mathematics with precise concepts

and terminology, in this paper we deﬁne terms and

consider issues of topology and geometry narrowly

and more simply as they apply to the ﬁeld of architec-

ture and computational design. Thus, our deﬁnitions

of topological concepts will necessarily be less pre-

cise than those used by mathematicians, but more di-

rectly applicable to the ﬁeld of architecture. The term

‘topology’ is derived directly from the Greek τόπος

(place), and λόγος (study), and therefore can be de-

ﬁned as the study of place - or the study of space

[1]. This is precisely our aim - mainly to enhance the

representation of space in computational design sys-

tems through the use of topological concepts. Topol-

ogy deﬁnes the relationships between entities. For

example, two spaces can be thought as topologically

adjacent, if they share a common face. In contrast

to geometry, topology is concerned with the prop-

erties of space that remain constant when it is sub-

jected to deformations. Yet, geometry and topology

are fundamentally inter-linked. A geometric opera-

tion on an object fundamentally changes its topol-

Draft - eCAADe 36 |1

ogy. For example, removing one outer face of a pris-

matic closed cell transforms it into an open shell and

thus alters its topology.

The diﬀerence between manifold and non-

manifold geometry

Computer-aided design (CAD), building information

modelling (BIM), and parametric visual data ﬂow pro-

gramming (VDFP) software usually rely on low-level

geometric engines (kernels) and software develop-

ment kits (SDK). These geometric kernels are usu-

ally classiﬁed as manifold or non-manifold (Chatzi-

vasileiadi, Wardhana, et al. 2018). Simply put,

manifold kernels represent three-dimensional enti-

ties with a series of connected boundary elements

that separate the outside world from its solid inte-

rior. Manifold entities (also called 2-mainfold) with

a boundary, such as a circle or a torus, can be un-

folded into a continuous ﬂat plane. In contrast, non-

manifold Topology (NMT) entities (also called 3 or

more manifold) such as a T-junction cannot be un-

folded into a continuous ﬂat wire or surface (see ﬁg-

ure 1).

NMT can represent the space inside an object

and allows subdivision of an outer boundary with in-

ner zero-thickness boundaries. In addition, NMT al-

lows entities with mixed dimensionalities to co-exist

in the same entity. Manifold geometry kernels usu-

ally struggle to model and represent non-manifold

entities and instead consider them modelling errors:

“Some tools and actions in Maya cannot work prop-

erly with non-manifold geometry. For example, the

legacy Boolean algorithm and the Reduce feature do

not work with non-manifold polygon topology [...]

Some types of polygon geometry will not work in

Maya. Invalid geometry includes vertices that are not

associated with a polygon edge and polygon edges

that are not part of a face (dangling edges)” [2]. 3D

manufacturing also struggles with non-manifold ob-

jects: “[...] Shapeways requires all objects to be 2-

manifold. This means that each edge should be con-

nected to exactly two faces. ‘Open’ objects are typi-

cally 1-manifold (or even 0-manifold for stray edges),

models containing unwanted faces are 3- or more

manifold” [3]. In addition, manifold kernels have tra-

ditionally focused on geometry far more than topol-

ogy. These systems can rarely recognise, query and

report on topological relationships and if they do, the

processes and representations are particular rather

than universal and ad hoc rather than formal.

Figure 1

Examples of

non-manifold

entities.

At this point the reader may be wondering why any-

one would use NMT if it causes such problems. The

reason is that NMT provides many advantages over

regular manifold modelling (Lee et al. 2009; Chang &

Woodbury 1997; Nguyen 2011; Aish & Pratap 2013).

As described earlier, NMT is well-suited to create a

lightweight representation of a building as an ex-

ternal envelope and the subdivision of the enclosed

space into separate spaces and zones using zero-

thickness internal surfaces. Because NMT maintains

topological consistency, a user can query these cel-

lular spaces and surfaces regarding their topological

data and thus conduct various analyses. For exam-

ple, this lightweight and consistent representation

was found to be well-matched with the input data

requirements for energy analysis simulation software

(Ellis et al. 2008; Jabi 2015).

As we will see later in the paper, because NMT al-

lows entities with mixed dimensionalities and those

that are optionally independent (e.g. a line, a surface,

a volume) to co-exist, structural models can be rep-

resented in a coherent manner where lines can rep-

resent columns and beams, surfaces can represent

walls and slabs, and volumes can represent solids.

In addition, non-building entities, such as structural

loads can be eﬃciently attached to the structure.

This creates a lightweight model that is well-matched

with the input data requirements for structural anal-

ysis simulation software.

In another paper by the authors we illustrated

how NMT can represent a design envelopeand popu-

2|eCAADe 36 - Draft

late it with bespoke conformal cellular units in prepa-

ration for digital fabrication. Access to topology in-

formation allowed us to create and follow rules about

the shape of and connection between deposited cel-

lular unit to create a more eﬃcient and better con-

nected conformal cellular structure (Jabi et al. 2017).

Finally, we successfully used NMT to spatially

reason about and evaluate the social sustainability

of vernacular courtyard houses. In that research

project, topology information allowed us to build

dual graphs and conduct space syntax analysis eﬃ-

ciently using lightweight models. The software rep-

resented rooms as spaces with zero-thickness divid-

ing surfaces and with embedded apertures such as

door. We then used that information to create a

shape grammar and a computational tool to design

socially sustainable tall buildings (Al-Jokhadar & Jabi

2017).

RATIOCINATION VS. FABRICA

Designing, representing and reasoning about archi-

tectural space is one of the unique and deﬁning prop-

erties of architecture (Ching 2014). Accounts from

the literature indicate that buildings are often ﬁrst

conceptualised as a hierarchical sequence of related

spaces (Curtis 1996). Only once this spatial arrange-

ment has been deﬁned does the focus shift to how

these spaces will be realised by the use of physical

building components. However, in BIM systems, the

most prevalent approach is to represent a building as

a collection of 3D solid models with each solid rep-

resenting an individual physical building component

(Attia et al. 2011). Each of these solid models uses

manifold topology to deﬁne the boundaries that sep-

arate the external void from the internal enclosed vol-

ume representing the material content of the compo-

nent. Modern BIM systems do not require nor advo-

cate the creation of a conceptual spatial model as the

basis of the building fabric model. Consider, for ex-

ample, this ﬁrst sentence of the Autodesk Revit tuto-

rial on how to get started with building a BIM model:

“Start with the general building components (walls,

ﬂoors, roofs). Then slowly reﬁne the design, adding

more detailed components (stairs, rooms, furniture)

as you proceed.” [4]. Architects are thus often asked

to postpone the derivation of the conceptual spa-

tial model and other representations to a later stage

and from an overly complex fabric model to conduct

tasks such as energy analysis, structural analysis, spa-

tial reasoning, and fabrication planning. This process

leads to diﬃculties, errors and an increase in time and

eﬀort.

Alternatively, one can follow a Vitruvian ap-

proach by starting with a topological model as a con-

ceptual regulating skeleton that sets out the ratio-

cination - the rational and theoretical setting out of

principles that can then support the creation of fab-

rica - the physicality of fabricating architecture (Pont

2005). Similarly, other researchers have emphasised

the importance of thinking abstractly and strategi-

cally by using a controller (something that controls

something else) and a proxy (something that stands

in for something else) in parametric design software

(Woodbury et al. 2010). These strategies ensure re-

silience within the system in the face of change; thus

a design system that forgoes this strategic deﬁnition

of topological relationships risks brittleness and fail-

ure in later design stages (Jabi et al. 2017).

Therefore, one of the primary motivations for this

research is to rethink the BIM design process to focus

ﬁrst on building a conceptual model that can act as

an ordering framework and support for further de-

sign development. In this process, an NMT concep-

tual model would serve as a deﬁning model for a

derived building fabric model. The NMT conceptual

model would deﬁne both the spatial conﬁguration

and topology as well as provide a skeletal framework

that can be ‘thickened’, either manually or using com-

putational algorithms and rules, into actual building

fabric components (Aish & Pratap 2013).

This is, obviously, not a new concept for design-

ers many of whom implement this methodology ef-

fectively, but in a bespoke and ad hoc manner due

to the lack of formal support in BIM systems. A

case in point is the Aviva Stadium in Dublin, Ireland

design by Populous (formerly HOK Sports Architec-

Draft - eCAADe 36 |3

ture) from 2005 to 2007. This project exempliﬁed a

transitional period that saw a shift from computer-

aided solids modelling to fully parametric design pro-

cesses. Initially, the design was ﬁrst studied through

static 3D models using McNeel’s Rhinoceros platform

[5]. However, the designers quickly realised that this

is an unsustainable approach due to the time and

eﬀort needed to implement changes. The stadium

design was re-considered as a simpliﬁed, conceptual

and parametric system, using Bentley’s Generative

Components software [6] (see ﬁgure 2).

Figure 2

Parametric

development of the

Aviva Stadium

geometry (Image

courtesy of

Populous).

The parametric model was made of three elements:

“the footprint of the stadium, composed of eight tan-

gential arcs; the plan of the inner roof or drip line,

also composed of eight tangential arcs; and a radial

structural grid that eventually became the support-

ing system of the stadium’s outer surface or skin.”

(Jabi 2013). This controlling lightweight conceptual

model, which could’ve been formalised as an NMT

Cluster of vertices, edges, wires, and faces, was then

shared by the architects and the structural consul-

tants, through nothing more than a Microsoft Excel

spreadsheet with an agreed format. The spreadsheet

was then used as the basis to drive the solution of the

structural model and the cladding system. In this ex-

ample, the thickened fabric of the project was con-

sidered a derived model from the conceptual deﬁn-

ing model of curve centrelines. The Aviva Stadium

case study illustrates the need to formalise this in-

verted design process and enable designers to spec-

ify deﬁning and derived models, and the relation-

ships amongst them, more precisely and formally.

NON-MANIFOLD TOPOLOGY

Because NMT formalises the spatial relationships be-

tween the various entities in a model and describes

how geometric entities are connected, this research

hypothesises that NMT has potential to serve as the

formal mechanism with which to build deﬁning mod-

els and precisely translate them into derived building

fabric models. This approach can serve a wide range

of representations of architectural space with bene-

ﬁts for various design, analysis, and production tasks.

Based on a previous review published by the au-

thors, a topological framework with the following

eight entities, arranged from the highest level of di-

mensionality to the lowest, is proposed: Cluster, Cell-

Complex, Cell, Shell, Face, Wire, Edge, and Vertex.

Each entity may contain other lower-level entities -

with the exception of a Cluster in which another Clus-

ter can be contained (Chatzivasileiadi, Wardhana, et

al. 2018).

In addition to allowing multiple faces to meet at

an edge or multiple edges to meet at a vertex, co-

incident entities (within a user-speciﬁed tolerance)

are merged and are ensured to be unique. Further-

more, imported mesh data, in standard vertex/index

format, can be self-merged not only to remove dupli-

cates, but to build the highest dimensional entities

possible automatically. These entities share lower-

dimensional entities where possible. This leads to ef-

ﬁcient and consistent models that avoid the duplica-

tion problems found in regular manifold and polyhe-

dral modelling that do not enforce such rules. For ex-

ample, a mesh model (see left in ﬁgure 3) with 7 faces

is converted into a non-manifold cluster object con-

taining one (1) closed cell, one (1) open shell, nine (9)

faces, nine (9) wires, nineteen (19) edges, and twelve

(12) vertices (see right in ﬁgure 3). Any duplicated en-

4|eCAADe 36 - Draft

tities are removed and topologically linked. Finally,

notice that what used to be three (3) single rectangu-

lar faces (top and side faces) in the original mesh data

are automatically segmented into two square faces

each in the resulting self-merged NMT model.

Figure 3

Exploded

axonometric of a

mesh model (left),

and the resulting

self-merged

non-manifold

cluster with one

closed cell, and one

open shell (right).

NMT models can be combined and manipulated

using regular Boolean operations. However, NMT

Boolean operations extend the traditional regular

operations of union, diﬀerence and intersection to

include the following irregular Boolean operation:

Merge, XOR, Impose, Imprint, Slice, Trim, and Un-

merge (Aish & Pratap 2013). Generally, a regular

Boolean operation removes any external faces of the

input bodies that are within the resulting body, while

a non-regular Boolean operation maintains these

faces. As a result, regular operations lead to a man-

ifold result, while non-regular operations lead to a

non-manifold result.

Prior publications by the authors suggest a

strong potential of using geometrical entities with

NMT as a representation of architectural space that is

also highly compatible with the input requirements

of building performance simulation (BPS) engines,

structural design, fabrication planning, and spatial

reasoning (Jabi 2016; Jabi et al. 2017; Al-Jokhadar &

Jabi 2017). The approach aﬀorded by NMT provides

topological clarity that has the potential to allow ar-

chitects to better design, analyse, reason about, and

produce their buildings.

TOPOLOGIC: A NON-MANIFOLD TOPOL-

OGY MODELLING TOOLKIT

This paper presents Topologic, an open-source soft-

ware modelling library enabling hierarchical and

topological representations of architectural spaces,

buildings and artefacts through NMT. Topologic is

designed as a core library and additional plugins to

visual data ﬂow programming (VDFP) applications

(Hils 1992; Marttila-Kontio et al. 2009) and para-

metric modelling platforms commonly used in ar-

chitectural design practice. These applications pro-

vide workspaces with visual programming nodes and

connections for architects to interact with Topologic

and perform architectural design and analysis tasks.

Software architecture

Topologic is implemented using a multi-layer soft-

ware architecture (see ﬁgure 4). At the lowest layer,

we use Open CASCADE, an open-source NMT geom-

etry software development kit (SDK) that provides

data structures and modelling algorithms for 3D

solid structures [7]. We also use ShapeOp, an open-

source SDK for surface planarization [8]. Classes

and methods in these two SDKs are encapsulated

in the second software layer containing the Topo-

logicCore and TopologicSupport libraries, written in

C++. TopologicCore implements the core topologic

classes and methods using an object-oriented pro-

gramming (OOP) approach while TopologicSupport

provides added utilities as needed. Above this layer,

we implemented an interface layer, written in the

.NET C++/CLI language, that connects the core and

support libraries to the host geometric editor or vi-

sual data ﬂow programming application. At present,

this layer (Topologic[VDFP]) has been written for Au-

todesk Dynamo software [9] and is thus named Topo-

logicDynamo.

Figure 4

Topologic

multi-layered

software

architecture.

Work is underway to implement a version for McNeel

Rhino/Grasshopper 3D [10] (TopologicGH) which will

be reported on in future publications. Additionally,

we envisage plug-in developers will use this layer to

Draft - eCAADe 36 |5

develop domain-speciﬁc applications. By strongly

separating the code written for diﬀerent platforms,

this architecture ensures high modularity and code

readability. In addition, the soft ware can be easily ex-

tended to other platforms by writing a small library

using the platform’s conventions in the upper layer

to encapsulate the core library.

Class Hierarchy

TopologicCore contains the following main classes

(see ﬁgure 5):

Figure 5

Topologic class

hierarchy.

• Topology: A Topology is an abstract super-

class that stores constructors, properties and

methods used by other subclasses that ex-

tend it.

• Vertex: A Vertex is a zero-dimensional entity

equivalent to a geometry point.

• Edge: An Edge is a one-dimensional entity de -

ﬁned by two vertices. It is important to note

that while a topologic edge is made of two

vertices, its geometry can be a curve with mul-

tiple control vertices.

• Wire: A Wire is a contiguous collection of

Edges where adjacent Edges are connected

by shared Vertices. It may be open or closed

and may be manifold or non-manifold.

• Face: A Face is a two-dimensional region de-

ﬁned by a collection of closed Wires. The ge-

ometry of a face can be ﬂat or undulating.

• Shell: A Shell is a contiguous collection of

Faces, where adjacent Faces are connected by

shared Edges. It may be open or closed and

may be manifold or non-manifold.

• Cell: A Cell is a three-dimensional region de-

ﬁned by a collection of closed Shells. It may

be manifold or non-manifold.

• CellComplex: A CellComplex is a contigu-

ous collection of Cells where adjacent Cells

are connected by shared Faces. It is non-

manifold.

• Cluster: A Cluster is a collection of any topo-

logic entities. I t maybe contiguous or not and

may be manifold or non-manifold. Clusters

can be nested within other Clusters.

Several other classes are being actively developed.

These include, but not limited to:

• Context: A Context deﬁnes a topological re-

lationship between two otherwise indepen-

dent Topologies.

• Graph: A Graph is a Wire that is deﬁned by the

topology of a CellComplex or a Shell. It can be

manifold or non-manifold. A dual graph is a

good example of this class.

Written using the Object-Oriented Programming

(OOP) paradigm, at the top level of Topologic’s class

hierarchy resides the Topology class, which is inher-

ited by other classes representing the topological en-

tities. Methods written in these classes can be gener-

ally classiﬁed into four categories, namely construc-

tors, queries, Boolean operations, and other entity-

speciﬁc methods. Constructors are used to construct

a topological entity from geometric entities or lower-

level topological entities. Query methods retrieve

one or more entities from another entity. Queries can

be further categorised into three: upward queries,

to retrieve higher-level entities which constitute the

argument entity; downward queries, to retrieve the

constituent lower-level entities of an entity; and side-

ways query, to retrieve adjacent entities on the same

level. Boolean operations combine two entities into

one in various ways and are written inside the par-

6|eCAADe 36 - Draft

ent Topology class. Finally, classes may have meth-

ods specially written for them. For example, the Wire

and Shell classes have methods to test if they are

closed. In addition, the Face class has operations to

attach multiple faces as apertures, which can be used

to model glazing as an example.

It should be noted that, in large part, Topologic

does not introduce its own entities or geometric

computations. Instead, whenever possible, it relies

on those either from the underlying SDKs or from

the host application to ensure compatibility. In addi-

tion, the topological classes can be used to represent

their geometry counterparts. For example, a Topo-

logic face may actually represent a planar or an un-

dulating NURBS surface trimmed by a wire, thus pro-

viding an abstraction for a wide variety of surfaces.

Despite TopologicCore being object-oriented

in its design, Topologic[VDFP] follows the VDFP

methodology to ensure compatibility with its host vi-

sual data ﬂow programming workspace. In VDFP, a

program is represented visually by a directed graph

made of nodes and arcs that connect them. Nodes

represent functions and arcs represent the ﬂow of

data between them (Hils 1992; Marttila-Kontio 2011).

Topologic methods are represented as visual

nodes with input and output ports. Topologic en-

tities are immutable at the host application levels.

Thus, modifying the attributes of an entity after the

fact, as is usually done in an OOP environment, is not

possible. Instead, the user has to trace the construc-

tor of the object and modify its input parameters or

create a brand new deep copy of the entity with dif-

ferent attributes.

A Topologicnode is designed to accept topologi-

cal instances from the library and the native geomet-

ric counterparts from the host application. In addi-

tion, any node that produces a topological entity also

has an extra output port that outputs the geometric

counterpart to allow display using the native host ap-

plication as well as additional workﬂows external to

Topologic. These design principles guarantee eﬀort-

less connection from and to indigenous nodes in a

single workﬂow.

DOMAIN-SPECIFIC APPLICATIONS

As explained above, we envisage that our software

will be used by plug-in developers to create domain-

speciﬁc applications. To illustrate this process, we

created two demonstrative applications. The ﬁrst ap-

plication, TopologicEnergyallows the user to quickly

build models that can be sent to EnergyPlus (Craw-

ley et al. 2000) for energy simulation using the Open-

Studio toolkit (Guglielmetti et al. 2011). The second

application, TopologicStructure demonstrates how a

mixed-dimensional structural model can be created

with structural loads applied to it.

TopologicEnergy

A comparative study with traditional workﬂows was

conducted and reported in previous publications

(Chatzivasileiadi, Lannon, et al. 2018) and thus will

only be summarised here. The experiment analysed

four pathways to the energy modelling of a building

with relatively complex geometry including curved

surfaces and bespoke glazing. From the four path-

ways explored, the NMT pathway using Topolog-

icEnergy was able to model and handle complex ge-

ometry and produce reliable results, while beneﬁt-

ting from the advantages of NMT. As shown in ﬁgure

6, the workﬂow consisted of (a) modelling the exter-

nal envelope and the glazing design on a ﬂat surface,

(b) mapping the glazing unto the curved wall, (c) sub-

dividing and planarizing the wall and mapped glaz-

ing into a set of wall panels and windows, (d) slicing

the building into multiple stories, and ﬁnally (e) send-

ing the model to OpenStudio/EnergyPlus for energy

analysis (Wardhana et al. 2018)

Modelling the external envelope and the glazing

design on a ﬂat surface. We start by creating a series of

circular wires that are then lofted into a surface. This

is converted to a Topologic face (see ﬁgure 6-1). The

glazing is created as a rectangular face with internal

wires that represent the glazing apertures (see ﬁgure

6-2).

Mapping the glazing onto the curved wall. The

ﬂat glazing design is sampled using a user-speciﬁed

number of rows and columns and mapped onto the

Draft - eCAADe 36 |7

Figure 6

TopologicEnergy

example workﬂow.

UV parametric space of the curved wall (see ﬁgure 6-

3).

Subdividing and planarizing the wall and mapped

glazing into a set of wall panels and windows. The

curved wall and glazing are then segmented into

quadrilaterals using a user-speciﬁed number of rows

and columns (see ﬁgure 6-4). The resulting mesh

is then planarized using the ShapeOp library [8].

The glazing is further triangulated and scaled down

slightly in keeping with the requirements of Open-

Studio and EnergyPlus.

Slicing the building into multiple stories. A series

of planes are created to represent ﬂoor slabs and con-

verted into Topologic faces(see ﬁgure 6-5). Using the

non-manifold slice boolean operation, the building is

sliced into separate ﬂoors and a Topologic CellCom-

plex is created (see ﬁgure 6-6).

Sending the model to OpenStudio/EnergyPlus. The

Topologic CellComplex is queried for its constituent

Topologic Cells, faces, and sub-faces and those

are translated into OpenStudio spaces and thermal

zones (see ﬁgure 6-7). The TopologicEnergy software

then sends the resulting energy model to EnergyPlus

and automatically triggers an energy simulation.

TopologicStructure

The second demonstrative application, Topologic-

Structure, allows the user to quickly build structural

models and apply structural loads in preparation for

structural analysis. The overall aim is to create a

mixed-dimensional topological shape by a list of ver-

tices and indices and apply structural loads to it. The

overall workﬂow consisted of: (a) creating the model

using an array of vertices and an array of vertex in-

dices, (b) deﬁning a list of locator points, and use

them to ﬁnd the closest simplest sub-shape of the

model, (c) Apply various kinds of structural loads to

these sub-shapes (see ﬁgure 7).

Creating the model using an array of vertices and

an array of vertex indices. We start by creating a

list of vertices, and a list of vertex indices (see ﬁg-

ure 7-1). This is akin to creating a mesh from the

same set of inputs. However, here we are creat-

ing a cluster of mixed-dimensional topology, con-

sisting of columns, walls, and spaces. We save the

vertices and vertex indices as CSV ﬁles and load

them in Dynamo using its built-in CSV ﬁle reader.

We then pass the list of vertices and vertex indices

to the Topology.ByVertexIndices() node, which con-

verts each row in the data into an independent Topo-

logic entity. The node returns a list of entities - one for

each row in the CSV ﬁle. We then pass this list to Clus-

ter.ByTopology() node to create a Topologic Cluster.

The ﬁnal step is to self-merge the cluster in order to

remove all duplicates, create higher-dimensional en-

tities where possible and topologically connect enti-

ties where appropriate (see ﬁgure 7-2).

Selecting sub-shapes to which the loads will be ap-

plied. To identify sub-shapes to which we would

like to apply structural loads, we use a collection

of point locators that fall on or near the desired

sub-shapes (see ﬁgure 7-3). We connect the con-

structed model and the locator points to the Topol-

ogy.ClosestSimplestSubshape() node, to ﬁnd which

“simplest” sub-shapes are closest to the locator

points (see ﬁgure 7-4). A sub-shape A is simpler than

another sub-shape B if it has a lower dimension (e.g.

a vertex is simpler than an edge, and an edge is sim-

pler than a surface etc).

Applying structural loads to the model. In Topo-

8|eCAADe 36 - Draft

Figure 7

TopologicStructure

example workﬂow.

logicStructure, we implemented a mechanism to ap-

ply loads to a topological shape (see ﬁgure 7-5). A

single load is applied to a point location on an entity.

A group of loads is called a LoadCluster, and it can be

applied to an edge (linear loads) or to a face (surface

loads). A LoadCluster is only valid if all of its loads are

within the valid range of the edge/face, otherwise an

error message is generated. Loads can have direction

and magnitude and are applied to a parametric loca-

tion on the target entity. For linear loads we use both

a u translation and a u scale to apply the loadCluster

to a region of the edge. Similarly, surface loads use

a u and v translation, scale, and rotation applied to

the loadCluster to locate it within a speciﬁc region of

the target surface. Topologic models without forces

(see ﬁgure 7-6) can then be combined with those that

have forces applied to them (see ﬁgure 7-7). The re-

sulting topological model is highly compatible with

structural analysis software input requirements (see

ﬁgure 7-8). We are currently implementing a link to

such software and will report on our progress in a fu-

ture publication.

Topologic and its associated tools are under ac-

tive development. The core toolkit is designed to

be platform-independent and allow third-party de-

velopers to build domain-speciﬁc software. Topo-

logicEnergy and TopologicStructure, as described

above, serve as demonstrative domain-speciﬁc ap-

plications for energy analysis and structural analysis

that can act as templates for others to follow. We

are in discussions with our industrial partners to in-

tegrate Topologic with their workﬂows and tools and

will report on that in future publications.

CONCLUSION

Manifold modelling, while needed in later stages of

design to create the models of the fabric and com-

ponents of buildings, is too complex and cumber-

some in the early stages of design and hinders the

use of building performance simulation. Topologic

aims to address these issues by introducing a rigor-

ous class hierarchy and a set of methods that are able

to manage both manifold and non-manifold topolo-

gies. The combination of non-manifold topology

and a versatile 3D software kernel has the poten-

tial to provide a comprehensive solution for archi-

tects while maintaining design creativity and ﬂexibil-

ity. The development of Topologic has made it clear

that there is a need to further investigate and con-

duct user-testing of innovative methods for creating,

displaying and interacting with geometric, topolog-

ical data using advanced interfaces and information

theory. Ultimately, our aim is to help architects and

engineers to: “[...] build the lightest possible model

using the least eﬀort that gives the most accurate

feedback about their design and engineering con-

cepts” (Aish & Pratap 2013).

ACKNOWLEDGEMENTS

This research project is a collaboration between

Cardiﬀ University and University College, London and

is funded by a Leverhulme Trust Research Project

Grant (Grant No. RPG-2016-016). We would like

to thank the National Renewable Energy Labora-

tory (Daniel Macumber), BuroHappold Engineering

(Al Fisher), and Grimshaw architects (Radu Gidei) for

their help with and contribution to this project.

Draft - eCAADe 36 |9

REFERENCES

Aish, R and Pratap, A 2013, ’Spatial Information Model-

ing of Buildings Using Non-Manifold Topology with

ASM and DesignScript’, in Hesselgren, L, Sharma, S,

Wallner, J, Baldassini, N, Bompas, P and Raynaud, J

(eds) 2013, Advances in Architectural Geometry 2012,

Springer Vienna, Vienna, pp. 25-36

Al-Jokhadar, A and Jabi, W 2017 ’Vernacular Neighbour-

hoods as Models for Socially-Sustainable Vertical

Cities: A Computational Approach’, Proceedings of

SDBE 2017: the International Conference for Sustain-

able Design of the Built Environment, London, pp. 76-

87

Attia, S, Hensen, JLM, Beltrán, L and De Herde, A 2011,

’Selection Criteria for Building Performance Simula-

tion Tools: Contrasting Architects’, Journal of Build-

ing Performance Simulation, 5(3), pp. 155-169

Chang, T and Woodbury, R 1997 ’Eﬃcient Design

Spaces of Non-manifold Solids’, Second Conference

on Computer-Aided Architectural Design Research in

Asia, Taiwan, pp. 335-344

Chatzivasileiadi, A, Lannon, S, Jabi, W, Wardhana, NM

and Aish, R 2018 ’Addressing Pathways to En-

ergy Modelling Through Non-manifold Topology’,

SIMAUD 2018: Symposium on Simulation for Architec-

ture and Urban Design, Delft, the Netherlands

Chatzivasileiadi, A, Wardhana, NM, Jabi, W, Aish, R and

Lannon, S 2018 ’A Review of 3D Solid Modeling Soft-

ware Libraries for Non-manifold Modeling’, Proceed-

ings of CAD’18 - the 15th Annual International CAD

Conference, Paris, France

Ching, FDK 2014, Architecture: Form, Space, and Order,

John Wiley & Sons

Crawley, DB, Lawrie, LK, Pedersen, CO and Winkelmann,

FC 2000, ’EnergyPlus : Energy Simulation Program’,

ASHRAE Journal, 42(4), pp. 49-56

Curtis, WJR 1996, Modern Architecture Since 1900, Pren-

tice Hall PTR

Ellis, PG, Torcellini, PA and Crawley, DB 2008 ’Energy De-

sign Plugin : An EnergyPlus Plugin for SketchUp’,

IBPSA-USA SimBuild 2008 Conference, Berkeley, Cali-

fornia, pp. 238-245

Guglielmetti, R, Macumber, D and Long, N 2011 ’Open-

Studio : An Open Source Integrated Analysis Plat-

form’, BuildingSimulation 2011: 12th Conference of In-

ternational Building Performance Simulation Associa-

tion, Sydney, Australia, pp. 442-449

Hils, DD 1992, ’Visual languages and computing survey:

Data ﬂow visual programming languages’, Journal of

Visual Languages & Computing, 3(1), pp. 69-101

Jabi, W 2013, Parametric Design for Architecture, Laurence

King Publishing

Jabi, W 2016, ’Linking Design and Simulation Using

Non-manifold Topology’, Architectural Science Re-

view, 59(4), pp. 323-334

Jabi, W, Soe, S, Theobald, P, Aish, R and Lannon, S

2017, ’Enhancing Parametric Design Through Non-

manifold Topology’, Design Studies, 52, pp. 96-114

Lee, SU, Roh, MI, Cha, JH and Lee, KY 2009, ’Ship Com-

partment Modeling Based on a Non-manifold Poly-

hedron Modeling Kernel’, Advances in Engineering

Software, 40(5), pp. 378-388

Marttila-Kontio, M 2011, Visual Data Flow Programming

Languages: challenges and opptortunities, Ph.D. The-

sis, University of Eastern Finland

Marttila-Kontio, M, Ronkko, M and Toivanen, P 2009,

’Visual Data Flow Languages With Action Systems’,

Proceedings of the International Multiconference on

Computer Science and Information Technology, IMC-

SIT, 4(November 2009), pp. 589-594

Nguyen, TD 2011, Simplifying The Non-Manifold Topology

Of Multi-Partitioning Surface Networks, Ph.D. Thesis,

Washington University

Pont, G 2005, ’The Education of the Classical Architect

from Plato to Vitruvius’, Nexus Network Journal, 7(1),

pp. 76-85

Wardhana, NM, Chatzivasileiadi, A, Jabi, W, Aish, R and

Lannon, S 2018 ’Bespoke Geometric Glazing Design

for Building Energy Performance Analysis’, MonGe-

ometrija 2018, Novi Sad, Serbia

Woodbury, R 2010, Elements of Parametric Design, Rout-

ledge

[1] http://en.wikipedia.org/wiki/Topology

[2] http://knowledge.autodesk.com/support/maya-lt/l

earn-explore/caas/CloudHelp/cloudhelp/2015/EN

U/MayaLT/ﬁles/Polygons-overview-Twomanifold-

vs–nonmanifold-polygonal-geometry-htm.html

[3] http://www.shapeways.com/tutorials/ﬁxing-non-m

anifold-models

[4] http://knowledge.autodesk.com/support/revit-pro

ducts/getting-started/caas/CloudHelp/cloudhel

p/2018/ENU/Revit-GetStarted/ﬁles/GUID-FE8EF5

B8-D1F4-4100-8C33-B2F710A82CFE-htm.html

[5] http://www.rhino3d.com

[6] http://www.bentley.com/en/products/product-line

/modeling-and-visualization-software/generati

vecomponents

[7] http://www.opencascade.com

[8] http://www.shapeop.org

[9] http://dynamobim.org

[10] http://grasshopper3d.com

10 |eCAADe 36 - Draft