Parametric Pattterns XI: GoalSeeker

2011-09-27_2114

Goalseeker

“Change an input until a chosen output meets a threshold.”

The Goalseeker  begins by stating where you want the design to end, not how you want it to get there.  This is the one pattern that is pretty much impossible in Revit or Vasari (or Grasshopper, for that matter) without some additional coding.  Revit’s engine likes to string a bunch of elements and relationships together and accumulate the pieces into an integrated whole.  This is essentially a bottom up process, where the result is determined by accumulated relationships. Goalseeker is the reverse, where the result is determined and we need to sift through multiple paths to figure out how to get there. Or how to get close.

This is not an easy operation for most platforms, partly because the end result is usually an approximation of an ideal.  Finding the highest point on a hill, for instance, can be an eternal loop of finding points NEAR an ideal “top”, points that are infinitely ever-so-slightly higher than the last measured highest point.  To make sure that the process stops, you need to build in the concept of “good enough”, a fuzzy area that satisfies the human sense of “top” but not a computer’s impossibly precise definition of “top” .  Computers don’t usually like “good enough”.

2011-09-27_2128

In this example, there is a core Goalseeking engine, a python script authored by Aki Hogge, which simply manages an input, an output, a goal, and the differences between them.  What is done with these numbers is defined by good old fashioned family parameters. This allows the heavy lifting to be done by the specialized script, and Revit allows the user to generalize it’s application.

Enough talk, let’s take a look ( I recommend full screen).

Demonstrating a Vasari/Python Goalseeker

Woodbury writes that “Key to writing a working Goal Seeker is understanding how to build the desired measure into the system. Understand how the result will change with changes to the driver”

The interesting part for me is that the same script can be reused for many different applications. While it certainly will not satisfy every application (it’s pretty limited, in fact), it is remarkably generic and portable. That is, it can be used for all sorts of different measurement needs, so long as you just need an input, an output, and a set quantity to measure the output against.

The core of this pattern involves the discovery of base conditions that are now known, but an end state that is known. Usually in parametric modeling the reverse is true: you set up the relationships of pieces and welcome the surprise of a resulting condition. But with the goalseeker, you define what you want the outcome to be and let the algorithm figure out how to get there.

Download Goalseeker python script and sample files from here 

Read how to get started with python scripting in Vasari and Revit here.

Comments

  1. So glad that you brought up this topic in Revit/Vasari context! I really hope that it will become the beginning of the evolutionary problem solving on this platform! I am sure that revit has enough flexibility already (in the massing functionality) to accommodate the Top Down approach.

    ReplyDelete
  2. And finally a new world is openned in Revit world. Programming, comunication with script languages will make revit a superpossibilities software.

    ReplyDelete

Post a Comment