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

For those of you truly immersed in visual programming, parametric design, or whatever you’d like to call it, there is certainly much more to it than this. But to a newcomer these tools will change the way you approach problem solving for the better. And to that point, I want to mention a few other moments of the conference that were my Top 5 BIMForum Moments:

1. A strong case for including virtual reality into the design phase was made by Crawford Architects during their presentation on the Penn State Pegula Ice Arena (structural engineering by Thornton Tomasetti) by attributing nearly $475K worth of savings to the overall project budget thanks to VR.

2. Disney’s Imagineers made some of the most unbelievable Revit families that I have ever seen (check it out here).

3. Patrick MacLeamy’s BIM BAM BOOM made a strong case for making sure to emphasize the value of design and BIM, as the trickle down from an under-cooked design phase can be enormous once it reaches the phases of a project where the bulk of spending actually is.

4. Cory Brugger of Morphosis presented amazing images of the Perot Museum. The prefabricated MEP tower sold it for me, and Ben was blown away by the sculptural metal mesh ceiling (if that doesn’t tell you something about the two of us, I don’t know what will).

5. Finally, Frank Fralick of Beck had the best explanation of an API (Application Programming Interface) that I have ever seen. To summarize Frank and his slide: “A table saw comes equipped with two grooves in the top; these are meant to extend the functionality of the saw. An API allows us to extend the functionality of our software.” I tried to recreate Frank’s slide for those of you unfamiliar with the anatomy of table saws. (We just can’t stop stealing from this guy! See the intro…)

WhatIsAnAPI_Tablesaw

A big thanks to Laura, Marisa, and James for chairing and organizing such a wonderful conference. We really enjoyed meeting all of you and seeing what everyone in the industry is up to.