Posts tagged ‘#flashblog’

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

hummingbird

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.

ColibriIteratorGif001

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.

aggregator

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

“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.

gh_dynamo

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…