TAPESTRY: The Art of Representation and Abstraction
Data - Data Structure - Organization
What's it all about?
Geometry gets very complex. When it does, so does editing and manipulation, in part because selecting portions of the data to apply actions to becomes complex. We need mechanisms for identifying just part of the data.
In a completely "flat" data structure all the polygons of a b-rep or polyhedral model would be equal. Selecting and editing data becomes incredibly complex in all but the simplest models due to the 3D data having been projected to the 2D screen. How can these problems be managed?
Names
A simple way to handle the situation is to give each polygon a name and use names as the means of selecting different sets of polygons, in addition to or instead of using the mouse. Numbering them works too, but numbers don't have any inherent meaning to most of us. Of course, making up 10,000 names isn't easy either.
Layers
Partly because of their familiarity from 2D drafting systems, the idea of assigning every data element to a named layer, by which the item's visibility and selectability can be controlled.
Clumps
Another popular idea from 2D systems is the idea of clumping a number of data primitives together and treating them as a single entity. System names for these "clumps" of data vary, but include blocks, cells, symbols, and components. In most systems clumps have Names (above). It is important to distinguish between the data that defines a clump and an instance or reference to the clump. All instances look alike (but, see "objects" below), but they share a single definition, so changing the definition changes the appearance of each and every instance.
Hierarchies
Related to the idea of data clumps is the idea of model hierarchy. In an hierarchical model the data consists of instances of clumps, each of which can be "opened" and edited as if it were a separate free-standing data file. In this way multiple instances of a "rafter", "post", "window" or "chair" can be edited all at once, providing a strong mechanism for refining simple models during evolving designs, as well as a means for isolating and easiliy working with more complex data sets.
Objects
Traditional programming separates "actions" (program) from "data" (information). The descriptions above generally follow this division. More modern programming recognizes that there is a more symbiotic relationship between data and action, a concept covered by the term "object oriented programming". Applied to architecture, this might be said like this--when I put a window (geometry) in a wall (more geometry), there is an implied hole that needs to be created (action) to hold the window. The window is a mix of data and actions. Similarly, if I move a wall that happens to have a window in it, the window should move too. I shouldn't have to select both wall and window to get the job done. Again, there are implied actions associated with the data.
This idea of objects containing both information and action can be extended to the point where we can talk about parametric design and smart geometry at the level of the building, not just the window. These subjects form the core of building information modeling (BIM). While an object-oriented approach might dramatically change the nature of editing a model, when the BIM model is being rendered or displayed, the system still produces polygons and the rendering proceeds as described elsewhere in these pages.
Last updated: April, 2014
