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 ;]
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.
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.
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.
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.
KPFUrban 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
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.
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.
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)
CORE studio is very pleased to announce the release of Spectacles, a hackable BIM viewer for the web. Spectacles allows authors in the AEC industry to view their 3D design work on the web for free, and is designed to be hacked, extended and modified. We’ve been working on the project on and off for the past year, and are quite excited for more hackers in the industry to get their hands on it!
Spectacles currently consists of a hackable HTML5 web viewer that runs natively in modern browsers (no plugin required), and a pair of exporters for popular authoring applications in the AEC industry—Grasshopper and Revit. BIM data can be exported from these desktop applications, and viewed on the web using Spectacles.
The web viewer, Revit Exporter and Grasshopper Exporter are all open source projects. You can find (and fork!) the source code here: [ Viewer, Grasshopper, Revit ].
Spectacles is a hackable BIM viewer for the web
Rumblings of this project began around 2013. We were involved in some structural and forensics projects in the New York office, and the need for a web-based 3D viewer kept arising. A couple of potential solutions existed at the time and we gave them a try, but none allowed for the sort of flexibility we were looking for. We wanted to provide project-specific 3D user experiences, and needed the UI of the viewer to be able to change—in some cases quite drastically—based on a project’s specific needs. Nothing like that existed, and the idea of building our own platform felt like a daunting task.
A handful of us attended the first AEC hackathon in November of 2013, and walked away armed with the fact that we had a lot to learn about programming on the web. We began experimenting with a couple of open source projects while we were there, including THREE.js, and although the idea of building our own viewer still felt overwhelming, we were starting to feel like it was at least possible.
The next experiment we tried was Platypus, which mashed up the web’s ability to shuffle a bunch of data around in real time with a parametric 3D modeller—Grasshopper for Rhino. It works like a chatroom for parametric geometry, and was a hugely important developmental step for our group. We could do 3D on the web! It is a very specific research project with a very narrow scope, but it got us up and running.
The next big step was vA3C, which emerged at the beginning of last summer at our first AEC Hackathon in New York. Benjamin Howes first outlined the idea here, and he, Jonatan Schumacher, Jeremy Tammik, Theo Armour, Matt Mason, Josh Wentz and a handful of other dedicated hackers built out the first prototypes over the course of about 27 hours. It was a truly awesome experience—we built out the viewer we wanted overnight! It wasn’t perfect by a long shot, but it worked, and it was open source. Spectacles is a fork of the vA3C project, and would not have been possible without this amazing team.
The vA3C team, after a long night of hacking.
Over the course of the next year, we used vA3C in practice on a few projects to do exactly what we set out to do in the first place—project-specific UX. Practical necessity drove code development, and along with help from the other vA3C team members, we were able to expand the feature set of the viewer and improve the stability of the exporters. We developed a custom daylighting analysis results viewer, a project-specific FIM (Forensic Information Model) viewer, and a prototype TTX model query engine. We also started maintaining our own forks of the vA3C projects, including a complete rewrite of the viewer.
Daylighting analysis results viewer prototype. Click the image check it out!
Earlier this year, CORE studio agreed to formally support the project’s development—one of our first company-funded open source projects—and Spectacles was born. Since then, we’ve been refining the codebase and sprucing up the work a bit in preparation for this public release. The project has been used to support a number of other research initiatives at Thornton Tomasetti, including VRX, our Photogrammetry research, and Design Explorer, and we are super excited to see more ideas that utilize Spectacles popping up within Thornton Tomasetti’s various practices.
VRX web viewer
Photogrammetry + BIM model
Green Space/Design Explorer
So what’s next? We’ve certainly got some more plans for Spectacles, and we are looking for collaborators to help us build some of this stuff out. First off, we’d like to build out more exporters! And in order to do so in an organized and efficient manner, we’d like to develop a shared Spectacles.Net library to standardize how AEC geometry is serialized into Spectacles.json files. The Web Viewer certainly needs some more love too—at some point we’d like to leave dat.gui in the dust, for example, and we’d like to make embedding viewers easier and more flexible. We are also developing a hosted web application for in-house project support—something like a Google Drive for Spectacles models: comments, 4D history, live uploads from Desktop Apps—and are considering our options in terms of opening this up to outside users. Finally, we are hoping to see a number of projects in the AEC industry that want to utilize Spectacles as a platform to build on. If you are interested in contributing to the project, or are interested in a project-specific 3D UX for one of your jobs, please do get in touch!
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.
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.
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!