This post serves as a critique for existing modeling methods. In a recent presentation at the Revit Technology Conference, we discussed two plugins which negotiate between Grasshopper and Revit while referencing an Excel spreadsheet. Each plugin cites various parameters from a programming spreadsheet and generates masses in a modeling environment.
After developing this workflow, our next step is to consider how to move from the generated masses to their explicitly defined adjacency in space. For one, we can reference our spreadsheet in both programs and begin to arrange our masses based on different data sets. In Excel, we can sort rows and columns based on data, but our modeling environment allows us to sort these values in three-dimensional space. As a basic example:
This is a good starting point to serve as a way of organizing and arranging our volumes. After this, we can begin to manually model the building to create a massing scheme. Now, the two existing ways to move our geometry in Rhino are with O-snapping and Gumball.
O-Snapping has the accuracy, but users are prone to error if they snap to the wrong thing. Snapping by points is also cumbersome when dealing with such primitive geometry as these boxes. On the other hand, the Gumball is a great tool for quickly transforming objects. The interaction is similar to many that we see with soft modeling programs and is a great addition to Rhino. However, one does not have the accuracy of O-snapping when working with the Gumball, and using a hot-key to toggle the O-snapping mode in Gumball doesn’t solve the problem. While we often work with primitive boxes, especially in the case of programming with massing models, we are considering a hybrid between these two methods, which we’re calling the Box Snap.
We’ve setup the Box Snap with a Grasshopper definition which uses a basic Python Script to translate the objects in Rhino. A listener in Grasshopper detects when an object is selected (using the Human Grasshopper plugin). When the object is transformed, the definitions detects the nearest point or edge of adjacent masses. After performing a Gumball operation, the Python Script will then snap to the nearest adjacent mass.
A range is defined for snapping to a vertex instead of an edge. For example, if the selected mass is moved to a region within 30′ of the vertex of another mass, it will snap to that vertex. Otherwise, the selected object will snap to the adjacent edge of a nearby mass.
This technique tries to address the two main issues of early massing models: ease of use and accuracy. Since the masses are all cleanly snapped together, it’s much easier to setup the model for simulations, especially daylighting and thermal ones. The solids are already connected at each face and one can use a Grasshopper definition to automatically apply fenestration patterns based on a target transparency for cardinal directions. Adjacent faces to masses can be declared as adiabatic and one can easily perform a thermal simulation with DIVA within a matter of minutes.
This way we can minimize the gap between conceptualization and modeling, and also minimize the gap between modeling and simulation. A designer can test out a range of massing schemes and be more informed with regards to its performance, all within a matter of minutes. As it stands, the tool is a bit of a work-around (it isn’t ideal to have a Grasshopper definition running in the background). In either Revit or Rhino, it would be great to see a Gumball/O-snap option for boxes and other volumetric primitives which works along these lines.