Skip to content

Blog’sploring: Kean Walmsley’s Through the Interface

December 22, 2011

My parametric model of the Palazzetto dello Sport in Rome, from the "What Would Nervi Do?" project

Meeting Kean Walmsley at Autodesk University last month was certainly serendipitous. I was visiting with Scott McFarlane of Woolpert in Autodesk’s booth on the show floor. Scott had presented an excellent workshop the previous day on C# best practices and I’d wanted to learn more about his experiences in the Autodesk Developer Network. ADN is Autodesk’s fee-based program which provides licenses and API support to third party developers. (BTW, Scott recommended the support network as invaluable, a must have.)

In the course of the conversation with Scott I brought up one of my pet projects: programming in F#.  F# is a nice little functional programming language developed by Microsoft and fully supported in their Visual Studio 2010 IDE (Integrated Development Environment – developer geek speak  for a fancy editing and debugging environment used in writing programs.)

Functional programming languages have long been of interest in the academic community for their purity of structure. They support a particularly clean programming style which is a good match with my recursive thinking, so I have always enjoyed the opportunities I’ve had to work with them. Furthermore, these languages are highly suited to multithreading, a key to taking advantage of capacity available in both modern desktops and cloud computing. Indeed, Robert Aish of Autodesk Research is developing the functional programming language DesignScript specifically for parametric programming. It is currently available in AutoCAD and is being propagated to additional tools in their design suite. (For a nice introduction to F# and functional programming by Microsoft check here.)

Plugins for Autodesk and Rhino both target the C# language and VS2010. Since libraries compiled from any of the supported languages in that environment are supposedly interchangeable, I wondered aloud, “Was anyone using F#?”  Scott pointed across the booth and said, “Well, Kean there has been working with F#, I think he has posted some things about it on his blog.”

Which brings me to my serendipitous meeting with Kean and later exploration of his blog, Through the Interface. Kean manages the technical arm of ADN. He blogs about his activities and travels, as well as providing a wealth of tips and information about software development in the Autodesk environment, including using F#.

All in all, I’m happy to say that the templates and information available on Kean’s blog have brought functional programming back onto my developer radar screen and to the top of my “stuff to experiment with” list.

Plugging-Into Disruptive Technology

December 12, 2011

Always have a solid platform beneath you.

Apps have changed the face of software design. You knew this already. If you’re in line with my current blog-reading demographic, you carry a smart phone and you’ve spent a few bucks buying your favorite apps. I love the app that tracks the bus coming toward me while I’m standing at my nearest bus stop, and the one that plots my best bike route between here and there.

As a software developer and architectural designer, I am also fascinated by the technological disruption initiated by the app world. The open source and commercial communities are accidentally colluding to lead us away from monolithic software systems and into a universe of platforms and user/developer groups extending those platforms. It is a response right out of Clayton Christensen’s The Innovator’s Dilemma, and exactly the kind of creative environment described in Steven Johnson’s Where Good Ideas Come From.

We see the same kind of change happening in the architectural CAD software community as well. Rhino’s open source approach to developing the next release of their 3d modeling product has enabled them to tap an enormous community of designers and developers, resulting in a wealth of creativity, and extensions that no one company or entrepreneur could possibly develop on its own. This is a win-win for both the company and the external talent. The company gains visibility, establishes a larger pool of committed users, and fosters new applications, while at the same time accessing an active and technically proficient set of beta testers who can look into every corner of the base tool’s capabilities. The users gain because the platform enables their creative ideas while relieving the overhead of developing a geometry system below it.  As a developer, I appreciate the quality of the commercially developed platform, which supports the experimentation necessary for developing add-ons. I can be creative about the things I know, debugging my own code rather than debugging and rewriting the work of others.

Rhino’s development model is beginning to percolate throughout the architectural CAD community at large. Autodesk now touts their “open APIs;” attracting plugin developer technology is becoming the norm, and is clearly perceived as key to their continued success. And this approach is not limited to modeling tools. M-SIX, a quiet little startup here in Portland, Oregon, is using the same open interface model to provide a suite of cloud-based capabilities for large scale BIM collaboration and project management, enabling a much higher platform to stand on, and one tailored to the computational needs of architectural design.

Blog’sploring: Zach Kron’s BUILDZ

December 8, 2011

Kelvin Tam of NBBJ's contribution to the parametric pumpkin carving contest.

Last week’s trip to Autodesk University unearthed a wealth of excellent blog sites.  One of particular interest to me is Zach Kron’s BUILDZ .  I first tuned in to Zach’s blog after attending his excellent Vasari workshop Playing with Energetic Supermodels, co-presented with Matt Jezyk. I have developed a real attachment to BUILDZ since discovering Zach’s 3rd Annual Parametric Pumpkin Carving Contest, with its unique awards categories, “Baddest, Goodest and Mostest Parametric” pumpkin.

Aside from some bad-a** examples of parametrically designed jack-o-lanterns, BUILDZ has lots of useful information on using Revit as a parametric modeling tool.  Good stuff.

A Visit to the Vdara Death Ray

November 30, 2011
Heliotrope

While here in Las Vegas for Autodesk University, I could not pass up the opportunity to walk down the Strip and around the corner to the Vdara Hotel, famous for the so-called Vdara Death Ray. It turns out the Death Ray is a result of reflections off the Vdara’s sister hotel, the Aria, located just across the street. At certain times during the summer, the windows on the 61st story of the Aria line up just right and focus all that Las Vegas sunshine right down onto the outdoor pool located on the Vdara’s third floor.

Death Ray

Poolside at the Vdara with the Aria beyond.

Stories abound of melted plastic cups and burned flesh. Exaggerated? Perhaps. But every one of the staff members I queried knew exactly what I was talking about.

Of course the Vdara is not the only recipient of unwanted solar energy from a not-so-well-thought-out neighbor. Frank Gehry’s Disney Concert Hall required some judicious sandblasting to reduce reflections from the titanium mirror finish which caused extreme over-heating of apartments and sidewalks across the street.

Heliotrope

The stepped planes of the Aria provide a nicely aligned mirror to warm the poolside guests at the Vdara

In the Vdara’s case, a little more design coordination would have helped, as the same developer built both hotels and opened the Aria just 15 days after the Vdara. The problem stems from the design of the Aria’s facade surface, which is stepped rather than a single smooth curve. It’s composed of a series of planer vertical strips arranged in a curved face, each stepped back from and slightly angled to the previous one. These highly mirrored strips reflect light downward onto the Vdara’s pool area.

The obvious question is, what went wrong in the design process? Assuming the designers were aware of the possibility of solar reflection, how could they have anticipated and corrected the problem in their design? One cannot, after all, anticipate or solve such a problem with the traditional solar shaders available on every modeling tool from SketchUp to Revit.

Enter my firm, Slate Shingle Studio. Using a combination of proprietary solar algorithms, parametric modeling and analysis, and the agility of a small computing house, we apply sophisticated computation techniques to specialized, small market problems. We seek aesthetic and environmental solutions for this kind of early design decision involving sun, wind and rain. An early design analysis could have foreseen this solar effect and saved hotel clerks, waiters and the Vdara’s insurance agents a lot of explaining.

Google Earth view of the Vdara, Aria and Death Ray

Cultural Whiplash in Vegas

November 29, 2011

Image

Outside my hotel room in Vegas.

I probably should not have been reading Fight Club by Chuck Palahniuk on my flight down to Las Vegas last night. It made the surreality here all the more so. On top of that, I’m experiencing a cultural whiplash. Having just returned a month ago from the annual ACADIA conference in Banff with a 150 of my best academic friends, I am now attending Autodesk University with my favorite 8000+ fellow developers and users. Each experience is great in its own way.  I personally prefer visiting Banff, but as I stand here in the glitter, noise and techno of these modern monsters on the Vegas strip, I do have to ask myself whether it’s actually any “better” or “greener” that the Canadian Pacific built the Chateau Lake Louise in the middle of a precious wilderness. It’s hard to imagine all 8000 of us at Lake Louise. But I do hope that in another 100 years, the Chateau will still stand while the fake Venice I now sit in will be long gone.

Image

Chateau Lake Louise in Banff, Albert, Canada

Image

Lunchtime at Autodesk University

Announcing Heliotrope; Solar Calculations for Grasshopper

October 9, 2011

Did I mention that I obsess about where the sun is?

So much so, that I developed a tool for use in my own modeling which I am now happy to release for general use. Heliotrope is a solar calculator for creating solar-aware design and geometry in Rhino and Grasshopper.

Typical modeling tools provide the sun’s position only for rendering–set your day, time and location and see the shadows that result. Heliotrope allows designers to use the sun’s location parametrically when creating geometry by calculating solar elevation and azimuth at one or many dates and times.  In addition, the precise time and position of sunrise, sunset and solar noon are available on a given date.

Rhino and Grasshopper provide an accessible and powerful modeling environment in which to use Heliotrope to generate paths along solar arcs; align objects to sunrise, solar noon, and sunset;  or analyze what objects obscure the sun at given times.  For example, the image below shows the sun’s path and position at 10:06am here in Portland, Oregon on this year’s summer solstice, fall equinox, and winter solstice.  A designer can adjust the time of day to view precisely where the sun will be located or use the calculations directly to drive parametric geometry.

Please feel free to try out Heliotrope and send me your thoughts and comments. The Version 0.1 plugin and User Guide are available for download from Food4Rhino. This free evaluation copy will expire on 12/21/2011 to make way for a number of additional analysis features now in development.

All in all, I expect to continue obsessing about where the sun is throughout our grey Portland winter!

- Brian -

Aligning the Sun in SketchUp

September 29, 2011
Adjusting Earth location to create the right shadow alignments

Adjusting Earth location to create the right shadow alignments

I admit it, I obsess about sun angles.  It is my inner mathematician colliding with my inner architect.  I love how traditional architectural elevations rendered in the Beau Arts style provided shadows showing the depth and relief of the facade. This image style still works even for modern, low relief buildings as shown in this rendering of Portland’s ,  12W building by ZGF.

Direct rendering engines, such as the one built into SketchUp, are great for generating the clean crisp shadows required for these images.  But it is difficult find the right dates and times to position the sun at precisely the angles needed to cast the desired shadows.  SketchUp does not provide for manipulation of the sun position directly (as can be done in Rhino, kudos to them!). And while you can use date and time sliders to move things around until you get something that looks good, it is difficult to get just right?  And once adjusted for one elevation, how do you expose successive faces of the building for the others?

Shadows cast across the face of Portland's 12W building.

Shadows cast across the face of Portland's 12W building.

I found a solution by using an object called a “shadow box” from an old, used, hand-drafting book by C. Leslie Martin. Martin used this simple cube-shaped ”box” to illustrate where shadows should be drawn, in SketchUp it can be used to dial in exactly the location, date and time required to cast perfect shadows.

First, I got close by ignoring the geolocation and manually my latitude to 45 and longitude to 0 degrees in the “Set Manual Location” window under “Model Info->Geo-location.   I then adjusted for solar noon on the equinox in order to align my shadows precisely along the north vector, which defaults to the Y-axis.  The magic date and time settings are 9/21/2011 at 11:53AM and set by tweaking the values in the Shadows window.  Not perfect but as close as can be gotten with minutes being the minimum time adjustment value.

ShadowBox1

Initial construction of shadow box showing crosshairs and north angle 0. The orange line along the Y-axis marks north.

Next I rotated north 45 degrees using the Solar North toolbar in SketchUp 8 Pro. Why rotate north angle instead of rotating the model?  SketchUp provides preset orthogonal views aligned to the default axis.  Assuming your model building has faces constructed orthogonally to those axes as well (a good idea for stable modeling) it is easy to expose each successive face of the building by switching to its view and setting north to the respective 45, 135, 225, and 315 degrees.  Rotating your model is hazardous as it can introduce tiny errors in point coordinates that will cause much grief later on.

ShadowBox2

Final shadow box settings with the crosshairs aligned to the box base corner.

The sun is now 45 degrees off the building face, but we also need to adjust its elevation to get a vertical angle 45 degrees.  Don’t touch that time and date!   Instead, adjust your longitude under the “Model Info” dialog so that the shadow box “crosshairs” directly align with the lower back corner of the box.  The magic latitude was 55.4 degrees N.  Now by changing the north angle to each respective quarter and you can quickly export beautifully stylized and consistent elevation studies.  Separately exported images for lines, materials and shadows can then be recombined in Adobe Photoshop to further enhance the renderings.

Download your very own SketchUp shadow box here!

ACADIA 2011 Conference & Rhino Programming

September 27, 2011

I am excited to be attending the ACADIA 2011 annual conference in Calgary & Banff beginning in two weeks!  The conference is split between the two locations, the first two days in workshops on the University of Calgary campus and the remainder at the Banff Arts and Cultural Center.  The biggest question of the moment is which of the workshops to sign up for during those first two days in Calgary?!

Any audience members who will also be there, please feel free to get in touch with me!  Happy to talk shop over a cup of coffee.  Will pay for guest blog postings with beer.

Speaking of talking shop, I have quietly extended my capability to develop plugin tools in the Rhino 3d modeling environment and am now ready to flaunt them at large.  There are three accessible levels of programming in the new beta version of Rhino 5.0:  Grasshopper, Python, and C#, in increasing order of both capability and complexity.  All are a great deal of fun and have different strengths and weaknesses.  What makes the three together a particularly powerful combination is the ability to develop code at the appropriate level of programming sophistication and then to utilize the results in the others.  For example, complex algorithms can be implemented in C# and then expressed as Python commands or Grasshopper objects.

The simplest of the three for programming, the Grasshopper visual language interface,  has become a fascinating starting point of a great number of new features and capabilities.  An interesting example of outside the box thinking is Andrew Payne’s Firefly plugin for controlling Arduino micro-processors.  (I’m looking forward to hearing Andrew’s talk at ACADIA as well.) Grasshopper provides an amazing ability to switch back and forth between the Rhino model and the program, leading to a code development process I like to think of as “Forward-Backward” code development in contrast to traditional “Top-Down” and “Bottom-Up” approaches.

Grasshopper provides a limited set of data structures for passing between program objects, however, basically just lists and lists-of-lists of things.  Great for generating lots of objects but tricky for accessing individuals within those lists and costly in terms of storage because it limits the ability to release and garbage collect intermediate objects; all objects created exist throughout the program.  Code loops are also tricky to implement although this has been addressed with the clever Hoopsnake plugin. Furthermore, although it is easy to quickly generate programs in visual environments, I often find it frustratingly difficult to go back and understand what I built even a short time later.  Developing modular and robust code is tricky, especially in the hands of less experienced programmers.

As a result, after hacking out rough ideas in Grasshopper I tend to move quickly into implementing the complex parts in traditional imperative code.  This is where Python and C# come into play.  It is possible to embed Python or C# code directly into Grasshopper objects for use within that environment, to write scripts directly in Rhino, or develop in Microsoft’s Visual Studio 2010 Integrated Development Environment with all of its attendant debugging and build support. For my work, this is where the rubber meets the road.

Over the next few weeks I will present here some of my initial experiments and short tutorials to enable others to get started at each of the three levels of programming in Rhino and to understand their strengths and weaknesses.  And of course I will be posting from the conference as well.  For those of you active in the field there is a nice LinkedIn group for ACADIA and somehow I have also taken on the responsibility for enlisting support at the conference to get its activities posted there.  Feel free to join in the conversation there as well.

It is a busy time and even if you can’t come to the conference I hope that you will enjoy the vicarious glimpses here instead!  Stay tuned, as there is more to come…!

- Brian -

Breeding Architecture

July 12, 2011
8334

A few weeks ago I posted about a white paper I’d read from SOM on their experiments with genetic algorithms and design.  It lead me to some further investigations into optimization and architecture.  Frankly, I have been reluctant to buy into the idea of computer optimization of architecture.  There are simply too many competing objectives to be optimized and I like to believe that there is an aesthetic component to the built environment that is important.  I say “believe” because I run into plenty of folk who feel the exact opposite: that justifying anything based on the aesthetics of form is a waste of the taxpayer’s money.  Too bad for the taxpayer.  Others have tried to quantify beauty by identifying specific characteristics that we are drawn to and arguing that the more of these found in a particular object the more beautiful it will seem to be.  Good luck with basing your art career on that, much less deriving much satisfaction from the process.

Long Arm by Opah at PicBreeder

Typically, computer optimization uses something called “directed search” and involves defining a space of problem solutions bounded by acceptable solutions and a cost metric that measures a particular solutions “goodness”.  Your goal is to find one or more solutions with a minimal cost.  Once you have a legal solution your cost function gives you a direction to go in so you just keep moving that way until you run out of legal solutions and that must be your best one.  Simple, right?  Wrong.  Even if you can model the problem accurately and define the right cost function, complex solution spaces are full of “local minima” or solutions that look good from where you are at but if you just went over that hump it turns out there is a better solution

over there.  Exploring the solution space efficiently can be very difficult to do.  Even so, designing architecture is all about adjusting the objectives or changing the constraints as the problem becomes better understood.

Butterfly by Adeleinr at PicBreeder

In steps a new area of computer optimization and search loosely termed non-directed or human-directed optimization.  Ken Stanley, of the University of Central Florida, is championing this technique with some fascinating work in creating imagery and music that is generated in part by a search algorithm and in part by human choices as to what intermediate solutions are interesting or not.  The human in the loop “quantifies” the unquantifiable value of aesthetic judgment.  At some level the algorithm has an understanding of value but that valuation is based on human input and changes as the search evolves.

One such project Stanley has produced is called “PicBreeder” in which users interact with an evolutionary algorithm to create two dimensional imagery.

Egg Wearing Hat by Robert at PicBreeder

Some rather beautifulexamples of two dimensional imagery in fact.  The human is not making the choices of how images in this program should change, they simply reward images created along the way that they find interesting.  Setting out with an initial objective or intention as to what you want to produce invariable fails.  Stanley claims that this system produces “art” while removing the “artist” from the equation.  All I can say is that statement that leads to a whole host of philosophical arguments that my inner artist strongly objects to.  But I will say that the images are great, the site is fun to explore, and there appears to be something here that has real potential to enable search in new and complex problem spaces.  Maybe even architecture.  Check it out!

Congrats NASA!

July 8, 2011
NASA_AMES_1982_1

This morning I listened to the launch of the Space Shuttle Atlantis on NPR, the final space shuttle mission.  It brought back a lot of memories for me personally, having started my career nearly 30 years ago as an electrical engineer at NASA’s Ames Research Center in Mt View, California. Pictured here, I was tasked with designing and fabricating a small, standalone data recorder device that was ultimately used in shuttle missions, aboard Russian COSMOS rockets, and even in the Antarctic.  Checkout that Heathkit VT100 terminal and the bubble memory device it is tied into behind!

I joined NASA shortly after the first shuttle launched in 1981 and just in time for my cousin Jimmy and I to travel to Edwards Air Force Base to see the landing of the 4th shuttle mission in July of ’82.  As a NASA employee we got to stay and camp on the facility side of the base, along with plus or minus 20,000 others (and President Regan!).  I remember watching the lines of car lights leading down from the hills on the other side of the lake bed where some 100,000 not so lucky visitors came to see.

It was great to be a part of that experience.  For 50 years NASA has been a driving force behind high technology and can be credited with a huge number of ideas, devices and technology that are now so ingrained in our daily lives we no longer consider them high-tech.  Velcro and Tang being the least of them. We also know from real experience just how dangerous it is to operate such a complex machine in such a hostile environment, and I wish a safe journey to all of the astronauts aboard.  I strongly believe in using non-military scientific programs such as NASA to motivate and give positive direction to our creative drive and entrepreneurship, and hope that through it we will continue to seek new opportunities and set new goals that do so in this new, post-Shuttle era.

Follow

Get every new post delivered to your Inbox.