Posts tagged ‘#COREstudio’

About / Directions / Schedule / Speakers & Hosts / Hackathon Info / Workshops / Register / Photos and Video



Join CORE studio at Thornton Tomasetti, Inc. for the fifth annual AEC Technology Symposium and Hackathon, for an advanced discussion on the future of the AEC industry.

We are proud to present the 2017 symposium theme of, Merging and Emerging: AEC Futures, focused on how the AEC and technology industry will develop through projected advancements in coming decades. Through three vectors: Site Futures (Robotics, Sensing, AR and Mixed Reality), Practice Futures (Cross-disciplinary collaboration, Machine Learning and AI), and Facilities Futures (Integration of sensing and data logging for the Built Environment), the symposium will investigate opportunities in implementing cross-industry tech and discuss emerging AEC technology.

The Hackathon is aimed for attendees to learn new skills, generate new ideas and processes for the AEC community through a predetermined challenge to result in an open-source product.

The Symposium will begin at 9:00 a.m., Friday October 20th. Following, the Hackathon will kick-off at 9:00 a.m., Saturday October 21st and conclude at 3 p.m., Sunday October 22nd.

Additional workshops will be held all-day at Thornton Tomasetti’s offices on Thursday October 19th. The workshops will be 4-hours each with a morning and afternoon session. Learn about D3.js and visualization, Tool Development in Grasshopper with Human UI, Dynamo, Konstru, and more. Workshops will be hosted by CORE studio, WeWork, Bad Monkeys, Mostapha Roudsari, and more.

Further information will be posted in the coming weeks regarding schedule, registration, and speakers. Continue to stay informed by following us on Twitter, Instagram, and checking our website.


Many thanks to our generous Symposium, Hackathon, and Workshop Sponsors!

Gold Level Sponsor


Silver Level Sponsor



Hackathon Sponsor


Workshop Sponsors


Leave a comment

CORE studio is pleased to announce the release of TT Toolbox version 1.9, our suite of free and open source plugins for Grasshopper, which is available on Food4Rhino.

Similar to our January 2017 release, the main attraction in this release is Colibri. Many new features have been added to make it easier to turn your Grasshopper definition into a Design Explorer – compatible design space. The big Colibri updates are:

  • Iterator component improved – transitioned to dynamic inputs, sliders / drop-downs / panels all supported as inputs, context menu to specify how to deal with warnings, selection broken out into separate component, ‘Fly’ button included as part of component UI – no more need for a button.
  • Selection component added – allows for more control over partial design space runs; users can specify granularity along any input vector, or can choose to run only a part of the design space (only run the first 100 iterations, for example), or both.
  • Parameter component improved – transitioned to dynamic inputs, generalized so that the component can be used to describe either design inputs or design performance data for the Aggregator to consume.
  • Image Setting component improved – multiple views supported, ability to provide custom file names added (for experts only!).
  • Aggregator component improved – context menu added to specify when / if data should be overwritten, defense added to check for Write? == true when Colibri is told to fly, inputs naming revised to distinguish between design inputs (Genome) and design performance data (Phenome), 3DObjects input added allowing for super-simple Spectacles data generation.
  • Spectacles Integration – The Spectacles exporter was extended to make it easier to work with Colibri; now all Spectacles data can be compiled by the Aggregator by funneling it through the Spectacles_Colibri component.

Also noteworthy: sometime in the past few months we crossed the 20,000 download mark on Food4Rhino!  Thanks to all of the Grasshopper users who have downloaded TT Toolbox for their interest and curiosity, and above all for their feedback and encouragement.  Keep up the good work, folks!  We’ll try to do the same ;]

Explore CORE Studio’s latest contribution to DynamoRevit. We added a lot of new nodes which are partly already released with Dynamo 1.2 and will fully be available with the next Dynamo release. There are a lot of new nodes for creating and manipulating annotations, accessing element properties, manipulating existing locations and entirely new features like creating family types from dynamo geometries or creating global parameters. We added a list containing all new nodes below:


  • Draw and query detail curves by dynamo curves
  • Create dimensions by elements or manipulate dimension properties
  • Make filled regions by outline and access filled region types
  • Place revision clouds by outline curves like polygons
  • Tag any element in Revit directly through Dynamo
  • Place text notes in views, access their properties and text note types

Tag Walls and place Dimensions in Dynamo



  • Access Material properties like Name, Shininess, Smoothness, Transparency, SurfacePatternColor, MaterialClass, MaterialCategory, CutPatternColor, Color, CutPatternId, AppearanceParameters, ThermalParameters, StructuralParameters


  • Select multiple edges from elements


  • Create rooms by location point
  • Get room boundaries as curves
  • Create reference planes by points
  • Get location point or curve and manipulate them with the set location node
  • Move elements by vector
  • Access element materials
  • Create new revisions using dynamo
  • Create wall by face
  • Access Revit’s shape editor for roofs and floors
  • Create curtain systems by face

Create Wall by Face in Dynamo



  • Access properties like host element of family and type
  • Create new family types by dynamo geometry

Create new Family types from Dynamo geometry


  • GetSurveyPoint and
  • GetBasePoint give you direct access to the document’s coordinates


  • Access parameter properties like: HasValue, IsReadOnly, IsShared, Group, ParameterType, Id, UnitType, ParameterByName, SetValue, StorageType, SharedParameterFile,
  • Create shared or project parameters
  • Create global parameters (from Revit 2017)
  • Access global parameter properties


  • Create Parameter Filters by filter rules
  • Create Filter Rules by Rule Types
  • Create new Override graphic settings

Performance Adviser

  • Run Revit’s performance adviser directly in dynamo and explore failure messages

UI Nodes

  • And several UI nodes to access elements like: Phase, Revision, FilledRegionType, RevisionNumbering, RevisionNumberType, ParameterType, BuiltInParameterGroup, RevisionVisibility, DirectShapeRoomBoundingOption, FilterType, HorizontalAlignment, VerticalAlignment, RuleType

Written by: Max Thumfart

1 Comment

CORE studio has released an updated version of TT Toolbox for Grasshopper containing a new plugin called Colibri.


Colibri is Spanish for hummingbird. Logo by Colibri contributor Olivier Dambron.

Colibri allows Grasshopper users to easily turn their Grasshopper definitions into Design Explorer – compatible design spaces.  Run Colibri in Grasshopper, upload to Google Drive, and voila: your design space in Design Explorer!

Colibri is an open source project that was started at the 2016 AEC Technology Hackathon in New York, which CORE studio hosted late last year.  It was designed and prototyped over the course of 27 hours during the hackathon by a team of dedicated hackers (most of whom work for TT!).  CORE studio forked the project after the hackathon, and we’ve been improving and testing Colibri over the past few weeks in anticipation of this release.

The project’s goal is simple: make it easy to generate Design Explorer-compatible data sets in Grasshopper. This has been possible to do for some time now of course, but it was super painful to set up and was generally quite error-prone.  Users would rely on Ladybug’s ‘Fly’ component or our ‘Brute Force’ component to iterate over some sliders in their grasshopper definition, and use a bunch of data recorders and an Excel Writer to create a data.csv file in the right format.  Images and Spectacles models were up to the user to generate, name, and link into the .csv file properly.  Because Fly and Brute Force hit every step on every slider, users’ sliders often had to be edited to fine tune the size and resolution of the design space.  If all of that sounds like complete nonsense (or if it makes sense but sounds painful), we are with you, and that’s precisely why we built Colibri.  It should be easy to jump into Design Explorer!

The Colibri workflow is divided into two stages, Iteration and  Aggregation.  Colibri provides a component for each stage, the Iterator and the Aggregator.


Colibri Iterator

The Iterator component loops over connected sliders and drives your grasshopper definition, much like Galapagos does when it’s running. Unlike Ladybug’s ‘Fly’ component or our old ‘Brute Force’ component (all of which, more or less, share the same code base by the way – these tools are all based on this post from David Rutten), Colibri’s Iterator component allows users to specify how many steps to take along each slider.  This is subtle, but important: it allows users to keep the size of their design space under control, and to specify granularity selectively along each input vector within the design space – all without editing the actual sliders in Grasshopper.


Colibri Aggregator

While the Iterator is iterating away upstream, the Aggregator component collects all of the data that Design Explorer needs from your Grasshopper definition. It gathers the inputs from the Iterator, the outputs (performance metrics) from your grasshopper definition, and takes care of generating images, naming images and Spectacles files, and writing all of that data into a data.csv file.

Another application for the Aggregator is to record optimization runs with Galapagos or Octopus. By connecting the ‘Colibri Inputs’ component to the same sliders that Galapagos / Octopus is driving, the Aggregator is able to record every iteration during an optimization run.  This workflow allows designers to navigate within the focused design spaces that those algorithms produce using Design Explorer.  Instead of reinstating one iteration at a time in Grasshopper, groups of iterations that fit a set of specific performance criteria (something like ‘show me all iterations that are highly performant and that have a bay spacing greater than X and a floor height smaller than Y’, for example) can easily be identified using Design Explorer.

The YouTube video above demonstrates how to get started with Colibri, and you can download the plugin from Food4Rhino.  Please let us know what you think!  We sincerely hope you’ll enjoy working with Colibri and Design Explorer.

Written by: Benjamin Howes


Photos and Videos are available!

Missed our symposium or want to share talks with a friend or colleague? Videos of the presentations are now available online! You can find the playlist on our YouTube.

Photos from the Symposium and Happy Hour Reception are located here.

If you attended any of the events and captured interesting images, we want to see them! You can email them directly to Shannon.


Find out more…

To learn more about this past event, symposium speakers, and hackathon ideas, please visit the event page.


In this third and final post in our series about Design Explorer, we focus on how the tool is currently being used in practice by architects, engineers, and designers. The discussions about design space navigation and the too many iterations problem are all well and good, but without some specific examples it’s all admittedly a bit abstract. This post will attempt to bring some specificity to the conversation by showing how some avant garde AEC technologists are using Design Explorer to navigate project specific design spaces.

Case #1 – Typical Block Massing


Data set link

KPF Urban Interface was kind enough to share a portion of their Ideal Block: London design space with us for this post. KPF.UI created a parametric model that generated massing geometry for an idealized residential block in London, and analyzed the performance of the massing based on a number of metrics: available daylight, sky exposure, site coverage, floor area ratio, etc.

Case #2 – Balconies, Daylighting and Operational Energy


Data set link

While still at the University of Pennsylvania’s Masters of Environmental Building Design program, Mingbo Peng (now a Project Consultant in the Sustainability Practice at Thornton Tomasetti) developed a design space exploring the relationships between balconies, daylighting, and operational energy for typical New Orleans apartments. More information on the study can be found here.

Case #3 – TT Embodied Carbon Database


Data set link

Thornton Tomasetti’s corporate sustainability department has been compiling a database of our completed projects’ embodied carbon footprints over the past few years. The design space above is a small sample of that database that compares projects’ sizes and embodied carbon footprints. I think this one is particularly interesting since the data didn’t come from a parametric model. Design Explorer can be used to visualize a very wide variety of design spaces. It’s not just limited to parametric AEC models.

Case #4 – Roof Truss Topology and Sizing


Data set link

CORE studio developed this example to demonstrate [to our Grasshopper-savvy structural engineering teams at Thornton Tomasetti] that Design Explorer can be used for structural work, too. Since most of the Design Explorer work we’ve shown to date has been related to environmental / sustainable design problems, there was a widespread misconception that it could only be used for those types of problems — not so!   This example explores how topology and member sizing relate to deflection, self weight, and structural utilization.

We chose to limit this post to these few case studies, but we wanted to show so many more … especially a product design example (something very small) and a purely numerical example (something without a body to show in 2D or 3D). If you’ve made it this far, the author will have to assume that you can use your imagination to conjure those last two. We sincerely hope you’ve enjoyed this series on Design Explorer, and that you’ll continue to use and fork the project in the months to come.

Happy exploring! Don’t get lost in all of those extra dimensions out there…


Shot from Christopher Nolan’s Interstellar (Source)

Written by: Benjamin Howes

Following up on our Design Explorer Announcement post last month, this second post in our Design Explorer series will explore the idea of the design space by looking at a small set of historical precedents and contemporary like-minded projects. By describing the natural history of this family of concepts, we can develop a better sense of how the idea of design space is moving away from the fringes and into the mainstream.

The timeline below is an attempt to position Design Explorer as part of a broader trend towards design-space-thinking in the AEC technology community. It is by no means meant to be exhaustive, and I’m sure there is a ton of work out there of which I am unaware that could further describe the natural history of the design space. It is a curated timeline from the author’s point of view.

(1941) Borges; Library of Babel. I came across this work in Kevin Kelly’s Out of Control. Borges writes about a vast library containing all possible [410-page, specifically formatted] books. Although most books are filled with utter gibberish, the library contains every book ever written. Kevin Kelly talks about visiting this [fictional] library while he is writing Out of Control and deciding that instead of finishing the book himself, that he will develop a method of searching the library for the already-complete copy of his book. This idea of searching – the method, as he calls it – is a vivid example of design space navigation.


Artist’s rendering of the Library (Source)

(1979) Hofstadter; Gödel, Escher, Bach. We could draw on a number of examples from this amazing book, but I think the high level survey is more meaningful. At various points, Hofstadter talks about protein folding space, the space of all meaningful mathematical expressions, the space of all possible fugue variations given any starting melody, etc. It turns out that mathematics has been concerned with these questions much longer than we have in AEC! No surprises there, I suppose.


A six-part fugue by Bach (Source).

(1986) Dawkins; The Blind Watchmaker. In the third chapter of The Blind Watchmaker, Dawkins expounds about a computer program he developed called Biomorph Land. The program allows the user to drive the evolution of 2D branching structures over a series of generations. For each generation, the user picks one figure that is most attractive, and in the next generation a set of new descendant figures are drawn. There are about 500 billion biomorphs in the nine-dimensional space that Dawkins created, and the only way to find any one of them was to evolve towards it from a single, primitive parent.

Dawkins writes beautifully about the first night he got the program to run – staying up all night evolving bats, insects, and airplanes – and how he neglected to write a method of saving the biomorphs he encountered. He saw amazing forms during his first night exploring in biomorph land that were effectively lost – without saving their genomes, it was practically impossible to find them again within the vast design space. Aside from the amazing writing about design space navigation, he also developed some incredibly interesting visualization techniques, such as cutting a section through the design space using a hyperplane.

Partial high-dimensional cross section of Biomorph Land (Source)

Partial high-dimensional cross section of Biomorph Land (Source)

(Early 2000s) Scripting Architecture.  Rhinoscript and Generative Components open up a new working methodology for architecture and engineering practices.  Instead of resorting to ‘click and die’ for design iteration, designers begin to automate the authorship of geometry in their CAD platforms, and to define parametric relationships in their models.  Generating new iterations is as simple as changing input parameters and re-running the script – design spaces begin to take shape.

Sample Generative Components model (Source)

Sample Generative Components model (Source)

(2009 – Present) Rise of the GrasshopperGrasshopper exposes a huge audience of architects, engineers and designers to computational and algorithmic design. Design spaces proliferate. Galapagos enables optimization workflows, and for the first time gives users a visual representation of the design spaces that their definitions describe. The idea of the design space starts to take root in the AEC mainstream.

Grasshopper’s Galapagos Interface (Source)

Grasshopper’s Galapagos Interface (Source)

(2011) Design space navigation / publication research at PAE. Right around the same time as the rise of the Grasshopper, online ‘configurators’ started to show up (including early versions of Nervous System’s work in the browser) … which begged the question: if BMW, Nike and Nervous System can publish design spaces, why can’t we? I worked on a research project called Igloo in 2011 at the Stevens Institute of Technology Product Architecture Lab along with Matthew Naugle, Nicholas Faust, David Pysch, Nick Mykulak, and Mike Cosentino, which allowed design spaces generated with Solidworks or Grasshopper to be published and navigated on the web.

Sample Igloo design space (Source)

Sample Igloo design space (Source)

(2012 – Present) GBS parametric runs. Autodesk releases functionality within Green Building Studio that lets users to upload a single design iteration [from Revit and Vasari] to a web application that would perform a series of parametric energy analysis runs automatically. Using the results of all of these analyses, GBS returns a sensitivity analysis visualization, allowing users to see which design parameters matter the most for potential for energy savings. It’s a specialized case, but the most interesting component is the use of a horizontally scaling web application to generate a design space (more on that below…). The CORE studio worked with the Dynamo and GBS teams at Autodesk to develop Energy Analysis for Dynamo, an open source package for Dynamo which allowed users to set up their own parametric runs, and to include GBS results in optimization workflows.

Sample GBS analysis output (Source)

Sample GBS analysis output (Source)

(May 2014) Pollination. A team of hackers developed Pollination at the 2014 AEC Technology Hackathon: an open source tool for managing (and dynamically visualizing the results of) distributed, parametric energy analysis runs using Grasshopper, Honeybee, and Amazon Web Services (to run the whole-building energy analyses on the cloud). This is another early example of a web application generating a design space, but the most interesting development was the use of an interactive parallel coordinates plot to display the results of the analyses in exhaustive detail. The team quickly realized that the UI used to display results could be used to visualize and navigate within any multi-dimensional data set. This insight was the kernel for the Design Explorer.

Pollination user interface (Source)

Pollination user interface (Source)

(May 2015) Design Explorer v1. Design Explorer was CORE studio’s first attempt to generalize and extend the ideas that came out of Pollination. We set out to build a single page web application that lets users navigate within multidimensional design spaces, and that gives them graphical representations of both the design space itself and of the individuals within that space. The parallel coordinates plot from pollination was used to visualize and navigate within the design space, and images and/or Spectacles models were used to represent individual design iterations. Navigation using sliders is also available in Design Explorer (it’s just sort of hidden over on the left!). CORE studio released this project under an open source license, in hopes that the burgeoning community of design-space researchers might help to extend the research. Design Explorer was first presented by former CORE studio Applications Developer Mostapha Sadeghipour Roudsari at the 2015 AEC Technology Symposium (link to Mostapha’s presentation), and a modified version was used to present the results of some early machine learning research by CORE studio Engineer Dan Reynolds at the same event (link to Dan’s presentation).

Design Explorer slider mode

Design Explorer slider mode

Design Explorer parallel coordinates mode

Design Explorer parallel coordinates mode

(March 2016) Speckle beta release. Speckle is making some really impressive headway – the CORE studio thinks it’s super exciting! The project aims to allow users to share, display, and explore parametric models in a web browser. Their beta release allows users to export design spaces from Grasshopper and to share those spaces on Both slider and parallel coordinates modes are available. Perhaps sweetest of all, the project is open source under the GPLv2 license! They’ve also got a new version cooking that seems to be exploring a streaming model (as opposed to exporting the whole design space).

Speckle slider mode (Source)

Speckle slider mode (Source)

Speckle parallel coordinates mode (Source)

Speckle parallel coordinates mode (Source)

(July 2016) Autodesk Project Fractal alpha release. Another super impressive project from our friends over at Autodesk, Project Fractal. Like Design Explorer and Speckle, sliders and a parallel coordinate plot are used to navigate within a design space that was authored in Dynamo Studio. However instead of exporting entire design spaces, Fractal runs Dynamo graphs on the cloud in real time, and stores computed iterations in a database. This is another example of using a horizontally-scaling web application to generate design spaces. This project seems to have branched out of an earlier Autodesk labs project called Akaba – you can read all about both here:

Fractal Demo Video

(October 2016) Design Explorer v2. While he was studying with Mostapha Sadeghipour Roudsari at the University of Pennsylvania in the Spring of 2016, Mingbo Peng forked Design Explorer and made a number of improvements. Most notably, he made publication much easier by linking up Google Drive to host [Design Explorer] content and data – this was an absolute nightmare in v1!

Design Explorer pulling data from Google Drive

Design Explorer pulling data from Google Drive

In his 2011 book Where Good Ideas Come From, Steven Johnson writes about simultaneous invention. It seems to me that we are in the midst of such a period of simultaneous innovation focused on design space navigation.  In other words, it’s not a surprise that we aren’t the only group doing R&D along this vector.  Since our authoring tools have evolved to let us iterate at an unprecedented scale and speed, we are now in dire need of a new generation of tools that will allow us to navigate within the vast libraries we build; tools that help us find a few good solutions in enormous possibility spaces.

Stay tuned for our final post in this series, which will focus on how Design Explorer is being used in practice.


Written by: Benjamin Howes

1 Comment

CORE studio is pleased to announce Design Explorer, an open source tool for exploring design spaces on the web.  We’ve been working on this project on and off for well over a year now and we’ve presented it a number of times, but we’ve never written about it. Shame on us!

Design Explorer

Design Explorer

Over the next few weeks, we will publish a series of blog posts about the project’s goals, the natural history of design space tools in AEC, and how Thornton Tomasetti and others are using Design Explorer in practice. This first post will focus on the current state of the project and the main problems that Design Explorer is trying to solve.

The first problem will be familiar to anyone who has done any parametric and/or computational modeling: parametric models give you too many iterations. Of the multitude of possible states that any reasonably complex parametric model describes, which ones are the good ones?  Are there some zones that are better than others?  If so, how do we find them?  It depends what you mean by ‘good’ and ‘better’, of course…

For some design problems, performance is measurable. Designers and engineers can qualify ‘good’ according to project-specific performance criteria.  Computational modelers can (and should!) build analysis feedback loops into their models to let performance analysis inform the trajectory of the design process.  Since CORE studio supports a world class engineering practice, we have the luxury of dealing almost exclusively with these types of problems.  In most cases, we build rich parametric models with embedded analysis feedback loops to rapidly study a wide range of potential solutions.  As such, this problem (too many iterations, where are the good ones?) is particularly important to us.

Nervous SystemNervous System’s edge based growth design space. Source.

The second set of problems is related to the nature of design spaces themselves. The types of design spaces that our grasshopper definitions and dynamo graphs describe are multi-dimensional.  Multi-dimensional spaces work  like the three dimensional space we all model in every day – they just have more axes.  Whereas a three dimensional point in euclidian space is described like this: { x, y, z }, a higher dimensional point in a design space might be described like this { length, width, height, numFloors, cornerRadius, rotation, embodiedCarbon, cost }.  Because our design spaces are typically of a higher dimension [than three], they are hard to visualize.  And because they are hard to visualize, they are very hard to navigate.

Wired’s illustration of a 3D design space. Source (and excellent article about design space thinking in the graphic design world).

You can think of Grasshopper and Dynamo as design space navigation interfaces.  Parametric modelers allow you to navigate from one point to another in any design space that you construct.  When you drag a slider in Grasshopper, you are moving along a vector in your design space, computing and visualizing one iteration at a time as you go.

Design Explorer is an interface that lets you visualize and filter groups of iterations – sets of design solutions that are both intimately related, and potentially scattered across a vast, high-dimensional possibility space.

Design Explorer Demo

Users export their design spaces from parametric authoring applications (Grasshopper, Dynamo, Catia, Etc.) in the form of a data.csv file and a series of images and Spectacles models.  The design space data is generated by traversing the parametric model in an automated fashion – either with our brute force solver, Ladybug’s Fly component, or an optimization algorithm such as Galapagos or Octopus.  After all of the data has been generated, it must be hosted somewhere on the web (Google Drive, Amazon S3, or your own server).

Design Explorer reads the data.csv file and generates a 2D visualization of the design space called a parallel coordinates plot (with a grid of thumbnails and some other UI).  The plot’s vertical axes represent design variables and performance metrics; the lines running horizontally across the plot represent individuals within the design space.  The design space can be filtered by clicking and dragging along the vertical axes, and by dragging filters up and down.  Users can investigate individuals by clicking on a thumbnail and reviewing a full size image and a 3D model.

Our next post will concentrate on the natural history of these ideas within our group, highlight a few parallel/adjacent projects within the AEC technology community, and identify some meaningful precedents in popular culture. In the meantime, you should try Design Explorer!  Give the samples a look, check out Mingbo Peng’s tutorial video, fork the Github repo and mess with the code, and let us know what you think!


Written by: Benjamin Howes

1 Comment

“Learn visual programming” was the hard-fought closing remark to the computational panel, which Ben Howes and I had the privilege to be a part of (video here). Hard-fought in the sense that Ben stole these words right out from under our new and good friend Frank Fralick (developing Dynamo for Autodesk’s Inventor), who appropriately had these words in his last set of slides—Ben and I of course did not. While Frank presented his work on turning digital designs into fabricated realities, Ben and I presented Remote Solving: a platform for allowing near instantaneous engineering feedback to our clients using the cloud. Also taking part in our panel was the team of Harry Mattison and Robert Manna from Boost Your BIM and Stantec, respectively, who shared their work on using a shortest walk algorithm to better design the walking distances between rooms in hospital planning. I couldn’t think of a more appropriate example of how to use this algorithm myself!

But let’s get back to learning visual programming. First, to be clear, when we say visual programming, we are referring to computational programming that relies not on the writing of text-based code, but on the connection of graphical nodes or components to create a similar logic system. Think: Grasshopper for Rhino, Dynamo for Revit (and soon other Autodesk products like Inventor) and Generative Components for Bentley.


Left: Example Dynamo script. Right: Example Grasshopper script.

This is important because learning these tools instills a procedural way of approaching design problems. Working with these software platforms forces you to consider design relationships at multiple scales, from the finest of details, all the way to the macro relationships and drivers that govern the overarching logic of the project. Aside from creating far more precise models that are able to iterate through many design options, it is largely a different way of approaching problem solving than what many of us are used to. In design education there is an emphasis on ‘the one,’ or the belief that a singular idea can be refined and re-refined until it is truly perfect and fully resolved. In engineering education it is much different, but ultimately it is too often boiled down to right or wrong and black or white. What visual programming allows is for the exploration of the ‘gray’ design space in between, which is all of the possibilities in and around that one great idea. In these adjacent areas of the design space, options can be exposed that may lead to solutions that are better than the original intent.

Continue reading…