Posts tagged ‘ResearchAndDevelopment’

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 ;]

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

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

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

Click to launch the FootPrint app

FootPrint is the result of collaboration between CORE studio and our Corporate Sustainability department, who worked together to find out and illustrate how our office operations and building projects impact the environment. The Corporate Sustainability department collects carbon footprint data from all Thornton Tomasetti offices on a number of sustainability indicators, such as how much energy an office uses for heating and cooling, how much waste it produces and how far employees are commuting and by what means. This data collection happens in two-year cycles (with the exception of offices that have relocated, for which we make sure there is a full year of data before including the metrics).  We’ve also incorporated Thornton Tomasetti’s Green Champions into the map, who help lead sustainably initiatives within their offices to help put some smiling faces behind all of this hard work.

In parallel to this effort of data colleciton, Thornton Tomasetti has joined the AIA 2030 commitment toward lowering the greenhouse gas emissions associated with the building structures that we design. The Corporate Sustainability department organizes our effort to measure embodied carbon in our projects for reporting to the AIA. As part of the initiative, CORE studio developed a Revit Plugin in 2012 that pulls material quantities from our Revit models and enters this information into a database. To date, we have over 200 buildings in the database and are continually adding more. This dataset is now being used to set benchmarks and to help us get a better understanding of the correlation between our structures and the impact they have on the environment.


A screenshot of the Carbon Calculator Revit Plugin for extracting material quantities to be added into the building carbon database


The embodied carbon of structural projects from 2011 – 2013 by market sector

The FootPrint map wasn’t created just to help make the results of this data collection more transparent within Thornton Tomasetti, but to also make the information available to the public. The map itself is built on a variety of CORE studio’s favorite web libraries, including google maps, google charts, and dat.gui.

CORE Studio’s third open source Dynamo package – Dynamo for Rebar – has been released this week. It provides a parametric interface for Revit’s 2016 Rebar API, which allows for the creation of single reinforcing bar elements and rebar container elements in Revit. Dynamo for Rebar enables iterative, parametric rebar design inside of Dynamo 0.8.2 and Revit 2016.

Dynamo for Rebar is an Open-Source project available on github and Dynamo’s package manager. The library contains a set of nodes helping you to create bars and containers in Revit, and provides a set of nodes for creating the base curvature of single bars or entire rebar containers. 

Rebar Nodes

The nodes in this group are specific to the Revit 2016 Rebar API.  They are the core nodes in the package that allow for parametric rebar design in Dynamo.  The utility nodes and nodes for curve generation (outlined below) are designed to work well with these rebar nodes.


Create Rebar
Creates one single bar element in Revit from a curve and and a series of rebar properties.

Create Rebar Container
Creates a rebar container element from a list of curves and a series of rebar properties.  The use of containers is highly encouraged as Revit can get bogged down by thousands of rebar family instances in your model.  Containers are like groups of rebars in a single family instance.

Rebar Property Dropdown Nodes
Select Rebar Style – Select available Rebar Styles from the Revit document

  • Select Rebar Hook Type – Select available Rebar Hook Types from the Revit document
  • Select Rebar Hook Orientation – Select available Rebar Hook Orientations from the Revit document
  • Select Rebar Bar Type – Select available Rebar Bar Types from the Revit document

Nodes for Curve Generation

The nodes in this package for creating curves are powerful tools on their own; they allow the user to parameterize any surface in Dynamo, and create curves along it for any use downstream.  Of course one good downstream use is the creation of rebar containers, but it’s up to you!


Curves following a surface
This node creates a set of curves following the geometry of a selected surface (most polysurfaces will also work). It divides the surface in one dimension – either U or V – regularly. You can define the number of divisions (or optionally, a distance to divide the surface by), and the direction of the curves.


Curves morphing between two curves
This node creates a set of morphed curves between two border curves. It requires two curves to blend between, and creates either a fixed number of curves between them or divides by a defined distance.


Curves perpendicular to one surface
This node creates a set of  linear curves normal to a surface. It requires the selection of a driving surface and a set of bounding faces to define the end of the projection. According to a selected height, the node will divide the surface along this height into a selected number points. It will then draw lines along the normals at this points, break the line at any obstacle and continue until the bounding surfaces.

Utility Nodes

These nodes in this group are mostly designed for use downstream of the rebar nodes.  


Cut Rebar Container by Plane
The cut rebar node cuts a selected rebar container at a selected surface. The result will be either the left or the right side of the division.


Shorten Curve from both ends
This node shortens a selected curve from both ends by the same distance.


Tag (any) Revit Element
The tag element node creates a tag of any taggable revit element in the current Revit view. It requires a revit element as an input and if the tag should be horizontal or vertical or having a leader or not.

Select Nodes
This set of nodes also comes with a very generic one: A node to select multiple edges. This allows you to select any number of edges from your Revit model and use them in Dynamo to create bars or even place adaptive components along them (see Image).


We hope you find these tools useful in your rebar design workflows.  If you have any feedback or find any bugs, please create an issue in our Github repo.  Happy reinforcing!