Conference PaperPDF Available

Visual Dataflow Modelling: Some thoughts on complexity

  • White Lioness Technologies

Abstract and Figures

Coming soon...
Content may be subject to copyright.
Visual Dataflow Modelling
Some thoughts on complexity
Patrick Janssen
National University of Singapore
When visual programming is applied to design, it results in a parametric
modelling approach that we refer to as Visual Dataflow Modelling (VDM). This
paper reviews existing VDM environments and identifies key issues that result in
dataflow graphs with high complexity. In order to explore how these issues could
be overcome, a new VDM environment is being developed, called Vidamo. For
any given parametric modelling task, Vidamo aims to support a style of VDM
where the complexity of the dataflow graph remains commensurate with the
complexity of the task. An initial experiment is conducted in which the existing
environments and the proposed Vidamo environment are used to complete the
same parametric modelling task. The results indicate that the dataflow graphs
created using Vidamo are much smaller and less complex.
Keywords: parametric and generative modelling, visual dataflow modelling,
cyclomatic complexity
Visual programming languages enable users to cre-
ate computer programs by manipulating graphical
elements rather than by entering text. In the design
domain, visual programming can be used as a para-
metric modelling approach that we refer to as Visual
Dataflow Modelling (VDM) (Janssen and Chen 2011).
The appeal of VDM environments lies in the fact that
complex form generating procedures can be created
without having to learn programming. However, a
well known problem with these environments is that
the complexity of the dataflow graphs can quickly
become unmanageable.
Analysing dataflow graphs created using exist-
ing VDM environments, three key issues are identi-
fied: too many links, too many nodes, and confusing
iteration. In general, it would seem that it should be
possible to create typical parametric models using far
fewer nodes linked together in more linear ways us-
ing iteration that is easier to understand. In order to
address these issues, a new more scalable VDM envi-
ronment is being developed, called Vidamo, support-
ing a hybrid style of visual programming that allows
larger and more complex types of parametric mod-
els to be created. At this stage, this environment is
in the early stages of conceptualization. This paper
discusses some of the early design decisions.
The paper first gives an overview of four com-
monly used existing VDM environments. The pro-
posed VDM environment is then described, high-
Design Tool 2 - Volume 2 - eCAADe 32 |547
lighting how limitations of the existing environments
are overcome. Finally, the conclusions summarises
the results and indicates future research directions.
Four commonly used VDM environments are anal-
ysed: M cNeel Grasshopper 0.9 [1], AutodeskD ynamo
0.7 [2], Bentley Generative Components v8 [3], and
Sidefx Houdini 13 [4]. Other design environments
that incorporate VDM include CityEngine by Esri [5],
3DVia Studio by Dassault [6], and the Sverchok plugin
for Blender [7].
The four VDM environments all make use of
dataflow graphs consisting of nodes and links. Nodes
represent some type of operation and links represent
the flow of data between these operations. Nodes
have input ports and output ports and can have pa-
rameters that affect their behaviour. (In some envi-
ronments, parameters are treated the same way as
inputs, while in some these are treated differently.)
One important restriction that has been imposed
is that multi-line scripting is disallowed, as this is seen
to be challenging for many designers (see for exam-
ple Senske 2014). The use of single-line expressions
is however considered to be acceptable since it does
not require users to have any advanced knowledge
of scripting or programming.
Modelling task
In order to be able to analyse the types of dataflow
graphs generated by these four environments, all of
them were used to complete a simple parametric
modelling task. The chosen task is the Kilian Roof,
based on a tutorial for Generative Components de-
veloped by Axel Kilian in 2005. The task consists
of building a simple parametric roof with a diagrid
structure (Woodbury at al. 2007). The ridge of the
roof remains at a constant height while the base of
the structure varies in height in response to an un-
dulating ground surface. The task consists of a linear
sequence of modelling steps, loosely defined as fol-
1. Centreline Coordinate Systems: Create a set
of coordinate systems oriented along the cen-
treline. The centreline consists of a spline as-
sumed to be lying on an undulating ground
surface. The coordinate systems are arrayed
along the centreline, orientated perpendicu-
lar to the centreline and the global z-axis.
2. Hoop Sections: Use the coordinate systems to
construct a set of hoop sections, consisting of
spline curves orientated perpendicular to the
centreline. The hoop sections are scaled so as
to ensure that the roof ridge remains at a con-
stant height.
3. Roof Surface: Use the hoop sections to create
a discretised roof surface. The hoop sections
are first lofted to create spline surface, and the
spline surface is then discretised into a grid of
four sided components.
4. Roof Modules: Use the roof components to
create a set of roof modules consisting of X
frames. The X frames connect diagonal cor-
ners of each component, with the frame diam-
eter being proportional to the length. When
all components are replaced by these frames,
a diagrid structure results.
In the following sections, each VDM environment is
analysed. First, three key aspects of each environ-
ment are described: the way nodes are used; the
way links are used; and the way iteration is han-
dled. These aspects strongly influence the types of
dataflow graphs that are generated. A brief descrip-
tion is then given of how each VDM environment was
used to build the Kilian roof.
Nodes may process either geometric data or non-
geometric data. For geometric data, nodes are pro-
vided to create, modify and delete geometry. For
non-geometric data, nodes are provided for vari-
ous operations, including logical, scalar, and vector-
based operations. Many of the nodes tend to per-
form fairly simple types of operations.
548 |eCAADe 32 - Design Tool 2 - Volume 2
Links are created by the user connecting nodes in
the graph. Both geometric data and non-geometric
data is represented in the same way, as trees. A tree
is a sorted collection of lists, where each list is identi-
fied by a path. A specific path can only occur once in
a tree. When t wotrees are merged, lists with identical
paths are appended to each other.
Iteration results from nodes iterating over lists
in trees using a data matching algorithm. This algo-
rithm looks at the inputs, and selects the data tree
with the longest path to be the 'master' tree. The al-
gorithm then iterates over the lists in this master tree
and generates an output tree with matching paths. If
the master tree has fewer lists than some of the other
inputs, then the algorithm automatically generates
the missing input data by duplicating the last list in
the master tree. ( This data matching algorithm is new
since version 0.9)
For the modelling task, the coordinate systems
were generated as frames along the centreline curve
and a hoop section was copied onto each frame. A list
of origin points was extracted from the frames and
used to calculate a list of scale factors. These were
then used to scale the hoop sections. The hoops were
lofted to create a surface, which was then discretised
by dividing the surface into a set of patches. The cor-
ner points of the patches were then extracted and
used to generate two lists of corner point pairs. These
lists were then used to create the lists of diagonal X
lines, which were then piped, thereby creating the fi-
nal piped structure.
Nodes are similar to Grasshopper. Two additional
types of nodes are provided: code block nodes and
custom nodes. Code blocks allow users to write short
expressions inside a node to perform simple calcula-
tions. Custom nodes allow users to define their own
custom operations that can be saved as a separate file
and then used within parametric models in the same
way as the built-in nodes.
Links are also similar to Grasshopper, and are
created by the user connecting nodes in the graph.
Both geometric data and non-geometric data is rep-
resented using nested lists.
Iteration results from nodes iterating over data
items in nested lists. Users are given the option to se-
lect from three 'lacing' patterns: 'shortest', 'longest',
and 'cross product'. In addition, Dynamo supports
recursion using custom nodes, thereby allowing for
more complex types of iteration without requiring
any scripting.
For the modelling task, the process is the same as
in Grasshopper until the stage where the lofted sur-
face is created. I n Dynamo, this surface was then used
to generate a grid of points, and these points were
grouped into a list containing four sub-lists for the
four corner points. These lists are then used to create
the diagonal X lines, which were then piped, thereby
creating the final piped structure.
Generative Components
Nodes create new geometric entities. There are no
nodes for modify or delete existing entities (although
there is a node that transforms between coordinate
systems.) Nodes are specified in two stages: the user
first specifies the type of geometric entity to be cre-
ated and then specifies the method that will be used
to create that entity. Nodes do not output any non-
geometric data, but may require non-geometric data
as inputs. The dataflow graph is used mainly for vi-
sual feedback rather than for direct editing.
Links are created automatically by the system in
response to expressions written by the user. When
the user creates a new node, the parameters for the
node can be defined using expressions that link to
data within other nodes in the dataflow graph. Ge-
ometric data is represented using lists, with node in-
puts and outputs being handled in slightly different
ways. Nodes outputs are always flat lists of geomet-
ric entities of the same type (including compound
types). Node inputs may requiredifferent types of ge -
ometric and non-geometric data, structured either as
lists or as nested lists.
Iteration results from using nodes with input ar-
guments that are defined as being 'replicable'. This
Design Tool 2 - Volume 2 - eCAADe 32 |549
indicates that a list of inputs can be used, resulting
in the node iterating over these inputs. For meth-
ods with multiple parameters, users are given the op-
tion to toggle the replication pattern between one-
to-one replication and cross replication.
For the modelling task, the coordinate systems
were generated along the centreline curve and then
scaled, with the scale factor being calculated using
an expression. A hoop section was created and then
copied onto the scaled coordinate systems, resulting
in the hoops being automatically scaled to the right
size. The hoop sections were then lofted to create a
surface. A grid of points is then generated on the sur-
face, which were then used to generate a grid of poly-
gons. A component was defined that had a polygon
as the input and a pair of diagonal pipes as the out-
put. This component was then applied to the list of
polygons, thereby replacing each polygon with a di-
agonal pair of pipes.
Nodes process geometric data, including creating,
modifying, and deleting geometry. Nodes tend to
perform complex operations and may have many pa-
rameters that affect their behaviour.
Links may be of two types: links for geometric
data and links for non-geometric data. Geometric
links are created by the user connecting nodes in the
graph (similar to Grasshopper). Non-geometric links
are created by the user writing expressions that link
node parameters to data within other nodes in the
dataflow graph (similar to Generative Components).
Geometric data is represented using a topological
data structure consisting of three levels: points, ver-
tices, and primitives. Primitives are any type of geo-
metric entity, including lines, polygons, splines, and
so forth. The topological data structure supports
user-defined attributes at all three levels.
Iteration results from nodes iterating over lists of
geometric entities within the topological data struc-
ture. In order to support more complex types of con-
trol flow, 'switch' nodes and 'for-each' nodes can be
used. Complex nested loops can be created by nest-
ing 'for-each' nodes inside one another.
For the modelling task, the centreline curve was
converted into a polyline with equal segments, and
the vectors for the coordinate systems were then at-
tached as attributes to the points on the polyline. The
scale factors were calculated and also attached as at-
tributes to the same polyline points. A hoop sec-
tion was created and then copied onto each of the
points, with the section being automatically oriented
and scaled according to the point attributes. A sur-
face was then generated by lofting the hoop sections,
which was then converted onto a polygon surface. A
loop was then defined (using a 'for each' node) that
replaced each polygon with a diagonal pair of pipes.
Analysis of dataflow graphs
For all four VDM environment, the aim was to
model the Kilian roof using the minimum number of
nodes without resorting to multi-line scripting. In
Grasshopper and Dynamo, input nodes such as slid-
ers were not counted, as these are considered to
be optional. In Generative Components, multiple
points were generated using a single node (using the
Point.ByCoordinateList() method) rather than
one node for each point. In Houdini, the nodes
nested inside the 'for-each' node were also counted.
The four dataflow graphs for the Kilian roof were
analysed using three metrics: the number of nodes in
the graph, the number of links in the graph, and the
cyclomatic complexity of the graph (McCabe 1976).
Cyclomatic complexity is a metric for measuring code
structure by calculating the number of independent
paths through a directed acyclic graph. In order to
ensure that code is understandable and easily main-
tainable, it is typically recommended that the cyclo-
matic complexity should be no greater than 10. The
complexity M is then defined as:
M=EN+ 2 (1)
where E is the number of edges in the graph and N
is the number of nodes in the graph. Note that for
nodes that are connected using parallel links, only
one link is counted.
550 |eCAADe 32 - Design Tool 2 - Volume 2
The results are shown in the Table 1. Despite the in-
herent linearity of the modelling task, none of the en-
vironments resulted in graphs with cyclomatic com-
plexity of 1. For Grasshopper, Dynamo, and Genera-
tive Components, the results are similar, with an av-
erage of 24 nodes, 27 links, and a cyclomatic com-
plexity of 5. These numbers are seen to be very high
and reflect the fact that with these environments, the
complexity of the dataflow graph is not commensu-
rate with the complexity of the modelling task. Fur-
thermore, the results suggest that tasks with a more
realistic level of complexity will likely exceed the rec-
ommended cyclomatic complexity threshold of 10. A
similar conclusion was reached by Davis at al. (2011),
who analysed a wide range of dataflow graphs and
found that 60% of the models had a cyclomatic com-
plexity greater than 10, despite the fact that many
of the models were thought to be snippets of larger
more complex models.
The results for Houdini were markedly better.
This improvement was attributable to a number of
factors. First, fewer nodes were required due to
the fact that nodes in Houdini may perform more
than one modelling operation . Second, fewer links
were required due to the fact that data could be em-
bedded within the topological data structure as at-
tributes. Third, the iterative loop for creating the X
frames was easily handled with just a 'for each' node.
Table 1
Analysis of the
dataflow graphs
created using
existing VDM
'Nodes' is the
number of nodes,
'Links' is the
number of links,
and 'CC' is the
Another issue that was considered was comprehensi-
bility of the iterative behaviour of nodes. This was not
quantitatively measured, but was instead evaluated
subjectively through experience of working with all
four environments. The approach used by Grasshop-
per, Dynamo, and Generative Components, whereby
the node iterates over trees or nested lists, was found
to quickly get very complicated. Since nodes can
have multiple inputs, with each input possibly con-
sisting of some complex nested structure, the way
that the iteration will be executed can be very diffi-
cult to predict. For Houdini, iteration was less com-
plex and avoided the many data restructuring nodes
require in other environments. However, the be-
haviour of individual nodes is complex and it is gen-
erally very difficult for novice users to know which are
the right nodes to use.
One last issue to mention is the use of sub-
graphs (also referred to as 'clusters' or 'subnets'). All
four VDM environments allow users to create nodes
that contain a sub-graph. To some extent, this may
reduce complexity by enabling users to encapsulate
a closely related set of nodes as a single sub-graph.
However, it also has the critical downside that it ob-
fuscates the dataflow, requiring users to continually
navigate in and out of such sub-graphs.
The analysis of the dataflow graphs created using ex-
isting VDM environments resulted in the identifica-
tion in three key issues: too many nodes, too many
links, and confusing iteration. Too many nodes refers
to datafow graphs that get very large due to the
fact that each operation is represented by a sepa-
rate node, even when some are relatively trivial. Too
many links refers to dataflow graphs that get highly
tangled (also sometimes referred to as 'spaghetti
code') due to the fact that nodes tend to require
many inputs. Confusing iteration refers to dataflow
graphs that use techniques for iterating that are ei-
ther highly implicit, or when defined explicitly are
very complex.
For any given parametric modelling task, Vidamo
aims to support a style of VDM where the complexity
of the dataflow graph remains commensurate with
the complexity of the task. In order to achieve this,
Vidamo introduces two key features: a hybrid visual
programming approach and a topological data struc-
ture. Thehybrid approach allows nodes to be defined
that perform more than one operation. The topolog-
ical data structure allows complex sets of intercon-
nected geometric entities to be represented as a sin-
Design Tool 2 - Volume 2 - eCAADe 32 |551
Figure 1
The Vidamo
interface in a web
gle geometry collection.
The hybrid visual programming approach com-
bines two styles : the dataflow nodes-based style and
the procedural tile-based style. The dataflow style
is used to define an overall sequence of modelling
procedures, while the procedural style is used to de-
fine each individual procedure. (Note that this ap-
proach combines dataflow and procedural styles of
programming without needing to invent a new pro-
gramming language, as proposed by Aish (2013)).
The dataflow style can be traced back to the existing
VDM environments described above, while the pro-
cedural style can be traced back to tile-based visual
programming environments such as Scratch (Resnick
et al. 2009). The way that these various ingredients
are combined is novel and supports a more powerful
style of VDM that is capable of handling greater com-
The approach allows users to decide on the gran-
ularity of the dataflow graph. For the Kilian roof
modelling task, the user could decide to perform the
whole task using just a single node containing a pro-
cedure with 16 instructions, or they could decide to
break the task into 8 nodes, with each node contain-
ing a short procedure consisting of just a few instruc-
tions. In the example given in Figure 1, the task is
broken into 4 nodes. The 'Centreline Coord Sys' node
creates the centreline curve and uses it to create a set
of correctly orientated coordinate system. The 'Hoop
Sections' node creates a hoop section on each coor-
dinate system and scales each section by the appro-
priate amount. The 'Roof Surface' node lofts the sec-
tion curves to create a roof surface and then converts
this into a polygon surface. The 'Roof Modules' node
replaces each polygon on the roof surface with a di-
agonal pair of pipes. The 'Hoop Sections' and 'Roof
Surface' nodes are described in more detail below.
Vidamo is being developed as a web-application
that will run entirely in the browser. Figure 1 shows a
sketch of the proposed user-interface, showing three
types of views: the graph view, the geometry view,
and node view. The graph view displays the dataflow
graph. The geometry has two modes: a 3D mode that
shows the model or a spreadsheet mode, called the
'Data Grid'. The latter allows geometry to be viewed
as data, with every row in the spreadsheet represent-
552 |eCAADe 32 - Design Tool 2 - Volume 2
ing one geometric entity. The node view has three
tabs: the 'Interface' tab allows users to customize the
node's user interface, including adding various inter-
face components such as sliders and tick boxes; the
'Procedure' tab allows users to define the node's un-
derlying procedure using a tile-base visual program-
ming style; and the 'Code' tab allows users to inspect
the generated code. In this paper, only the geometry
3D mode and the 'Procedure' tab will be discussed.
The information that is displayed in the geome-
try or the node view is dependent on what is selected
in the graph view, with two types of selection be-
ing possible: selecting a port and selecting a node.
The geometry view displays the data that is passing
through the selected port. In Figure 1, one of the out-
put ports of the Roof Module nodes is selected (as
shown by the black circle), and the geometry view
therefore shows the roof X modules. The node view
displays the information for the selected node. In
Figure 1, the 'Hoop Sections' node is selected, and
the node view therefore shows the procedurefor that
node. Theseprocedures will be described in more de-
tail below.
Fewer nodes
In order to reduce the number of nodes, Vidamo uses
nodes capable of executing a procedure consisting
of more than one operation. For all geometric oper-
ations, there is only one type of node, which acts as a
generic container for a geometric procedure.
The generic geometry node can have an arbi-
trary number of inputs and outputs. Nodes may have
no inputs, in which case the procedure will generate
geometry from scratch. Nodes with no outputs are
possible, but are only used for specific purposes such
as writing files. Node input and output data may con-
sist of either geometric data or non-geometric data.
For geometric data, the data is represented using a
topological data structure (see section "Fewer Links").
For non-geometric data, the data can be structured
as either flat or nested lists.
When a user adds a generic geometry node to
the graph, they need to define the procedure for
that node. Procedures are created by inserting three
types of instructions: data instructions, action in-
structions, and control instructions. Data instructions
get and set data to local variables and input and out-
put ports. Action instructions perform any types of
geometric operations. Control instructions consist
of control flow statements such as 'for' loops, 'while'
loops, and 'if' statements.
Figure 2
The node view for
the 'Roof Surface'
node. (a)
Instructions with
collapsed settings.
(b) Instructions with
expanded settings.
(c) The node in the
dataflow graph.
Figure 2 shows the 'Roof Surface' node with a proce-
dure consisting of four instructions: a data instruc-
tion, two action instructions, and another data in-
structions. Each instruction is defined by a number
of settings that can be collapsed or expanded. Fig-
ure 2 (a) shows the collapsed settings, while Figure
2 (b) shows the expanded settings. In order to spec-
Design Tool 2 - Volume 2 - eCAADe 32 |553
ify the action to be performed, the user must select
a method using a series of nested menus. Once the
method is selected, parameter boxes are then dy-
namically generated so that the user can specify the
values for the method parameters.
The data instructions read and write data to
the input and output ports. For reading data, the
GetInput() method is used, and for writing data,
the SetOutput() method is used. For the first ac-
tion, the BSplineSrf.ByLoft() method has been
selected which generates a BSpline surface by loft-
ing a set of section polylines. The surface is assigne
to the local variable bs_srf. The section lines are
specified by the expression hoop_sections.edges,
which refers to a set of curves in the topological data
structure (see section "Fewer Links"). For the sec-
ond action, PolySrf.FromBSplineSrf() method
has been selected which generates a polygon sur-
face from a BSpline surface. The polygon surface is
assigne to the local variable poly_srf. The BSpline
surface is the one created by the previous action,
Fewer links
In order to create graphs that are less tangled,
Vidamo uses a topological data structure capable
of representing geometric relationships and storing
non-geometric data. The use of such a data struc-
ture means that many of the relationships between
geometric entities do not have to be represented in
the dataflow graph, but are instead an integral part of
the data structure (which is itself a graph). The data
structure and underlying geometric entities are de-
fined using the Open Cascade modelling kernel [8].
A set of geometric entities represented using the
topological data structure is referred to as a 'geom-
etry collection'. Within such a collection, complex
shapes are modelled as assemblies of simpler shapes.
Table 2 lists the eight types of shapes defined by the
OpenCascade kernel. These shapes are abstract en-
tities that are associated with underlying geometric
entities. For example, a model may contain a number
of edges, each of which may be associated with a dif-
ferent type of geometric entity, such as a line, an arc,
or a BSpline curve. A geometry collection can there-
fore contain a large number of geometric entities re-
lated to one another in complex ways.
Table 2
The eight
typological shapes
available in
For the 'Roof Surface' node described above, the in-
put and output data are both geometry collections.
The input collection consists of vertices and edges,
with the vertices being points and edges being the
BSpline curves. The output collection consists of five
topological levels, from vertices to shells. The ver-
tices are points, the edges are straight lines, the wires
are sets of four connected lines, the faces are poly-
gons, and the shell is a set of connected polygons.
The topological data structure allows lower level
entities to be extracted from higher level entities us-
ing simple expressions. The expressions specify data
queries using the topological level as a way of navi-
gating through the data structure. For example, the
expression input1.edges[1].vertices[0].z will
return the z coordinate of the first point of the of the
second curve in the collection input1. This ability to
extract specific pieces of data from deep within the
geometric collection means that nodes often only
need a single input, thereby significantly reducing
the numbers of links that are required in the dataflow
Explicit iteration
In order to reduce the obfuscation of iteration, Vi-
damo allows iteration to be explicitly specified us-
ing loops, thereby giving users complete control over
the iterative process. Loops fall under control flow
instructions, which are one of the three instruction
types that can be created for node procedures.
554 |eCAADe 32 - Design Tool 2 - Volume 2
The ability to add control flow to the procedures
makes this approach Turing complete, theoretically
allowing procedures of arbitrary complexity to be de-
fined. Figure 3 show the procedure for 'Hoop Sec-
tions' node, which includes a 'for loop'. As can be
seen in Figure 1, this 'Hoop Sections' node actually
precedes the 'Roof Surface' node sown in Figure 2.
Figure 3
The node view for
the 'Hoop Sections'
node that includes
a loop. (a) The
procedure showing
a list of instructions
with expanded
settings. (b) The
node in the
dataflow graph.
In order to create the hoops, the node has to iterate
over each of the coordinate systems in the input ge-
ometry collection. The coordinate systems are cre-
ated and oriented by the 'Centreline Coord Sys' node.
Since the hoop sections lie on a flat plane, 2D coordi-
nate systems have been used, defined as a set of ver-
tices in the topological data structure.
The 'for loop' is the second instruction in the pro-
cedure shown in Figure 3. The type of 'for loop' that
has been used in this case is the 'for item in list' type,
which iterates through a list of items. For the settings,
the 'Item Name' defines the name of a local variable
whose value will be equal to the item, and 'List' refers
to the list of items to be iterated through.
Inside the loop, four instructions have been de-
fined: three action instructions and one data instruc-
tion. The first action creates four 2D points on the
2D coordinate system. The second action create a 2D
BSpline curve through these points and assigns it to
a local variable called hoop. The third action scales
the hoop by a factor that ensures that the roof ridge
line will remain at a constant height. The final instruc-
tion is the data instruction, which appends the scaled
hoop to the geometry collection for the node output.
Analysis of the dataflow graph
The dataflow graph shown in Figure 1 has 4 nodes
and 3 links, and therefore has a cyclomatic com-
plexity of 1. Furthermore, even if more nodes were
used, there would still be no need to create a non-
linear graph and therefore the cyclomatic complex-
ity would remain the same. For example, another
user might decide to split the 'Centerline Coord Sys'
node into two: one node to create the centreline and
another to place coordinate systems along that line.
This would result in 5 nodes with 4 links, which would
still have a cyclomatic complexity of 1.
The reason that the linearity of the dataflow
graph can be maintained is due to the fact that the
parametric modelling task is itself liner. This is of
course not always the case. More complex para-
metric models may require non-linear graphs. How-
ever, with Vidamo the user can ensure that the com-
plexity of the dataflow graph remains commensu-
rate with the complexity of the parametric modelling
Design Tool 2 - Volume 2 - eCAADe 32 |555
task. This is not the case with existing VDM environ-
ments, where the complexity of the dataflow graph
will typically be significantly higher than the com-
plexity of the parametric modelling task.
Four existing VDM environments were used tomodel
the Kilian roof and the resulting dataflow graphs
were analysed. Considering the simplicity of the task,
the size and complexity of the dataflow graphs was
found to be very high.
Vidamo is a new type of VDM environment that
results in dataflow graphs that are are much much
smaller and less complex. I t achieves this byintegrat-
ing two key features: a hybrid visual programming
approach and a topological data structure. The hy-
brid approach uses the dataflow nodes-based style
for defining a sequence of procedures and the proce-
dural tile-base style for defining each individual pro-
cedure. The topological data structure defines a hi-
erarchy of shapes that allows complex shapes to be
modelled as assemblies of simpler shapes.
Vidamo is in the early design stages, and there-
fore the modelling of the Kilian roof was conducted
as a theoretical exercise. The use of a hybrid ap-
proach combined with a topological data structure
allowed the Kilian roof example to be modelled us-
ing significantly smaller dataflow graphs with a cyclo-
matic complexity of only 1. Furthermore, due to the
explicit way that loops are represented, it is argued
that the comprehensibility of the iterative behaviour
is much better than in existing VDM environments.
The future development of Vidamo will focus
on three areas: support for debugging, support for
linking to third-party tools (such as simulation pro-
grams), and support for generating data-rich models
(such as Building Information Models). These are all
areas in which current VDM environments are lack-
Aish, R 2013 'DesignScript: Scalable Tools for Design
Computation', Proceedings of the 31st eCAADe Con-
ference, Delft, The Netherlands, pp. 87-95
Davis, D 2013, Modelled on Software Engineering: Flexi-
ble Parametric Models in the Practice of Architecture,
Ph.D. Thesis, RMIT University
Davis, D, Burry, J and Burry, M 2011, 'Understanding Vi-
sual Scripts: Improving collaboration through mod-
ular programming', International Journal of Architec-
tural Computing, 9, pp. 361-376
Janssen, P and Chen, KW 2011 'Visual Dataflow Mod-
elling: A Comparison of Three Systems', Proceed-
ings of the 4th International Conference on Com-
puter Aided Architectural Design Futures (CAAD Fu-
tures 2011), Liege, Belgium, pp. 801-816
McCabe, T 1976, 'A Complexity Measure', IEEE Transac-
tions on Software Engineering, 2, pp. 308-320
Resnick, M, Silverman, B, Kafai, Y, Maloney, J and
Monroy-Hernández, A 2009, 'Scratch: programming
for all', Communications of the ACM, 52, p. 60
Senske, N 2014 'Confronting the Challenges of Computa-
tional Design Instruction', Proceedings of the 19th In-
ternational Conference on Computer-Aided Architec-
tural Design Research in Asia, Kyoto, Japan, pp. 821-
Woodbury, R, Aish, R and Kilian, A 2007 'Some Patterns
for Parametric Modeling.', 27th Annual Conference of
the Association for Computer Aided Design in Architec-
ture, Halifax, Nova Scotia, p. 222–229
556 |eCAADe 32 - Design Tool 2 - Volume 2
... The analysis of parametric models created by two different Computational Design Specialists (CDSs) (see, Fig. 2.3a and 2.3b), in one of our previous works, is reminiscent of the same issues which led to the software crisis in 1960s. After a careful literature study, we have concluded that the same problem has been highlighted by others as well [Dav14,Jan14]. In our work, we are looking at some of the potential solutions to improve the current situation in parametric modelling. ...
... The analysis of parametric models created by two different Computational Design Specialists (CDSs) (see, Fig. C.1a and C.1b), in one of our previous works, is reminiscent of the same issues which led to the software crisis in 1960s. After a careful literature study, we have concluded that the same problem has been highlighted by others as well [Dav14,Jan14]. ...
Full-text available
The construction industry has been plagued by low productivity for quite sometime now. Automation is considered as a viable way forward to improve the situation. The industry has not witnessed proliferation of robotic technologies as seen in other fields like manufacturing due to high levels of project specificity, smaller lot sizes for production and need for customization, thus causing the sector to remain vastly under-served. In this work, we focus on developing a software framework (Sculptor), which will help the industry to rapidly design, prototype, develop, and test robotic applications. An application is said to be understood as a cyber-physical system which contains one or more robotic manipulators equipped with necessary end-effectors and a tablet based interface to help a novice user to easily program the system. Architects find it convenient to express such robotic processes using parametric (data flow) models. These models come with some known drawbacks related to stability, maintainability, latency and re-usability. After having developed Sculptor, we are trying to address some of the above stated problems by applying methods like software design patterns. Further, the framework was used to develop multiple commercial applications to evaluate its effectiveness.
... The relative advantages and disadvantages between VPLs and TPLs have already been discussed in several studies (Leitão and Santos 2011, Davis et al. 2011, Leitão et al. 2012, Janssen 2014, Zboinska 2015. However, in the current practice of architecture, there is a clear propensity to the use of VPLs over TPLs, due to the user-friendly features and interactive mechanisms they provide that are absent in most textual approaches. ...
... Although it is possible to use the interaction mechanisms available in visual programming to manipulate code in VR, the complexity of the models that most benefit from immersive visualization make visual programming an inviable solution. Despite being more difficult to learn, textual programming languages tend to offer more expressive power, scalability, flexibility, and efficiency than visual ones [34,35]. Hence, we propose to enrich the design experience by integrating a textual-based AD practice, which natively supports extensive design changes, with VR, an intrinsically interactive and immersive medium. ...
Full-text available
Virtual reality has been shown to facilitate perception and navigation inside 3D models, while stimulating creativity and enhancing architect/client interaction. In this scenario, in order to better explore paths along the design space that are suggested from this interaction, it is important to support quick updates to the model while still immersed in it. Algorithmic design, an approach to architectural design that uses parametric algorithms to represent a design space, rather than a single design instance, provides such support. We present a novel architectural design process based on the integration of live coding with virtual reality, promoting an immersive approach to algorithmic design. The proposed workflow entails the use of an algorithmic design tool embedded in a virtual environment, where the architect not only creates the design but also interacts with said design, changing it by live coding its algorithmic representation from within virtual reality. In this paper, we explain the challenges faced and solutions devised for the implementation of the proposed workflow. Moreover, we discuss the applicability of algorithmic design in virtual reality to different stages of the architectural design process and the future developments that may arise from this proposal.
Two main concerns drive the architectural practice: the design and the construction of buildings. This makes the creative practice highly dependent on construction viability, most design decisions having to consider, among others, the available materials and construction techniques and the associated manufacturing costs. Nevertheless, the desire to conceive complex geometries has always been present in architecture, often leading to innovative solutions and structures that go beyond what had been done to date. The emergence of computational design in the last decades has further accentuated this ambition by providing architects with unprecedented design freedom. The realization of such shapes, however, is not as easy as its 3D modeling due to limitations in the available manufacturing strategies. In this paper, we address this problem with Algorithm Design (AD), a design approach based on algorithms, presenting a design workflow that benefits from its (1) geometric freedom in developing facade design solutions and (2) expressiveness in converting and detailing the obtained solutions for manufacturing. We evaluate our proposal with an algorithmically developed prototype of a geometrically complex facade. The aim is to illustrate its potential in exploring design alternatives that consider multiple design criteria, while automatically detailing them for construction and producing the corresponding technical documentation. We also intend to demonstrate the importance of the proposal’s flexibility in considering different construction schemes that, in turn, result in different aesthetic outcomes and manufacturing needs.KeywordsAlgorithmic designFacade designDesign-to-FabricationDesign workflow
Full-text available
In the digital age of architecture, parametric design plays an essential role in the generative process of architectural design. The most important benefits of parametric design are having the visual representation of the design process, enabling the interaction of user during the generation of parametric model using visual digital codes, the representation of design steps sequentially and logically, and also the possibility to adapt the design model according to the customer's requirements and the designer's desires generating alternative design solutions for the same model. A parametric typology is an approach that combines typological design and computational parametric techniques to produce a variety of designs belonging to a specific building type. It facilitates the customization in housing design. The parametric typological design allows diversity, variation, and individualisation just as easily as the mass-standardized production. This research investigates the customization of housing components to satisfy the customer's needs. The research reviewed many previous studies that adopted the parametric typological approach in architectural design, ranging from general to specific studies. Accordingly, the research problem has been identified as the lack of a clear perception about the parametric typological approach that is customizable, to be applied in the design of single-family housing within a local residential complex in Mosul city. The research aim is to apply the parametric typological approach in the generation of customizable single-family housing designs in response to the customer's choices. To achieve the aim, the research methodology was to build a theoretical framework for the customization using parametric typological approach, The framework included three components that define the stages of the parametric typological design and the sequence of steps, the implementation of customization in the parametric typological design, and the computerized parametric techniques used in the application of customization. Later, some of the framework’s components were applied to generate new typological designs belong to a local project of single-family housing to meet various requirements of customers. The results of the study show the efficiency of applying customization in the parametric typological design process. The proposed algorithm proved its effectiveness in generating wide range of design alternatives. From six original design prototypes of Ain Aliraq Housing project in Mosul, the study generated 96 varied prototype plans for the ground floor, 1920 prototype plans for the first floor, and 069 three-dimensional facades. All design alternatives were generated from a single parametric model implemented in Grasshopper for Rhino without the use of ready-made software. The user interface presented in this study simplifies the design process for the customer. Where the process of selecting parameters is sequential and having the possibility of backtracking.
In the last few decades, architecture has experienced paradigm shifts prompted by new computational tools. Algorithmic design (AD), a design approach based on algorithms, is one such example. However, architectural design practice is strongly based on visual and spatial reasoning, which is not easy to translate into algorithmic descriptions. Consequently, even using tailored AD tools, AD programs are generally hard to understand and develop, independently of one’s programming abilities. To address this problem, we propose a methodology and a design environment to support AD in a way that is more akin to the workflow typically employed by architects, who represent their ideas mostly through sketches and diagrams. The design environment is implemented as a computational notebook, with the ability to intertwine code, textual descriptions, and visual documentation in an integrated storytelling experience that helps architects read and write AD programs.
Full-text available
Internet-of-Things has reshaped the way people interact with their surroundings and automatize the once manual actions. In a smart home, controlling the Internet-connected lights is as simple as speaking to a nearby conversational assistant. However, specifying interaction rules, such as making the lamp turn on at specific times or when someone enters the space is not a straightforward task. The complexity of doing such increases as the number and variety of devices increases, along with the number of household members. Thus, managing such systems becomes a problem, including finding out why something has happened. This issue lead to the birth of several low-code development solutions that allow users to define rules to their systems, at the cost of discarding the easiness and accessibility of voice interaction. In this paper we extend the previous published work on Jarvis [1], a conversational interface to manage IoT systems that attempts to address these issues by allowing users to specify time-based rules, use contextual awareness for more natural interactions, provide event management and support causality queries. A proof-of-concept is presented, detailing its architecture and natural language processing capabilities. A feasibility experiment was carried with mostly non-technical participants, providing evidence that Jarvis is intuitive enough to be used by common end-users, with participants showcasing an overall preference by conversational assistants over visual low-code solutions.
The importance of Algorithmic Design (AD) is growing due to its advantages for the design practice: It empowers the creative process, facilitating design changes and the exploration of larger design spaces in viable time, and supports the search for better-performing solutions that satisfy environmental demands. Still, AD is a complex approach and requires specialized knowledge. To promote its use in architecture, we present a mathematics-based framework to support architects with the algorithmic development of designs by following a continuous workflow embracing the three main design stages: exploration, evaluation, and manufacturing. The proposed framework targets the design of buildings’ facades due to their aesthetical and environmental relevance. In this paper, we explain the framework’s structure and its mathematical implementation, and we describe the predefined algorithms, as well as their combination strategies. We focus on the framework’s algorithms that generate different geometric patterns, exploring their potentialities to create and modify different facade designs. In the end, we evaluate the flexibility of the framework for generating, modifying, and optimizing different geometrical patterns in an architectural design context.
Algorithmic Design (AD) uses computer programs to describe architectural models. These models are visual by nature and, thus, greatly benefit from immersive visualization. To allow architects to benefit from the advantages of Virtual Reality (VR) within an AD workflow, we propose a new design approach: Live Coding in Virtual Reality (LCVR). LCVR means that the architect programs the design while immersed in it, receiving immediate feedback on the changes applied to the program. In this paper, we discuss the benefits and impacts of such an approach, as well as the most pressing implementation issues, namely the projection of the programming environment onto VR, and the input mechanisms to change the program or parts of it. For each, we offer a critical analysis and comparison of the various solutions available in the context of two different programming paradigms: visual and textual.
Conference Paper
Full-text available
Many architects understand that learning to program can be a challenge, but assume that time and practice are the only barriers to performing well enough at it. However, research from computer science education does not support this assumption. Multinational studies of undergraduate computer science programs reveal that a significant number of students in their first and second year of full-time instruction still have serious misconceptions about how computer programs work and an inability to design programs of their own. If computer science students have trouble learning to think and express themselves computationally, what does this say about architects' chances of learning to program well? Moreover, if common problems have been identified, can architectural educators learn anything from findings in computer science education research? In order to determine if this re-search is relevant to architecture, the author conducted a pilot study of architecture students consisting of program analysis and conceptual knowledge tests. The study found that student performance was poor in ways similar to those revealed in the computer science education research. Because architects face similar challenges as computer science majors, this suggests that the discipline could benefit from more investment in educational collaborations. In addition, empirical re-search – from architecture as well as other fields – must play a more substantial role in helping architects learn computational thinking and expression.
Conference Paper
Full-text available
Visual programming languages enable users to create computer programs by manipulating graphical elements rather than by entering text. The difference between textual languages and visual languages is that most textual languages use a procedural programming model, while most visual languages use a dataflow programming model. When visual programming is applied to design, it results in a new modelling approach that we refer to 'visual dataflow modelling' (VDM). Recently, VDM has becoming increasingly popular within the design community, as it can accelerate the iterative design process, thereby allowing larger numbers of design possibilities to be explored. Furthermore, it is now also becoming an important tool in performance-based design approaches, since it may potentially enable the closing of the loop between design development and design evaluation. A number of CAD systems now provide VDM interfaces, allowing designers to define form generating procedures without having to resort to scripting or programming. However, these environments have certain weaknesses that limit their usability. This paper will analyse these weaknesses by comparing and contrasting three VDM environments: McNeel Grasshopper, Bentley Generative Components, and Sidefx Houdini. The paper will focus on five key areas: * Conditional logic allow rules to be applied to geometric entities that control how they behave. Such rules will typically be defined as if-then-else conditions, where an action will be executed if a particular condition is true. A more advanced version of this is the while loop, where the action within the loop will be repeatedly executed while a certain condition remains true. * Local coordinate systems allow geometric entities to be manipulated relative to some convenient local point of reference. These systems may be either two-dimensional or three-dimensional, using either Cartesian, cylindrical, or spherical systems. Techniques for mapping geometric entities from one coordinate system to another also need to be considered. * Duplication includes three types: simple duplication, endogenous duplication, and exogenous duplication. Simple duplication consists of copying some geometric entity a certain number of times, producing identical copies of the original. Endogenous duplication consist of copying some geometric entity by applying a set of transformations that are defined as part of the duplication process. Lastly, exogenous duplication consists of copying some geometric entity by applying a set of transformations that are defined by some other external geometry. * Part-whole relationships allow geometric entities to be grouped in various ways, based on the fundamental set-theoretic concept that entities can be members of sets, and sets can be members of other sets. Ways of aggregating data into both hierarchical and non-hierarchical structures, and ways of filtering data based on these structures need to be considered. * Spatial queries include relationships between geometric entities such as touching, crossing, overlapping, or containing. More advanced spatial queries include various distance based queries and various sorting queries (e.g. sorting all entities based on position) and filtering queries (e.g. finding all entities with a certain distance from a point). For each of these five areas, a simple benchmarking test case has been developed. For example, for conditional logic, the test case consists of a simple room with a single window with a condition: the window should always be in the longest north-facing wall. If the room is rotated or its dimensions changed, then the window must re-evaluate itself and possibly change position to a different wall. For each benchmarking test-case, visual programs are implemented in each of the three VDM environments. The visual programs are then compared and contrasted, focusing on two areas. First, the type of constructs used in each of these environments are compared and contrasted. Second, the cognitive complexity of the visual programming task in each of these environments are compared and contrasted.
Full-text available
"Digital fluency" should mean designing, creating, and remixing, not just browsing, chatting, and interacting.
Conference Paper
Full-text available
Patterns express generic solutions to a well-described problem. In parametric modeling patterns can be used to describe a tactical level of work, above mechanics and below design. We describe three patterns and show how they can be used through an example model.