The New Hypar Platform—Soon Offering the AEC Industry Scalable Computation

AT AUTODESK UNIVERSITY 2018, I had a chance to sit down and meet the folks behind the new Hypar Platform—a scalable computational and generative environment for the AEC industry. I had already known Anthony Hauck (President) before from his days at Autodesk and was now meeting Ian Keough (CEO) also from Autodesk. Both men have set out to deliver something in the industry they feel is missing and we’ll get to that in a second.

Algorithmic-Aided Design (AAD)—a Very Brief History

Algorithmic-aided design (AAD) often goes by several different terms but loosely what we are talking about is using visual scripting UI (most often node-based) tools like Dynamo or McNeel’s Grasshopper, as opposed to the earlier textual scripting tools found in CAD systems. The first such major AAD tools in architecture appeared at Bentley and in particular at the SmartGeometry conferences, though the true beginning of AAD or parametric CAD systems whereby 3D form was tied to variable-driven equations goes back much further. (see: DanielDavis.com, “A History of Parametric,” 6 August 2013).

“Architects got their first visual-scripting language when Robert Aish, then working for Bentley Systems, started quietly beta testing Generative Components (GC) with select architecture firms in 2003,” writes Daniel Davis.

 

 

 

 

The Rhino folks (McNeel and Associates) would try to license GC but were unsuccessful. Handing the task to developer David Rutten, the company would soon release their own graph-based visual scripting environment called Explicit History in 2007. Explicit History was later renamed Grasshopper.

Robert Aisch meanwhile was nabbed by Autodesk shortly after the first version of Grasshopper emerged. Explanations as to why can be found in this excellent story here at AECMagazine. (see: AECMagazine, “Dr. Robert Aish joins Autodesk,” 8 February 2008). Aisch would go on at Autodesk to develop something called Design Script.

The Hypar Connection

Meanwhile, Ian Keough, who has a masters in architecture, started Dynamo—another visual scripting tool for algorithmic design—while working at Buro Happold in New York City. In our meeting at AU, Ian described how both the early version of Dynamo and Design Script merged at Autodesk in what is now Dynamo today.

This brings us to our connection with Hypar. Ian Keough went from starting the Dynamo work at Buro Happold—an effort to bring computational design through visual scripting to BIM—to being Principal Engineer at Autodesk overseeing the development of Dynamo. He was also one of the lead engineers on Autodesk’s Project Fractal, something Architosh wrote about here.

Back in November, at AU, I discussed the emergence of the Hypar Platform with both Ian Keough and Anthony Hauck. This conversation goes into a bit of the backstory of computational design and what the industry needs.

The Interview

(Anthony Frausto-Robledo) What is missing in the computational design space inside of AEC and how does Hypar address this deficit?

(Anthony Hauck) First, I’ll say that there’s a lot of great computational and generative design work happening worldwide in AEC every day, and at Hypar we’re committed to helping accelerate and broaden that trend. In many of my presentations over the past few months, I remind audiences that the earliest paper I can find on applying computation (or ‘cybernetics’ as it was called at the time), to architectural practice was published by Gordon Pask 50 years ago. As I became more familiar with this history, it seemed obvious to me there must be some high barriers preventing the introduction of half a century’s great ideas about applying computation to professional practice.

In our opinion at Hypar, one of the major barriers to the common use of computation to make decisions about buildings has been the lack of a technical infrastructure to support common needs. To the extent that professional firms have encoded and delivered their expertise to their own people with software, they’ve come close to becoming software companies themselves, and sometimes literally have started software companies to support their efforts, assembling or creating a lot of technology from scratch. In our discussions with building professionals, we hear a lot of common requests for fast computation, shared data definitions, easy user interfaces, reliable deployment, and independence from any of the popular commercial platforms used primarily for documenting building decisions in the form of coordinated drawing sets.

 

 

 

 

At Hypar, we haven’t created a complete suite of technologies to answer all the needs we’ve heard about yet, but currently with our platform we’re providing a means to easily distribute and parallelize tasks in the cloud, automatically create basic interfaces for uploaded functions, automatically sample input ranges and create displays of results and interact with individual options generated by functions, with distribution of the functionality as simple as sharing a URL. We think we can make this process even easier than we have so far, but that’s already a lot of technological capability that building professionals don’t have to create for themselves. We’re hoping by providing all of this through the cloud we can unlock a lot of the great work sitting on peoples’ desktops for wider and more consistent use, either within their firms or as an additional source of revenue for their companies.

Ian spoke about how today’s contemporary software development world is different than it was in the not-to-distant past. We have Github for example and numerous shared libraries and tools and open source resources. He implied that this changes the context for how visual scripting evolves and thus visual scripting in AEC must evolve. What are the specific items that visual scripting today is missing from the current generation of software development and how does moving “computational design” to C# address this?

(Anthony Hauck)  To expand on Ian’s point, a lot of what we’re doing is trying to bring common practices of the software development world into AEC practice. We talk a lot about the ‘blank sheet’ metaphor enshrined in just about every AEC software platform, despite having more than 5,000 years of building practice that should be readily available to building professionals. That’s not how the software world works, where today I can easily start a development project mixing toolkits from any number of development organizations. We can’t do that yet in AEC except by hiring a number of consulting firms, something beyond the practical means of most people.

Visual scripting has done a lot to demonstrate that it’s possible for more professionals to capture and apply their expertise through software development, and I think Ian and I share an opinion that without it, we’d lack a whole generation of professionals who understand the potential of combining computational technologies with building expertise to realize both gains in productivity and easier exploration of form. It’s been well said that “culture eats strategy for breakfast” and visual scripting has helped change the culture of practice to recognize how much further we could augment our practice capabilities with technology.

However, from firms who have adopted visual scripting for a variety of tasks, we also hear that the resulting applications can be difficult to deploy, maintain, extend, and re-use, because the tools don’t easily lend themselves to modularization or easy interaction for end users. Several development organizations and some individual developers have made progress on extending the popular visual scripting platforms to mitigate these issues to a degree and we applaud that work, but we also think there’s an opportunity to marry some best practices from the software world to best practices in the building profession.

What are some of the opportunities you are seeing?

(Anthony Hauck)  There’s an enormous development community around C #, many, many libraries applicable to use in AEC, and development environments that help anyone get up to speed quickly. That said, we’ve also successfully uploaded Python functions to the platform, and while we’re not supporting it publicly yet, we’re considering a more ecumenical approach. In the end, we want to help “building professionals” capture and deliver their expertise to projects, and that could mean going where it’s captured now, including in the thousands of spreadsheets on which much practice can depend. As a startup, one of our primary skills has to be listening to where our customers would like us to go, and making strategic decisions accordingly.

It seems that less than 1 percent of all architects are truly capable of utilizing algorithmic-aided design (AAD) in truly meaningful ways to practice. How can Hypar as a platform address this? 

(Anthony Hauck)  Your question goes to the heart of my personal frustration in reviewing piles of fantastic, publicly available research on creating better buildings and applying computation to building problems, and wondering why so little of it appears consistently in professional practice. It would probably be good for our marketing to declare that we have the answer, but the truth is we’re all working together, as a group of building professionals, to find it.

 

 

 

 

At Hypar we’re trying to make that search a lot easier by removing what we see as some basic barriers to progress. We’re trying to help the profession address the problem algorithmically by taking care of a lot of essential software work and allowing them to concentrate on the algorithms themselves, rather than the hundred other concerns that come to bear in trying to scale, deliver, and maintain software.

How specifically are you doing this with the Hypar Platform?

By providing foundational open source data types, web interfaces, interoperability, optioneering, and scalable computation, we’re hoping the professions can concentrate on the important work: capturing their differentiating expertise for consistent use in their own projects or as another means of delivering expertise to clients and colleagues that don’t depend exclusively on direct consultation and documentation.

Is that the complete answer to the current limited application of algorithmic-aided design? Probably not. However, our hope is that over time, we can help foster an ecosystem of “captured expertise” that can be readily combined to address specific problems framed by building professionals who never touch a line of code.

How does the industry democratize computational design methodology when it is intrinsically difficult and both mathematical and requires computer languages? What does Hypar offer this challenge?

A lot of technologies were once estimated to be intrinsically difficult but became easier over time for anyone to use. There was a time that to use an automobile, it was a good idea to be a mechanic or to hire one full time, but today most everyone couldn’t draw you a diagram of how fuel injection or a hybrid power system works. The goal supported by an automobile is to get from one place to another, and anything that impedes that goal has gradually been stripped away for the driver and her passengers while increasing the attraction of the experience. That’s the future I see for algorithmically-aided design methodologies.

So you see the barrier of entry for the user lowering as new users take on the technology. Some will have this technical skillset and package it up as embodied expertise and then the expectation is other firms will readily use it—which in itself is quite foreign to the practice of architecture today. 

While there might be some quite understandable hesitations about utilizing someone else’s encoded expertise, if the results are meaningful, measurable, and verifiable, I believe such solutions will gain acceptance.

 

 

 

 

We see that process today in the wide acceptance of energy analysis engines well tested and verified by independent experts and linked to popular building modeling solutions. We don’t need to turn everyone in the building professions into “mechanics” (software developers), but we do need to make it easy to use the products of one another’s recorded expertise. At Hypar, we’re trying to provide a forum and exchange for recorded expertise as well as capabilities to combine offerings from different providers to arrive at relevant workflows and deliverables. We see similar approaches in the visual scripting world with popular packages providing methods for analyzing and optimizing building solutions, and we’re trying to provide the means to accelerate that approach through our platform.

I want to switch to the coding part of Hypar because visual scripting in Dynamo and Grasshopper aren’t quite the same as coding in computer languages like C#. So part of the problem as I understand you both is that the modern capabilities of the “software world” need to transfer to the AEC world and its set of popular visual programming tools. 

(Ian Keough)  The problem is that we’ve accepted visual programs as a stand-in for code, but haven’t actually developed visual programming tools that exhibit the same characteristics of code like the ability to refactor and modularize your code for reuse and the ability to collaborate on code using source control like Git.

Additionally, while there’s no lack of resources for learning to write code in any language you want (Stack Overflow, Code Academy, etc.), there’s nowhere to learn how to “code” in Dynamo except a comparatively small community of Dynamo users. Looking at this problem as we started Hypar we figured we could burn precious cycles making visual programs do all the things we need to do to make it possible to externalize users’ expertise, or we could take advantage of all of the amazing free and open source tooling for developing, testing, and learning how to code in any language you want. We’re starting with C# because it has broad applicability on top of existing AEC tools, a massive community, and a zillion learning resources, but may offer the ability to write your “functions” in Python or Javascript in the future.

The important thing is not the language that we chose, it’s that we’re betting that we can make the experience of writing code to generate buildings joyful—something that you want to learn and that we can make the experience of getting that code to run in the cloud completely frictionless.

I applaud the aspirational vision. Tell me about the nature of the business model a bit. How will Hypar work at the “contributor” level? 

(Anthony Hauck) We’re still figuring it out, but we see two primary models. The simplest is to offer mechanisms for providers to charge for use of their functions, with a percentage of that fee going to support the maintenance and enhancement of the Hypar platform. We’re also looking at more complex models that include certain levels of use of certain functions depending on end-user subscription level, and returning a portion of that revenue to contributors proportionate to the use of their functions by a subscriber. It’s an ongoing conversation we’re having with the provider community, and I expect we’ll close in on a consistent initial business model within the next couple of months.

And what does the Hypar API do, what does it connect to? If you make a 3D, CAD or BIM app, what would the Hypar API (application programming interface) offer your software by extension? 

(Anthony Hauck)  Ian can elaborate more on this, but essentially we’ve created a basic data model to represent building objects, designed to be highly portable to popular BIM environments and IFC. If you’re a desktop software developer, we’re offering an easy path to bring your work to the web while also providing a scalable computational infrastructure without the trouble of building it yourself.

As we extend the capabilities of the platform, we’re hoping that developers can concentrate less time on common functionality—interoperability, web-based model viewing and interaction, site selection, and similar tasks—and more on recording and delivering interesting and perhaps unique capabilities that others can use and build on. Our data model and our example projects make it easy to create compatible functions whose results can become the inputs for other functions following the same open source protocols.

Certainly, the software industry continues to make headway in data interoperability and the progress in IFC in particular with the ODA taking up the toolkit side of things will aid this further. I agree that so much work seems spent on basics and interoperability and we should be passed that already. Ian, what can you elaborate on the Hypar API and its connections to software and systems?

(Ian Keough)  I will give a slightly more technical explanation here. The Hypar API is a RESTful API for creating and updating functions on the Hypar Platform and executing those functions. More functions on the platform mean more capability. The API will grow over time to encompass more of the things that architects and engineers want to compute in the cloud.

In our domain, expertise is currently delivered either through functionality baked into applications like Revit or through “scripts” provided by the community that requires Dynamo (on Revit) or Grasshopper (on Rhino). Hypar doesn’t require any hero applications to run. It doesn’t require an $8,000 computer. It doesn’t require getting some IT guy to validate and run installers on your machine. But it does generate content in formats that can be consumed by those hero applications allowing it to interop with your current design process.

Architosh Analysis and Commentary

The Hypar Platform is attempting to do several things of note all at once. While I was initially excited to see the platform as a place to go shopping for “accessible” and ready-to-run algorithmic-aided design (AAD) design tools (or shall we call them functions?)—complete with this sense of modularity about the types of problems architects confront over and over again and repeatedly tackle the hard way (ie: Excel, 3D models, diagrams and even manual arithmetic), the more I step back from this the more I realize the real excitement may be the sharing of “embodied expertise.” 

A recent article on AI, written by Kathleen M. O’Donnell for the AIA National website, noted the importance in changing industry perceptions about not just data and expertise but about storage and sharing of this data and expertise. She writes, “Architecture firms should seek to acquire data from owners, other firms, contractors, and software companies—and share theirs in return. This would create an industry-wide information loop that may redefine practice methods and drive profits.”  As a practicing architect as well as a journalist in this industry, I can’t agree more. 

“Knowledge capture” is another term that emphasizes the notion that we should package practice wisdom, often hard-earned, into reusable and democratically accessible storage points. I emphasize points plural because some knowledge may be worth retaining for competitive firm advantage or for privacy and security and the protection of IP of clients. But sharing embodied expertise as envisioned by Hauck and Keough via the Hypar Platform touches more on process methodologies that accelerate some of the hardest and most time-intensive architectural firm processes. It’s about making better decisions faster. Speaking of…if you want to hear Ian Keough discuss Hypar further listen to this excellent podcast episode with him at The Getting Simple Podcast. 

 

Editor’s Note

In the original version we mis-characterized Ian’s role with Autodesk Project Fractal. He was one of many lead engineers on that project, not “the lead engineer.” (14 Jan 2019)