CHAPTER TWO

The Evolution of
Computer Models in Building
We envisioned even then the designer seated at a console, drawing a sketch of his
proposed device on the screen of an oscilloscope tube with a “light pen”, modifying
his sketch at will, and commanding the computer slave to refine the sketch into a
perfect drawing, to perform various numerical analyses... . In some cases the
human operator might initiate an optimization procedure... . The different powers of
man and machine are complementary powers, cross-fertilizing powers, mutually
reinforcing powers.

Steven Coons
“An Outline for the Requirements for a Computer-Aided Design System”
AFIPS Conference
1963

2.1 INTRODUCTION
Credit for developing the world’s first interactive computer-aided design (CAD) system belongs to
Ivan Sutherland, who in 1963 developed special graphics hardware and a program called
“Sketchpad” as for his Ph.D. dissertation. He conceived Sketchpad as a drawing assistant; it
cleaned up rough drawings by straightening and connecting lines, constructing geometric patterns,
and in other ways anticipating a designer’s intent. Sutherland not only wrote the software, he also
had to build the display and interaction hardware. The above quote by Sutherland’s thesis advisor
discusses the initial plans for CAD systems. Sutherland continued to make contributions to CAD
and computer graphics and co-founded a high-performance computer graphics company.

Sutherland’s thesis introduced a new generation of technology supporting design and fabrication.
However, it took six years to develop the technologies that would allow CAD to become a
production tool. Several different technologies were involved. The display technology in
Sutherland’s thesis was new and needed to be redesigned in order to be mass produced. Also,
demonstrating the first version of Sketchpad required dedicated use of one of MIT’s campus
mainframes. This was not feasible for practical use, even in a large company. Small, cheap
computers were needed. And, of course, the various pieces had to be integrated and new software
developed.

It took six years, to 1969, before Computervision Corporation built and marketed the first
commercial CAD system, a system for constructing drawings defined by textual commands and
displayed on a plotter. It relied on one of the first mini-computers. In 1970, they introduced an
early CRT display tube allowing direct interaction. By the early 1970s, new CAD companies were
forming monthly: Applicon, Calma, Autotrol, Intergraph, CADAM and others. In terms of the
media attention and entrepreneurial enthusiasm, the emergence of CAD in the 1970s was similar
to the emergence of the personal computer in the 1980s and multimedia in the 1990s.

This chapter begins by reviewing the main threads of research supporting interactive computer-
aided design and similar applications. It presents a historical review of the display, hardware and
36 Part One: Context and History of Building Models

software technologies. Although once they were an inhibiting context for the development of
complex applications in building, these technologies now enable development. We consider CAD
here for its use not only during the design phase of a building project, but as a means to represent
and manipulate a product specification throughout a building’s lifecycle. Thus we consider CAD
in its broadest sense, ultimately being concerned with the full representation of a building and the
products that comprise it, whether used during design, construction planning, operation or
management.

Computer-aided design systems have evolved according to three general but distinct paradigms.
One paradigm is as a geometric editor. Another more recent paradigm looks at a CAD system as
an environment for developing discipline-specific applications. Most current CAD-system vendors
address work within both of these paradigms, with varying success. Last, some design systems
have been developed to support domain-specific applications but with the addition of a well-
defined central model for representing building information. Early efforts based on this paradigm
did not accept the CAD-system-as-graphic-editor paradigm, instead focusing on the need to
develop what is now called a building model. It is to this third paradigm that commercial CAD is
finally turning today. In the second half of this chapter, three early groundbreaking efforts in
building modeling are reviewed.

PROCESSOR DISPLAY
CAPABILITIES TECHNOLOGY
8Mh 286PC calligraphic displays
16Mh 386PC storage tube displays
33Mh 486PC hardware transforms
100Mh 486PC VGA raster displays
150Mh Pentium 24-bit color, z-buffers
200Mh Pentium Pro hardware texture mapping
300 Mh Pentium II hardware anti-aliasing
400 Mh Pentium II
CAPABILITIES IN
COMPUTER AIDED
DESIGN
SOFTWARE AND
ALGORITHMS
hit testing, line clipping, surface
modeling, hidden line removal,
surface shading, solid modeling,
texture mapping, ray tracing,
radiosity modeling, animation,
object-oriented modeling

Figure 2.1: The three technologies that computer-aided design is based on and that
determine its capabilities.

2.2 CAD TECHNOLOGIES

Early computer-aided design was very technology intensive, beyond the capabilities of most
computer processors, early displays and systems capabilities of the day. CAD has consistently
been a technology-intensive application, "driving" the technology with its potential market for
high-end capabilities. Today, hardware technology has largely caught up with these demands,
allowing interactive 3D CAD to runslowlyon everyday desktop machines.

Computer-aided design is dependent on three different types of technologies, diagrammed in

Figure 2.1:
Chapter Two: The Evolution of Computer Models of Buildings 37

(1) display technology: CAD motivated the first graphic display monitors; teletypes that printed
on paper were used at the time. Evolution in display technologies has allowed us to move
from low resolution monochrome static displays, incapable of displaying much detail or to
quickly update a display, to large-scale monitors and high performance graphics boards
supporting increasingly fast dynamic color displays. Graphic boards incorporate important
display and processing capabilities, such as high resolution, wide color ranges, z-buffering,
line drawing algorithms, anti-aliasing, transforms, surface shading and texture mapping.
These technologies are the basis for all high quality, dynamic imaging capabilities now
commercially available, including those for games.
(2) processor capability: The earliest CAD systems relied on command-line interaction, where
the user typed in each operation as a command. This was mandated because early display and
processor capabilities were not able to support the processing required for graphical user
interfaces. Object dragging and 3D capabilities only became possible on high-end CAD
systems when processor speeds became fast enough to support these operations. This
threshold was reached with the introduction of the Motorola 68000 and the Intel 386. Still
today, a complex 3D model can slow any processor and display device to a crawl. However,
the transition time to PCs has been constantly decreasing and high-end PC-level machines are
now competitive with traditional workstations. Today, real-time interaction is the target
capability that drives high performance processors and display technology. The next
generation of interactive capabilities is being developed directly for high-end PCs.
(3) software capabilities: Early software issues dealt with low-level issues such as how to quickly
draw arcs and thick lines. Then came issues of perspective views and hidden line removal.
Later came the technical issues of quick shading based on various lighting models, editing
operations on surfaces and then on solid models. Recently, the issues in software design have
included real-time renderingespecially with mapped texturesand new forms of 3D
manipulation and editing. Another developing research area is trying to take advantage of
image coherence between animation frames, instead of computing each frame individually.
Parametric geometric modeling is another software area that is allowing new products to be
introduced, supporting innovative capabilities.

Beginning in the mid-1950s, computer applications were written to automatically calculate

engineering formulas that had previously been calculated manually. Computer programs also
supported material procurement and billing services. It was the representation of geometry,
however, that suggested a major role for computers in the design and manufacture of products.
The earliest peripheral devices that could deal with geometry were plotters. They generated a
drawing from a description consisting of a list of line segments, defined as pairs of X-Y location
coordinates. Initially, arcs and text were generated using software that converted text fonts into the
short line segments needed for each letter. In this sense, the earliest CAD systems represented a
product simply as a list of line segments and text strings located within some coordinate system.
Early display technology followed an approach similar to that used by plotters. An electron beam
in the display traced lines, curves and text on the phosphor of the display tube. The excited
phosphor lit up for only a short period; hence the drawing had to be constantly refreshed. This sort
of display was called a calligraphic display. Calligraphic displays required their own processor to
continually refresh the drawing and their own memory to hold a list of display commands. Thus,
their cost was very high, initially over one hundred thousand dollars. The earliest CAD systems
were all based on calligraphic displays. For some details regarding the initial development and
dates of CAD-related technologies, see Figure 2.2.

Later, CAD companies developed and used several other display technologies, including storage
tubes (principally sold by Tektronix) and plasma displays. In the late 1970s, pixel-based bitmap
displays became available and within a few years grew to dominate the display market. They were
initially limited because they required a large amount of memory (by the standards of the day) to
38 Part One: Context and History of Building Models

hold the display image. While they required a special display processor, the technology was very
simple compared to calligraphic displays. Pixel-based bitmap displays also used display monitors
very similar to those used for television.

TIMELINE
Engineering analysis (ICES, MIT)
GM and IBM begin DAC
Calliographic Displays
Storage tube displays
Color Raster Displays
Digital Equip. PDP-11
Internet created (ARPANET)
Xerox Alto (first workstation)
IBM Personal Computer
Silicon Graphics (real-time surface display)
Apple Mac II
World Wide Web formed

1960 1970 1980 1990 2000

PC-based virtual reality
Virtual Reality (SGI)
PC solids modeling
Wavefront formed (visualization)
Autodesk formed
First 3D building model
First solid modeler
M&S Computing (Intergraph) formed
Autotrol formed (overlay drafting)
Computervision formed
Sutherland's Sketchpad

Figure 2.2: A timeline of major technological developments affecting computer-

aided design.

Computer-aided design was an early interactive application that required very large amounts of
dedicated processor time to respond to a user’s commands. In the 1970s, personal computers did
not yet exist. The development of mini-computers priced at 20 to 40 thousand dollars in the 1970s
made CAD a practical possibility. Such mini-computers, using a simple timesharing system so two
to four people could use the same machine at once, barely allowed interactive execution of a CAD
program. The most popular early mini-computer for CAD systems was the Digital Equipment
PDP-11, with 32 thousand words of 16-bit memory and a processing speed of about 200 thousand
operations per second. This is much less than a first generation PC! Nonetheless, these machines
offered a huge increase in the number of computing cycles per dollar continuously available to an
individual.

From its beginning (1970-1975), CAD software was developed in an evolutionary manner, with
only a limited analytic or formal base. Research was intense in the development of algorithms for
drawing curves, panning and scaling images or parts of images, and so forth. CAD companies
proposed different data structures for representing geometrical data and each company introduced
enhancements to gain market advantage over its competitors. If a company’s innovation was
successful, others soon copied it. Those that did not evolve in this way soon lost market share, in
classic Darwinian fashion. Some features that evolved in this way were (i) symbols, introduced
first as purely graphic entities, then later as data-loaded ones; (ii) layers, as a means to structure
data; (iii) user application languages; (iv) associative cross-hatching and associative dimensioning;
(v) 3D wireframe and surface modeling; (vi) solid modeling; and recently (vii) integrated
rendering modules and (viii) parametric solid modeling.
Chapter Two: The Evolution of Computer Models of Buildings 39

2.2.1 PERSONAL COMPUTERS

Up to the middle 1980s, CAD systems were developed for mini-computers or time-shared
mainframes. Unix or VMS (the proprietary Digital Equipment Corporation operating system) were
the main operating systems available. Systems running on these operating systems are generically
called workstations.

Even before the introduction of the IBM Personal Computer (PC), a few efforts were made to
develop personal drafting systems. The Apple II, though limited to 64K word of memory, was the
first popular, personal computer and some early drafting systems were developed on this machine.
The IBM-compatible PC, introduced in 1981, and the Apple Computer Macintosh, introduced in
1982, were big steps forward in terms of processing power, with 640K and 256K words,
respectively. Simple CAD systems were quickly developed for these machines. Initially, the
capabilities of these systems were toy-like, unable to include what were considered minimal
features for an effective CAD system, even for 2D drafting. However, the cost reduction was
dramatic. Until the advent of the personal computer, a CAD workstation cost on the order of
$30,000, which only a few organizations in the building industry could afford. Many buyers of
workstations had to use multiple shifts of operators to justify their cost. Operators were specially
trained to operate the machine constantly; even the occasional unskilled use of these expensive
machines by an architect or engineer was too inefficient.

Several companies began developing CAD software for the IBM PC and the Apple Macintosh,
including Autodesk, VersaCad, Summagraphics, Microstation and others. Initially, these systems
were also very limited, with poor graphics, little storage and even less speed. With the
introduction of the Intel 80386 and the large screen Macintoshes in the late 1980s, desktop CAD
truly became available in the $5,000 range. The evolution of the Intel family of processors is
shown in Figure 2.3. As the cost of CAD systems dropped, their potential market exploded. A
CAD system could be purchased and used possibly only a few hours per day, without fear of
wasting an expensive machine. Architects and engineers could use it without the supposed
efficiency of a CAD operator. The required investment was of the same order of magnitude as a
good typewriter (considering inflation). Today, the capabilities of CAD are available to anyone
with access to a PC.

Processing power was not the only demand CAD systems put on PCs. They also had to improve
display and graphic capabilities. Neither the PC using EGA graphics, nor the early Macintosh with
its small monochrome display, was adequate for serious CAD use. Effective CAD use became
practical only after display processors and monitors attained SVGA resolution (800 x 600 pixels),
at least 256 colors and fast line and arc drawing.

As personal computer processing speed increased, more of the capabilities available on

workstations migrated onto them, such as 3D surface and solid modeling, dynamic “rubber-band”
editing of graphic entities, and shaded rendering. Thus, while these capabilities have been gaining
widespread use, they are not new. The late 1980s and early 1990s have been a period in which the
CAD market has consolidated and expanded.

As a result of these technological advances, many limitations in using computer-aided design have
disappeared. Costs of systems are low and their speed and versatility continue to increase.
Development of new forms of computational support for building is no longer limited by system
costs or the quality of displays. Rather, imagination and the ability to change the status quo—that
is, the intellectual capabilities within the fieldare the primary limitations to future progress. The
generic capabilities produced thus far have not really begun to address the specific needs of
architecture or construction. More specialized capabilities are needed that respond to the
representations, procedures and practices of the building industry.
40 Part One: Context and History of Building Models

1,000

Pentium Pro
100 Pentium
80486
10
80386
80286
1

8088
0.1 Source: Intel Corp.

1975 1980 1985 1990 1995 2000

Figure 2.3: The logarithmic increase in computer speed for the family of Intel
microprocessors. The vertical scale is MIPS, or millions of instructions per second.
Desktop computers are now typically 100 MIP machines.

2.3 CAD AS A GEOMETRIC EDITOR

Many application areas have been developed for building use. However, the one most central to all
building lifecycle phases, as identified at the end of Chapter One, involves the representation and
manipulation of building geometry, as defined in a CAD system.

A CAD system is a very large computer program, written in a programming language such as C or
C++, whose size can range from 30,000 lines of program code to several million lines. In order to
deal with such a large and complex system, developers organize their software into functionally
based modules. That is, a CAD system has a design. Like other aspects of the CAD industry, CAD
system design has evolved incrementally.

A typical design for a CAD system with traditional functionality is shown in Figure 2.4. This is
not the organization of any specific CAD system, but rather a structure similar to many different
systems. Each of the boxes shown corresponds to a software module, which has multiple inputs
and outputs, defined by arrows. Some of the arrows are labeled. Thus we see that there is a user
interface module (now typically Windows or MOTIF, the Unix graphical user interface) that
receives all user input and passes it on to a command processor. The command processor
packages up individual mouse selections and sorts them to properly define a graphical operation
that the system can understand. The interaction facilities provide high-level feedback to the user,
such as rubber-banding, stretching and real-time coordinate readout that are not part of the base
user interaction. Operators are of two types. One type consists of the given primitive operators of
the CAD system, defined in the figure as graphical operators. These are part of the base-level
CAD system. The other type consists of sequences of base-level operators called by application
code and interpreted by the application language. The graphical operators operate on graphical
primitives—lines, curves, text, as well as on any selection or layer of the drawing. The graphical
operators and the data structure for representing them may be organized together as objects, or
may follow more traditional organizations. The operators typically apply to an in-memory display
list, where most operations take place. These are mapped back to a disk file format, typically
either after every operation or during "save" operations. IGES and other report generators typically
operate on the in-memory version of a project description.
Chapter Two: The Evolution of Computer Models of Buildings 41

USER

WINDOW MANAGER

1. cursor location
defines action
INTERACTION 2. action translated
UTILITIES into graphic
operator
3. parameters
identified,
APPLICATION LANGUAGE
including possible
COMMAND PROCESS
prompts and
responses
4. new results
displayed,
possibly
APPLICATION CODE
dynamically
5. updated entities
stored
GRAPHIC OPERATORS

GRAPHIC PRIMITIVES
SYMBOL LIBRARY ADDRESSABLE
DISPLAY LIST DRAWING
IGES STRUCTURE
REPORT
GENERATOR
SYMBOL
LIBRARY
DRAWING DATABASE

LAYERS LAYERS LAYERS

Figure 2.4: The typical structure of a modern CAD system.

This structure suggests how the functionality of CAD systems is organized. It suggests how a
CAD program could be “ported” to another machine—namely, by recompiling the software code
and, if necessary, restructuring the user interface and database modules. It also shows where errors
may occur. Later, we will refer to this figure to explain how some of the evolutionary features and
current capabilities arose.

2.3.1 CAD SPECIALIZATION

Initially, CAD systems were not differentiated and were sold in all markets that relied on
drawings, such as electronics, manufacturing, building construction, petrochemical plants, road
building. However, some companies began developing special operators and features needed in
particular markets. Other companies that could not develop their product fast enough to provide
the capabilities desired in ALL user markets began to specialize in one or just a few markets,
leading to product differentiation.

One of these specialization areas was sheet metal manufacturing. The aircraft and automobile
industry realized early that drawings were not the main object to be represented, but rather the
development of surfaces. Surfaces could only be poorly represented in drawings, requiring
42 Part One: Context and History of Building Models

interpolation between a large number of sections drawn through the surface. However, the
mathematical definition of a surface provided all points on the surface. Because of their
completeness, surface representations could be used to guide the fabrication of sheet metal
components with great accuracy, using numerical control machining that was developed in parallel
with CAD. In 1966, Steven Coons, Sutherland’s Ph.D. advisor, who taught engineering drawing at
MIT, developed the first curved surface modeling and editing techniques. It was his vision that is
quoted at the beginning of this chapter. In tribute to his pioneering work in the field, the modeling
techniques Coons developed came to be called "Coons’ patches". Another early pioneer was Pierre
Bezier, who, while at Renault, developed surface modeling techniques called Bezier surfaces,
which are still used today. Surface modeling was important because it was the first example
showing that the objective of CAD was to represent the object being designed, not a drawing of
the object.

Special-purpose CAD systems were developed in other areas as well, including (i) electronics,
where each step in the design and fabrication of a circuit board or silicon chip has been highly
automated; (ii) shipbuilding, which also relies on specialized operations for hull design and
analysis, steel plate definition and welding, and bulkhead design and fabrication; and (iii)
geographical information systems (GIS), which involve large mapping databases. Initially, these
specializations were treated as application areas and special features were simply added to a
general-purpose CAD system as application code, as shown in Figure 2.4. Eventually, they
became separate from standard CAD systems because they required unique representations and
base operations that were not supported by general-purpose CAD. However, as all CAD systems
matured, some capabilities that were once only available in special-purpose CAD systems have
actually migrated back to general-purpose CAD. Parametric surfaces, solid modeling and
kinematics, for example, are currently moving from special-purpose CAD to general-purpose
systems.

2.3.2 SOLID MODELING

In the late 1970s, 3D wireframe drawings were introduced into general-purpose CAD systems as
an early 3D capability. This was a incremental step, adding 3D vertices, new editing operations,
3D coordinates and a multiple view display allowed both users and developers to begin working in
3D. Soon after, some simple surface modeling capabilities were introduced to general-purpose
CAD systems, allowing full 3D representation. It became possible to represent surfaces because
pixel display systems could show colored shaded areas in addition to lines. The display of shaded
surfaces greatly expanded the need for a large range of colors. Older pixel displays supported only
4 or 16 colors. New algorithms were soon developed to enhance the capabilities for rendering
smooth shaded surfaces, casting shadows, properly displaying surfaces that are partially blocked
by other surfaces, and other needs.

Modeling an assembly of complex parts required defining the multiple surfaces of each shape by
specifying each surface, trimming and adjusting them so their edges matched. This was a very
tedious task. Research groups at several universities worked on the problem of making surface
modeling simpler, and on defining higher level editing operations. In 1973, two independent
efforts developed related approaches. One came from Stanford University, where Bruce Baumgart
designed and implemented a shape modeling program that defined an object by the set of surfaces
that bounded it. The program had operators that, given two shapes, generated the union,
intersection or difference of the shapes. These operations are called the Boolean operators and are
demonstrated in Figure 2.5. At about the same time, Ian Braid at Cambridge developed a similar
system. Both programs included new graphic operations that combined two solid shapes, each
defined as a volume enclosed by a set of surfaces, and returned another solid shape. Because the
result was always a closed shape, iterated operations were allowed. New data structures for
representing solids were developed. These were added at the graphic objects level of a CAD
Chapter Two: The Evolution of Computer Models of Buildings 43

system, as shown in Figure 2.4. Because a solid was represented by the surfaces that bounded it,
this form of solid modeling was called a boundary representation or BRep. Later, other forms of
solid modeling representations were developed.

UNION INTERSECTION BLOCK MINUS SPHERE MINUS

SPHERE BLOCK

Figure 2.5: Examples of solid modeling operations.

This work was soon followed by a formal analysis that determined the properties needed to
guarantee that a set of surfaces was volume enclosing and to make solid modeling an abstract
algebra. Not any set of surfaces is sufficient to represent a volume-enclosing region. A set of well-
formedness rules is needed to distinguish a well-formed BRep from any set of surfaces. Among
these are topological properties requiring:
(1) all edges to be two-connected; that is each edge on a face must coincide with exactly one
other edge on a face
Geometrically,
(2) all faces must have consistent orientation
(3) no faces can self-intersect
Many volumes have holes through them, such as a wall may have for a door or window. A volume
may also be hollow, with another shape inside that bounds the volume. For example, if all the
constructed parts of a building were combined by unioning them together (with doors closed), the
rooms would remain outside the construction volume but be interior to the building. In such cases,
the outside set of surfaces enclosing the building would define a closed volume, called a shell, and
the interior set of faces enclosing the room volumes would define other shells. All the shells
together bound the solid part of the building. Both of these conditions impose additional
constraints regarding orientation:
(4) edges bounding a surface with holes must be consistent with regard to the side of the
edge adjacent to the surface
(5) the surfaces defining a set of shells making a volume with hollows must have consistent
orientation
Other well-formedness conditions have also been defined.

These capabilities had several benefits. For one thing, they allowed users to take high-level design
actions, similar to sculpting, that automated all the detailed actions involved in cutting multiple
surfaces that in surface modeling had to be dealt with manually. These high-level actions also met
the properties of a formal algebra, and thus could be concatenated, allowing the automatic
computation of complex shapes. They were intuitively much simpler than surface modeling, where
each type of surface had its own editing style. In the late 1970s, solids became commercially
available, though not in stable form until the mid-1980s. They are now available in most CAD
systems developed for the Architecture, Engineering and Construction (AEC) markets.

For most industries, there were many benefits to be gained from moving from 2D to 3D, whether
it involved surface or solid modeling:
44 Part One: Context and History of Building Models

• Any number of drawings could be automatically plotted as reportsby cutting sections or

making various isometric or perspective projections from a 3D model. All drawings extracted
from the same 3D model were guaranteed to be consistent with each other. No other means
have been developed so far that can guarantee the consistency of a set of 2D projections
supposedly describing a single 3D shape or assembly.

• A 3D model could be used in many ways that a drawing could not. Among the many uses
were 3D visualization, automated machining and manufacturing, and as input to various
forms of analyses. Except in special cases, these uses were not possible from a digital drawing
representation.

The use of 3D modeling has allowed many advances in certain industries, especially in
manufacturing, aerospace and process plant design and construction. For example, it has
facilitated the integration of design and analysis applications and facilitated automatic fabrication
and assembly. The building industry must still make the transition from paper or electronic
drawings to 3D modeling to realize these benefits.

2.3.3 PARAMETRIC MODELING

More recently, a new generation of geometric modeler has been introduced, based on parametric
modeling. These systems move away from the conceptually straightforward notion of a geometric
editor. In earlier solid and surface modeling systems, the user entered a sequence of parametric
definitions to define a shape or editing operations on a shape. Examples of parameters might be
the three dimensions and location of a solid box, the location and diameter of a sphere, an edge
that needs to be filleted and the radius of the fillet or the cross-section of a shape and the centerline
that the cross-section sweeps through. In general-purpose geometric modelers, these parameters
are evaluated and a set of surfaces corresponding to the resulting shape is generated. Further
operations, including union, intersection and difference, may be applied to the current shape. No
history is retained of the operations used to generate the current shape.

In a parametric modeling system, a shape is defined through a similar set of construction

operations. Each operation is defined with its parameters. But in addition to evaluating the
resulting shape as a set of volume-enclosing surfaces, the modeler retains the set of input
construction operations and parameters. These operations form a set of operators and operands in
the form of an algebraic expression. This expression can be later edited—graphically or
textually—and the shape automatically regenerated. Such editing capabilities are very useful in
design, where the geometry of a product is refined over time. Shapes may be refined by changing
their existing parameters or by adding additional operations to the model.

An example of a simple parametric solid modeler is shown in Figure 2.6. A menu of primitives
and operators is shown at the top. In practice, they would be presented to a user graphically. The
algebraic expression of primitives and operations defined up to now is shown in the middle of the
figure, along with the parameters. The layout of the primitives, without the application of the
operators, is shown at the bottom left. The evaluated shape is shown at bottom right. The algebraic
expression in the center of Figure 2.6 is called the unevaluated representation of the parametric
model. The bottom-right figure is called the evaluated representation. In Figure 2.7, a sample
editing operation is shown. Suppose that the user selected one of the points defining the front roof
plane and changed its Z-value. Upon re-evaluation, the new evaluated model would appear on the
right. Very complex parametric models can be defined, with each of the original defining
operations available for editing.
Chapter Two: The Evolution of Computer Models of Buildings 45

A SIMPLE PARAMETRIC MODELER:

1. A set of primitives of the form: 2. A set of operators:
BLOCK(x,y,z,transf) UNION(S1,S2,S3,....)
CYLINDER(rad,l,transf) INTERSECT(S1,S2)
BALL(rad,transf) SUBTRACT(S1,S2)
PLANE(pt1,pt2,pt3) SLICE(S1, plane,bool)
CHAMFER(edge,depth)

UNEVALUATED MODEL (as stored):

SLICE( ,1 )

PLANE((0.0,0.0,10.0),(35.0,0.0,10.0),(35.0,10.0,18.0))

SLICE( , 1)

PLANE((35.0,10.0,18.0),(35.0,20.0,10.0),(0.0,20.0,10.0))

SUBTRACT( )

BLOCK(4.0,3.0,7.0,(33.0,6.0,1.0,1.0,0,0,))

SUBTRACT( )

BLOCK(34.0,19.0,8.0,(0.5,0.5,0,1.0,0,0,))

BLOCK(35.0,20.0,25.0,(0,0,0,0,0,0,))

UNEVALUATED MODEL EVALUATED MODEL:

primitives displayed):

Figure 2.6: A simple unevaluated parametric model and its evaluated result. The
parametric model is defined and stored as a set of parametric primitives and the
sequence of operations modifying or combining them. The primitive shapes are
shown bottom left, the evaluated model is shown at bottom right.

UNEVALUATED MODEL: EVALUATED MODEL:

Figure 2.7: An example of an editing operation performed on the parametric model

defined in Figure 2.6.
46 Part One: Context and History of Building Models

Development of a wide variety of tools allowing direct manipulation of 3D forms has been the
important benefit of solid modeling. Solid modeling technology allows people to create and edit
shape directly on the computer, providing an effective alternative to working with 3D physical
models. In all likelihood, solid modeling will become the dominant representation for building
geometry in the next few years.

2.4 CAD AS A PLATFORM FOR APPLICATION DEVELOPMENT

In the previous section, we discussed the use and evolution of CAD as a geometric editor. Another
view of CAD is that geometry is only one of many attributes involved in the representation of a
product. This view takes the position that representing a product as geometry alone is very
incomplete. To the basic representation of geometry, it adds other properties, such as material and
performance properties, and to the structure of that representation it adds relations between
entities. Material and performance properties of objects are defined as attributes, represented as
text, numbers or compositions of simple values (such as RGB color values).

Mathematically, connectivity and other such relations are known as a system's topology and are
most commonly represented as a graph. Representing structural systems requires the prescription
of elements that are “connected” to others for the transmission of stresses. For a piping system, the
connectivity of the piping system must be prescribed for flow analysis. Similarly, in architecture,
the connectivity of rooms is needed for dealing with privacy, accessibility and to check fire-exit
codes. Wall boundaries are needed for energy analysis. Many types of relations are required in
different contexts. There are prescribed means with which most CAD systems carry attributes and
define topological relations between elements.

This view considers a general-purpose CAD system as a platform upon which to add domain-
specific capabilities. The CAD system provides the low-level capabilities needed to support
special-purpose functionality. In addition to representing geometry, it must also be able to
represent attributes and support creation, selection, editing and deletion of attributes. It must also
be able to represent topological networks and support them with editing capabilities. Also, a CAD
system that supports application development has to provide an application development
language, allowing the definition of specialized entities with their associated geometry, attributes
and topological relations and providing special operators to edit and manipulate the special
objects. Most CAD systems today have made these extensions, supporting customization.
Several additional subtle capabilities are required to support open extensibility:
• providing ways for new operations or applications to be added to the base system, in terms of
menus and graphical user interface
• providing a means to associate attributes, topology and geometry together; the most common
means was to associate attributes and topology to the geometry using the CAD systems
symbol capability
• ability to block certain basic operations, so that they cannot be applied to application-defined
objects, destroying the internal consistency built up in the special application operations
• easy interfaces to load external data, such as material or performance properties of entities
• means to interface existing "legacy" applications to these specialized CAD models, allowing
data to be extracted from the CAD system to run on the application, or for loading the results
of another CAD program into this one

CAD systems that provide an application development platform allow implementation of some
powerful and useful applications. While a geometry editor carries no special knowledge beyond
geometry about a product, the extended applications built on top of them are able to incorporate
many types of domain-specific knowledge. They can incorporate design or construction rules,
checks about legal compositions and other product information of central importance to the
Chapter Two: The Evolution of Computer Models of Buildings 47

product field. For a given type of product design, these capabilities can be immensely useful and
begin to realize the image of a CAD system as a design or engineering assistant.

The current generation CAD systems were first developed in the early 1980s, with only partial
cognizance of the need to support application development and before the development of modern
object-oriented programming techniques. Most current CAD systems evolved from electronic
drafting systems, using the paradigm of geometric editor. Today, the main vendors are attempting
to restructure their systems to support object-oriented development. They are integrating Internet
and Web-based communication, so as to provide a future-oriented application development
platform. At the same time as they develop new technologies for application development, CAD
vendors need to support current customers who desire only incremental improvements. The
challenge is to maintain one's current customer base while at the same time rebuilding the
foundation code supporting all system operations.

2.5 EARLY EFFORTS AT BUILDING MODELS

Even though a single CAD system may support the effective development of multiple add-on
applications, it is not likely that these applications will operate together. The different applications
may each rely on different definitions of the objects representing a building, different relationships
among objects and different rules of how objects are composed. In fact, most applications built on
top of the current main CAD systems are not compatible with the other applications on the same
platform. This is the natural result of each application having its own representational needs and
its own concepts and semantics about how a building is defined.

In the early days of architectural CAD, however, a few systems evolved from assumptions quite
different from those associated with geometric editors. That all the separate computational tools
needed to design and build some facility should be integrated around a central representation of a
building is not a new idea. In the mid-1970s, a number of independent efforts were made to
develop integrated systems, based on a single building model supporting a suite of applications.
These systems were developed before the existence of platform-based systems and developed
from scratch an integrated system supporting building design. They were based on the assumption
that the basic task of design was to develop a specification of a building, supported by applications
to define the various components and to analyze the behavior of the compositions. These efforts
each defined a single, coherent representation of a building around which all applications should
be built. More than one of these eventually evolved into commercial CAD systems, but as a result
of this different heritage, offered different capabilities and provided different bases for future
application development than standard CAD systems.

Most of these efforts were British. Three early building modeling systems were funded by Her
Majesty’s Health Service, the national health agency: the OXSYS CAD system from Applied
Research of Cambridge, and the CEDAR and HARNESS hospital design systems. A fourth major
effort was funded by the Scottish Housing Authority and developed by a group at the University
of Edinburgh. Three other efforts were made in the US. An important but largely forgotten early
effort was a building model supporting design using the Techcrete precast concrete construction
system. Techcrete was developed by architect Carl Koch and Associates and the building model
was developed by Theodore Myer of Bolt, Beranek and Newman. Another research group was at
the University of Michigan; their best known model was called ARCH-MODEL. ARCH-MODEL
went through several versions, each expanding on the original earlier capabilities, and eventually
evolving into a Macintosh-implemented CAD system. It was based on a consistent model of
geometryusing solid modeling and a relational database for storing non-geometric data. The
other effort was the author’s work at Carnegie-Mellon University, where three different building
modeling systems were developed and tested: BDS, GLIDE and GLIDE-II.
48 Part One: Context and History of Building Models

Here, three of these early efforts are reviewed: (1) the council housing effort by Aart Bijl at the
University of Edinburgh; (2) the OXSYS CAD system developed by Applied Research of
Cambridge, a commercial firm, but as a research project for the national health service; and (3) the
CAEADS system developed by the author’s group at Carnegie-Mellon University along with the
University of Michigan, sponsored by the National Science Foundation and later by the US Army
Corps of Engineers. These have been selected because accessible documentation on them still
exists and their impact on later efforts.

In the following discussion, an attempt is made to reconstruct the ideas and issues involved in the
three efforts, based on recollections and discussions with the developers near the time they were
finished and the reports on this work that still exist. It is useful to consider them with respect to the
timeline shown in Figure 2.2, which shows what hardware and software capabilities were
available at the time. These early efforts responded to building modeling issues in an intuitive
fashion, addressing the problem at hand by defining the needed concepts as they were recognized,
often anticipating concepts that were more formally developed only much later. The systems
surveyed here, plus the other systems mentioned above (accessible through references at the end
of this chapter) have provided some of the foundations for current integrated building model
efforts. The supporting drawings and images have been taken from original sources. Many are of
low quality, but are presented to indicate the functionality provided by these systems.

2.5.1 SCOTTISH SPECIAL HOUSING AUTHORITY HOUSING SYSTEM

An early housing and architectural design system was developed by the Architectural Research
Unit at the University of Edinburgh, led by Aart Bijl. It was funded first by the Scottish Special
Housing Authority (SSHA) and then later augmented at the national level by the Department of
the Environment. Funded research began in July, 1969, and continued into 1973. It was
undertaken in two major projects: the first focusing on housing unit design, the second addressing
site planning for housing estates. The period in which this project was undertaken can be discerned
from the computer equipment shown in an early photograph from the first project's research
report, which is reproduced in Figure 2.8.

Figure 2.8: Reproduction of the hardware configuration used in the first phase of
the SSHA Housing Design System: a Digital Equipment PDP-7 with 8K memory
and 340 display.
Chapter Two: The Evolution of Computer Models of Buildings 49

The goal of these two related projects was to develop practical tools. In these early days, the
distinction between prototype and production software was not as clear as it is now. Thus it was
planned that the hardware, and the software system developed on it, would be passed over to
SSHA and they would continue using the hardware, maintaining and further developing the
software. The SSHA was evidently a very forward-looking government unit. It had previously
developed very organized quantity surveying methods. Part of these methods was a well-
structured set of “units of construction” and “units of work”, providing an important, rational
foundation for developing the CAD applications.

Both systems involved definition of a design development process that could produce the desired
product specifications and that could be realized on a computer. Both reports included early
process analyses of the various operations needed to develop a design.

Figure 2.9: An example of a floorplan and symbols used for walls, doors and windows.

2.5.1.1 Floorplan Design System

The first phase was conceived as an intelligent floorplan layout system. The elements used to
define the floorplan were units such as wall, window, door, cabinet and stair (see Figure 2.9). The
plan elements were known as “blobs”, which were symbolic entities that were selected, specified
and located to compose a housing unit. The symbolic entities were kept very simple to reduce
display time. Each blob referred to a detailed data structure that more fully described it. Each blob
had associated unit geometry, materials and labor codes, joining codes and other information.

As the blobs were assembled, the spaces bounded by the arranged walls were identified so that
they could be later analyzed. Also, their junctions had to be indicated and assigned the appropriate
detailing. The SSHA floorplan system was one of the earliest building models that explicitly
modeled both the solid, constructed part of building and also building spaces.

The 2D data structure of the SSHA building model is shown in Figure 2.10. A wall component
carried material and other information. It is shown as a component bounded by surfaces that were
shared with rooms and wall-ends called "leaves" that abutted junctions. Both components and
rooms could be traversed to capture their geometry. This structure supported a number of
advanced operations. Because materials were associated with each building element, they could be
50 Part One: Context and History of Building Models

retrieved and displayed, along with the part of the room perimeter they described (see Figure
2.11). Each of the joint conditions defined in the plan could also be displayed. From the room
perimeter, the program automatically computed room areas and the enclosing surface areas for
each room. This procedure was useful in computing material areas and volumes. Based on the
glazing area on outside walls and its location, and on inside wall boundaries, the iso-contours
designating sunlight levels could be derived (see Figure 2.11).

Figure 2.10: An abstract representation of the SSHA building model.

The system also had the capabilities to evaluate beam and joist sizes and positions (see Figure
2.13) and to calculate heat transfer through exterior walls. It is assumed that these calculations
were all made by small analysis routines written especially for this system. No reference is made
to external or commercial applications that were interfaced.

Figure 2.11: Automatic Figure 2.12: Automated floor Figure 2.13: Generation of
computation of room joist sizing and layout. natural light contour levels.
perimeter.

The house unit design system was similar but predated by a decade or more the architectural
design add-on packages offered by CAD vendors and third parties. It relied on interaction with the
user through an early display monitor—initially a calligraphic display, later a storage tube display.
The system relied on simple menus consisting of keywords on the display screen. It took
advantage of the well-defined building unit codes already created and used by SSHA but was
Chapter Two: The Evolution of Computer Models of Buildings 51

developed to support standard on-site construction. It was quite successful in showing at an early
period the potential capabilities of CAD systems using two-dimensional geometry.

2.5.1.2 Site Planning System

The second stage of the SSHA Building Model was a site planning system for developing the site
layout and cost estimation for a housing estate. It defined the contour and ground plane conditions,
then assigned housing and garage units, roads, drainage lines, landscape areas, footpaths and
retaining walls to the site. These elements were each defined in any order, and their borders were
rectified into tight packing polygons afterward. The primary purpose of the system was not for
designing the site plan, but rather for entering an already designed plan and getting a quick,
detailed cost estimate for it. Editing operations were provided so that the specification could be
changed and cost updates computed. The site plan system included an early terrain model. It
supported topographic definition using either contours (given a Z-value, enter a string of X-Ys), or
elevations along a survey line (sequence of X-Y-Z). Both initial elevations and finished elevations
were entered, from which cut-and-fill volumes were derived. Elevation interpolation was
performed by software acquired from the University of Michigan.

Figure 2.14: Building unit end conditions involve various conjoint, subjoint and
overlapping conditions.
52 Part One: Context and History of Building Models

This CAD system prestored the house-type library and inserted it into the site. Each house unit
was located on a site by an origin, angle and elevation for each optional level. The house
definitions involved several complex issues. The system defined a house type by its perimeter, as a
sequence of vertices. However, house plans allowed for split levels so that each of the possible
split-level regions had to be defined separately. In addition, party walls were described, because
the detailing of party walls, particularly due to changes in elevation, were a significant cost item.
The party-wall condition was defined by accessing the two adjacent walls. The different cases are
shown in Figure 2.14. Party walls were also defined by an array of vertices, defining the vertical
perimeter of the wall. Also, sleeper foundation walls were also defined at split levels or as part of
the basic type definition, again as a line of vertices. Garages were defined similarly, but with only
one level and no sleepers.

Foundations were a significant cost item and the height of foundation walls and the merging of
shared foundations were significant considerations in later cost calculations. Simple estimates
were made of the bottom level of each foundation wall, where steps were located, and depended
upon whether the steps were vertical or sloped. Given the merged foundation walls, with top and
bottom elevations, routines estimated their cost.

Party walls were analyzed to determine if they were mutual, stepped or staggered. These
conditions identified whether the boundaries of the wall are inside, align or intersect each other
(see Figure 2.14). Thus their conditions correspond to special cases of the 2D polygon intersection
operations. Each condition required its own set of details. All sections of the perimeter were
analyzed and the appropriate detail with its associated unit cost was looked up and applied. The
areas of shared wall were also identified, and by subtraction so were the portions of party wall on
the exterior. Each type of wall had its own cost unit.

Roads and paths were entered by their centerline and width. Vertical alignments were computed
from the finished elevation and users could adjust these if desired. Road elevations were
interpolated and smoothed automatically. The result produced a new cut-and-fill volume. This
volume of added or subtracted soil was computed, using elevations at grid points. An example of a
layout is shown in Figure 2.15.

Figure 2.15: An example of a system-generated site plan, with buildings, roads and
contours. The original contour lines are shown as dotted.
Chapter Two: The Evolution of Computer Models of Buildings 53

Landscape areas, paved areas, ramps and outdoor steps were defined by a polygonal border and a
type classification. Fences, drainage lines and retaining walls were all defined by polylines and
associated attributes. All the polygonal areas were rectified so as to be consistent and provide
complete coverage. House and road areas were fixed and landscaping borders were adjusted to
them, and the remaining adjustments were averaged. The output of the program, after all the
entities were defined, was a bill of quantities and their material or detailing code. These were then
entered into a quantity survey program to derive a cost estimate.

The site plan system had to deal with many geometrical operations, such as set operations on
polygons, calculating the volume of cut-and-fill operations, and the entry of various geometrical
types. These operations were all defined and implemented by the project team. Today, libraries of
routines are available for most of these capabilities. The SSHA program is not very different from
current site planning applications now available, though the current systems have enhanced 3D
graphics. This program could display plans and sections, but not 3D images. Both the site
planning and housing programs incorporated significant amounts of knowledge about house
design and construction practices, about construction detailing, adjustment of roads and paths to
terrain, and foundation planning. They were pioneering projects, directed toward production use.
The system was used in production for a period of about ten years.

Later, the project leader, Aart Bijl, felt that the kind of task-oriented knowledge implemented in
routines in the two projects was severely limiting, both in its generality and in its conception of
architecture. The routines were fragile and could not deal with the variety of conditions often
encountered in different design contexts. He later undertook a different direction, developing
systems based on logic programming with semantic networks. Later, in a book reviewing all of his
efforts, Bijl presented a set of points regarding what would have to be addressed if intelligent
computer applications were going to support creative architectural design as we now know it.

• Many aspects of a design developed on paper are ambiguous and are open to multiple
interpretations. One reason for this is that most design problems are ill-defined and the
designer must decide which aspects of a problem should be keyed upon and which ignored.
Allowing these multiple interpretations is an essential aspect of architectural representations,
whether paper- or computer-based, because it allows human designers to develop new
interpretations of existing information, much like a scientist forms new hypotheses.
• The rationale for many design decisions is often tacit. That is, a creative designer does not
always make decisions based on well-defined and explicit knowledge; knowing why a design
decision was made may be akin to knowing why a soccer player made a specific move—it
probably just seemed the right thing to do. If the soccer player held back to rationalize a
decision, the context in which it was initially made may disappear.
• Design is an evolutionary process. The values embedded in a design evolve as the design is
studied, often through making trial designs. As the values change, the programmatic aspects
also evolve.

These points are directed toward the use of computers in the design phase of the building lifecycle.
They reflect upon various efforts to automate aspects of design. At the same time, they are general
truths that apply to many actions undertaken by people in response to real-world conditions and
requiring creativity.

2.5.2 OXSYS BY APPLIED RESEARCH OF CAMBRIDGE

Applied Research of Cambridge (ARC) was a commercial unit that grew out of the Centre for
Land Use and Built Form Studies (now called the Martin Centre), a research unit associated with
the School of Architecture at Cambridge University. ARC was formed in 1970 to commercialize
the research developments initiated within the Centre. An early research project taken on by ARC
54 Part One: Context and History of Building Models

was the development of a CAD system to support hospital design, using system building
techniques. The tool was to support hospital design based on OXSYS, a prefabricated building
system developed by the Oxford Regional Health Authority to facilitate the construction of
hospitals after the Labor government in the UK had nationalized the health care system.

Figure 2.16: Isometric of the Oxford method of hospital construction.

The Oxford Method was a post-and-beam and slab system of construction, based on a Tartan Grid.
A Tartan Grid is an orthogonal structural grid, with smaller grid lines on either side of the
structural grid. This grid is used for laying out walls and fittings on walls, or in section, for laying
out ceilings and finished floor elements. The construction system consisted of metal post and
beams, with concrete slabs and various types of external cladding. Mechanical elements, fittings
and most of the components of hospitals were predefined. An exploded isometric characterizing
the OXSYS system is shown in Figure 2.16.

The CAD system was first developed on the ICL Atlas mainframe computer at the Cambridge
CAD Centre, an Industrial Research Establishment initiated in the 1960s by the UK’s Department
of Trade and Industry to support advanced technology applications for industry. The overall
system was written in FORTRAN and heavily overlaid in memory. (This means that the program
swapped in and out various program segmentsa tactic used before virtual memory.) The
overlays were managed by OXSYS-O, the OXSYS operating system (later renamed BDS Overlay
System (BOS)). The overlays consisted of different application modules. An overall diagram of
the resulting environment is shown in Figure 2.17.

The OXSYS building system was based on a predefined set of building components. Thus all
building elements could be defined in a library, which ARC called a Codex. ARC updated and
extended the Codex as the OXSYS building system was refined. The Codex was extensive,
including structural elements, cladding components, partitions, slabs and ceiling elements, as well
as room types, interior fittings and fixtures, and mechanical equipment, all organized into families
and subfamilies. The Codex was not based on any standard, but was pragmatically organized
Chapter Two: The Evolution of Computer Models of Buildings 55

according to types within this building system. Early publications suggested that it could be cross-
linked to standard categories, such as the European Sfb standard (somewhat like the CSI standard
in the US). Publications indicated that there were Codex elements for assemblies, as well as for
parts, which could be used for schematic design. However, it is not clear if there were hierarchical
links from an assembly to its parts.
OXSYS 1-n OXSYS O BUILDING DATA
USER APPLICATION THE OPERATING
MECHANISMS SYSTEM
COMPONENT MASTER
DATA CODEX
BRIEFING & ROOM
DATA HANDLING

BUILDING FORM
DEFINITION

DIRECT COMPONENT PROJECT

BUILDING INPUT INPUT CODEX
SKETCH DESIGN
LATER DETAIL AUTOMATIC PROJECT
DESIGN COMPONENT FILE
SELECTION

AUTOMATIC
COMPONENT DESIGN
CONFIRMATION

THE BUILDING
BUILDING IMAGE
RESULTS PERFORMANCE
EVALUATION

OUTPUT OF PRODUCTION
DRAWING DOCUMENTATION
SCHEDULES & APPLICATION CORE CONTROL
OTHER TENDER
CODEX &
DOCUMENTS PROJECT FILE
HOUSKEEPING
LANGUAGE
FACILITIES
GRAPHICS

Figure 2.17: The system architecture of the OXSYS system, developed by Applied
Research of Cambridge, Ltd.

Each element was described in terms of its dimensions, descriptive text giving its name and
general use, weight, function-related properties, environmental characteristics and also the graphic
codes required to draw the element in different views. Geometrically, each element was defined by
its projections onto a 3D rectangular box. Up to twelve projections or views could be stored for
each component. Poor quality images of these graphic codes for three elements are shown in
Figure 2.18, taken from an early product description. Because the total Codex for OXSYS was so
large, a smaller version was required for definition of a particular building project, called the
Project Codex. It was similar in some ways to the symbol libraries and project symbols
(WBLOCKs and BLOCKs in AutoCad) found in most contemporary CAD systems.

Within the Project Codex, elements were classified into families, subfamilies and components.
They were spatially defined by an orthogonal bounding box specifying their X-Y-Z spatial extent,
and a list of allowed penetrations. Other information included adjacencies, material properties and
various performance characteristics such as maximum span or load. Whenever possible these
specifications were precomputed. Attributes, including the bounding box dimensions, could be
marked as either fixed or variable. Given a required level of performance, the components could
be automatically selected using the component selection routines in the system. Alternatively, they
could be selected and laid out manually.
56 Part One: Context and History of Building Models

FIGURE 2.18: The multiple geometric descriptions for three different objects used
in OXSYS.

Figure 2.19: Steelwork automatic selection based on column positions.

Chapter Two: The Evolution of Computer Models of Buildings 57

Figure 2.20: Automatic analysis of steel beams.

Figure 2.21: Automatic sizing of steelwork.

A project was the composition of individual components. It carried the spatial transformation and
parameters of each component in the layout. New components could be added at any time and
existing ones could have their location or parameters changed to suit different conditions. Some
components were variable in length. Upon placement, spatial conflicts were checked using the
box-level geometry. An "allowed penetrations" attribute was used to identify permissible conflicts.
Connections were checked with the adjacent elements in the Tartan Grid. A variety of applications
could then analyze a composition directly or extract data and reformat it to generate a drawing.
Figures 2.19, 2.20 and 2.21 show three structural applications: the first application was for
selection of elements, the second for analyzing shear and moments in a truss element, and a third
for automatic sizing. The applications interfaced to this model were custom developed and not
general-purpose ones.
58 Part One: Context and History of Building Models

Document generation was treated as a separate application. It retrieved the graphical data stored
with each part, locating and formatting it to generate plans and sections. Examples, including a
plan and two sections of a building layout, are shown in Figures 2.22, 2.23 and 2.24.

Figure 2.22: Plan showing layout of cladding partitions, fixtures and furniture
(Tartan grid is dotted).

Figure 2.23: Section through B-B in plan above showing roof and first floor
structure.

Figure 2.24: Section through A-A showing partial elevation and section.
Chapter Two: The Evolution of Computer Models of Buildings 59

In addition to an elaborate Codex for building parts, OXSYS included a well-defined structure for
representing building spaces, based on spatial sets. It was organized in hierarchies defined using
the relations shown in the left column of Figure 2.25. The examples show that for two spaces, any
subset may be defined using the spatial set operators. The structure was developed based on the
recognition that functional zones are not always consistent with other types of zones, like HVAC
zones. Thus multiple, spatial hierarchies were supported. Different zone hierarchies could be
defined, then reviewed and overlaid. The zones were entered by a user and the spaces were then
tabulated and compared against the building brief. An example is shown in the right column of
Figure 2.25. The building is partitioned with two different sets of zones. The resulting subzones
are shown in the fourth figure down. The ownership of the derived zones by the two higher level
ones are shown at the bottom.

A
BUILDING

X
A ∪B
Z ZONES CLASS
Y SVOLs

A ∩B P
ZONES CLASS
Q SVOLs

A∩B

A
E RESULTING
B
CVOLs
D
C
F

 ∩B
A
X Y Z P Q

A B C D E F

(A ∩B) ∪ (A ∩ B)

Figure 2.25: The union-intersection of space zones allowed classification of all

spaces.

An important thrust of the OXSYS CAD system was to address the combinations of details arising
in the assembly of Codex parts. It involved a fairly complex, rule-based system of checks for
whether particular assemblies were allowed (all coded in FORTRAN). The developers went
through a "knowledge elicitation" process, acquiring the rules that were implicitly part of the
building system from the OXSYS architects. The rule-coding process was difficult because the
Oxford System of building kept evolving, even to the extent that the size of the grid was changed.
As a result, the rules had to be constantly updated. In use, many rules appeared to be "fragile", in
that they reflected recommendations of the system's architects but did not apply in all cases.
Project architects who used the system often needed to work around different rules or make
additions or changes to the system. In retrospect, its developers felt that the OXSYS CAD system
was a means for enforcing the conventions of the system architects on the project architects. These
60 Part One: Context and History of Building Models

issues are still a concern today where expert systems are designed to enforce certain types of
design decisions.

The file management in the BOS system facilities addressed several important issues about data
security that still are not resolved in many current CAD systems. One feature was that as data was
changed during a session, the changes were written back to disk on duplicate copies, without
updating the original. Thus the initial state could be retained until an update was complete and the
user accepted the update. At this point, the original file segments were overwritten. The second
feature was that BOS maintained an interaction log of all user commands. In case of a crash or
hardware glitch, the previous operations could be re-executed, thereby ensuring that the work done
was secure.

The OXSYS CAD system was ported to Prime mini-computers and tested on several hospital
projects. The initial Prime implementation was restricted to 64K words of memory. Later, a larger
virtual memory version of the Prime operating system became available.

Associated with the project database was also a database defining the brief for the project, which
allowed allocations within the final design to be compared against targets included in the brief.
OXSYS also supported concept design, by allocating spaces corresponding to each of the spaces
specified in the brief in a certain configuration.

The system was marketed commercially beginning in 1978 under the name BDSfor Building
Design System. It was an early example of an object-based system that incorporated multiple
views of an entity, some being graphical and others not. The BDS system defined entities
abstractly, then generated views of them. This approach to design was later refined in the
commercial GDS system and in other British systems. GDS was originally conceived as a post-
editor for OXSYS-generated drawings, to deal with annotation and representational conventions
too tedious to do parametrically. It rapidly became apparent that it could do the whole drawing
production in a way more familiar to architects than through Codex creation. Many of the BDS
concepts and implementation strategies, especially at the system level, were incorporated into
GDS.

BDS was eventually withdrawn from the market when full 3D and solid modeling geometry began
to be integrated into production systems. However, it was a strong example of object-based
modeling and the development and integration of multiple applications. It included design rule
checking, implemented in a somewhat more general way than was realized in the SSHS work at
Edinburgh. It dealt explicitly with the issues of producing a full product specification for
construction. The OXSYS CAD system served as a model for at least one other commercially
marketed CAD system, initially called RUCAPS and later SONATA. SONATA included full 3D
modeling and other capabilities beyond those that were initially developed in BDS. There are
probably some people still running SONATA today. A similar object-based system is STAR
which is now marketed primarily in Europe. Apparently support for the last eight installed BDS
systems was withdrawn in 1986.

The OXSYS and BDS systems were based on a single, integrated model of a building that
supported all design tasks as well as an integrated suite of interdisciplinary applications. While
OXSYS and BDS did not support user-defined parts, some of their descendents did. In an
unpublished review of the work undertaken by ARC, Ed Hoskins, Director of ARC, made several
comments that are still relevant today:

• BDS was based upon the assumption that information technology could have a catalytic effect
on the design process, which in retrospect was somewhat naïve; an established practice will
not reorganize itself around a new, foreign and sometimes inflexible set of procedures.
Chapter Two: The Evolution of Computer Models of Buildings 61

• BDS's economies in production documentation were inadequate to justify significantly

increased resources to the design phase of building production.
• While the facilities provided in BDS were truly interdisciplinary, BDS did not adequately
support multiple concurrent operation.
• The predefined parts did not give the designer the freedom to work out new details that were
unanticipated in the original system.
• A building component-based model is inadequate if it cannot support the open-ended needs
arising from new, special details and from distinct or problematic site conditions.

2.5.3 GLIDE-II AND CAEADS

During the 1970s and early 1980, the CAD-Graphics Laboratory at Carnegie-Mellon University,
directed by the author, was active in the development of several early building models. The
Carnegie-Mellon group was not concerned with developing finished solutions, but rather with
developing a computing environment that would facilitate the easy implementation of integrated
systems for architectural design. The work of the group had two foci: (1) the development of solid
modeling for use in buildings, and (2) the integration of solid modeling with database and other
capabilities needed to generate an environment for advanced CAD system development.

In 1974, the group developed an early, solid modeling-based, building model with permanent file
store, called Building Description System (another BDS). In 1977, an expanded team developed
GLIDE (Graphical Language for Interactive Design), an interpretative language with built-in solid
modeling capabilities with permanent storage of global variables. GLIDE allowed users to define
new parametric primitives and attach attributes to them. Its operations included the spatial
transforms, spatial set operations and Euler operators required for defining new parametric shape
primitives. The language and permanent storage provided a simple database structure for defining
and storing building schemas with complex geometry. New schema structures could be added after
the database was loaded with values. Some fairly complex building models were defined. GLIDE
was implemented on a PDP-10 time-sharing computer and was written in BLISSa proprietary
Digital Equipment system development language. This work was funded by the National Science
Foundation.

The insights and capabilities of this earlier work led to funding by the US Army Corps of
Engineers to develop a portable engineering database system that could run on various hardware
systems. This was difficult, in that certain system facilities such as graphics were built up on a
particular machine configuration, and there were no standards for graphical interfaces and
databases at that time. However, a new system, called GLIDE-II, was designed and implemented,
defined as an interpretive programming language with permanence, with a backend file system for
storage. Within GLIDE-II, a building schema was defined that supported interfaces with a set of
applications, some specially defined and some generic, the latter having to be interfaced through
translators. The integrated system comprising the environment, applications and schema was
called CAEADS, for Computer Aided Engineering and Architectural Design System. CAEADS
included a predefined, general-purpose building model and interfaces to a set of applications,
developed in the 1980 timeframe. Below, GLIDE-II and CAEADS are both reviewed.

2.5.3.1 GLIDE-II
GLIDE-II was developed as a portable database language, written as a bootstrapped extension of
Pascal (portable meaning that it could be configured on multiple machines, in a semi-commercial
manner). Like its predecessor GLIDE, it was an interpretive programming language with
permanent storage of global variables. Syntactically, it was a superset of Pascal and built by
extending a P-code interpreter, the original way to easily implement Pascal. Language extensions
supported features needed for product modeling. Also, the language was implemented as an
62 Part One: Context and History of Building Models

interpreter, so that each global statement was executed as soon as it was completed. The
implementation was designed to run on Digital Equipment VAXes.

Figure 2.26: Two graphic images from GLIDE: A 3D building layout and a portion
of an automobile chassis.

In GLIDE, solid modeling capabilities were built into the language as primitives. In GLIDE-II
they were written in the GLIDE-II language and stored in a library that could be used or replaced
with another. This allowed the geometric modeling capabilities to be extended or modified. The
Euler operators for defining shape topology, various shape and surface definition and transform
operators were all written as procedure calls, then used to define high-level solid modeling
operations. This potentially allowed new surfaces to be added as abstract data types—as a data
structure and a set of operations for manipulating the new surface type. Some screen images of
geometric shapes generated in GLIDE are shown in Figure 2.26. In GLIDE-II, the Pascal Record
could represent a geometrical shape, an object, or complex relations. An object could be defined
without a predefined fixed shape or a set of attributes; these could be defined later by the user,
resulting in a custom object and shape. Alternatively, all of these could be predefined and only an
instance ID and transform need be entered by the user. Other variations also could be supported,
including instances defined by a few parametric values.

A project was partitioned into multiple separate name spaces, called Frames. Frames were similar
to directories in a file system, each being named and organized hierarchically. They held both
Records and operators and allowed structuring of code making up a building model in a
hierarchical database schema.

Legacy applications could be interfaced to the building model, but other operations could be
defined and added by application developers who supported end users. Developers could, for
example, define design tools to solve layout and specification problems. If a tool design did not fit
the current need, it could be revised. The use of a common environment supported the smooth
transition between normal use and system development. This smooth transition, where designers
and engineers start as users of high-level tools, but then have the opportunity to incrementally
redefine existing tools or develop new ones, was an important concept behind the development of
Chapter Two: The Evolution of Computer Models of Buildings 63

GLIDE and GLIDE-II. User interface capabilities were limited. All commands were entered
textually, with entity references given using an entity name, possibly with subscripts.

GLIDE-II's Frame and Record structure encouraged work in schema organization. It was
recognized that in construction, a single fixed schema was not practical. Many different
construction technologies could be used to solve the same problem (steel, concrete or wood). A
semi-hierarchical structure, into which detailed type definitions and operations are loaded from
stored libraries as one designs, was explored as a schema definition strategy. Thus a high-level
Frame for “structural system” could be defined early with general attributes regarding cost, for
example. Later, the detailed schema below the structural system could be loaded with different
entities and procedures corresponding to a specific type of structural system. The attributes of a
higher level Frame need not know what entities or procedures computed its aggregate properties.
The multiple hierarchies formed to support this type of performance and information aggregation
were called "abstraction hierarchies".

Frames offered no clear way to add new types of performance after the schema was initialized,
since doing so required adding new attributes to existing Frames and Records. Other language
extensions were needed to resolve this limitation. Frames did not support inheritance; they were
more like modules in Modula-2 (the unsuccessful successor language to Pascal). Instances of
Record types were created within a Frame.

A fundamental issue in programming languages is the notion of type. Type specifies what
operators may be applied to what objects or variables. Until to recently, an object or variable could
only be of a single type. Polymorphism is the computer language concept of an object or variable
having more than one type. If new attributes were added to an object, how could the computer
know which objects possessed the added attributes and which did not? A type of polymorphism
called type unions was developed in GLIDE-II so that existing entities could have new semantics
added to them. Thus a wall or other high-level data object could have new variables appended to
receive additional values. A set of appended variables could correspond to a class of
performance—for example, for a structural or acoustic class. Similar appendages could be
associated with other Records in the Frame tree, which would allow new, detailed properties to be
assigned, then aggregated up to the top-level Frame. The motivation for type unions was to allow
new performance properties to be added to a Record after it was created. This type of extensibility
involved three different levels of complexity:
1. unions of types, allowing a type to be defined as the union of other types
2. unions of types that apply to newly created instances (without values), so that all new
instances would have the newly added data fields
3. unions that extended an existing instance already loaded with values
Only the first two levels of capability were implemented. The needed capability in design
databases to add new data fields after an object is instanced is still missing from most commercial
systems today. The type union feature has close similarities to some forms of implementation of
object-oriented systems existing today (see Chapter Four for a more detailed discussion of
inheritance).

The GLIDE-II file system also supported design Alternatives. At any point in time, an Alternative
could be initiated that would redirect the results of all operations to a new file. Work then would
proceed, using the data in the new file as primary data, with earlier opened file(s) as the source for
entities not in the new file. Secondary Alternatives could be created from an earlier one, resulting
in a tree of Alternative files. An example of such a structure is shown in Figure 2.27. Object
searches within the GLIDE-II runtime environment were directed up the Alternative tree from the
current leaf node. The system would return the first object match encountered; thus an Alternative
could overwrite or append new objects or values to an existing model. A user could return to an
earlier branch and create other Alternatives, creating multiple branches in a parent-child relation.
64 Part One: Context and History of Building Models

Once a base design or Alternative had child Alternatives, e.g., branches, it could not be modified.
At any time, an Alternative could be merged into its parent, which then resulted in its siblings
being thrown away.

Base design

Alternative 1 Alternative 2

Alternative 1.1 Alternative 1.2

Figure 2.27: An example of an alternative tree in GLIDE-II. If Alternative 2 in

merged into the base design, Alternatives 1 and 1.1 are thrown away.

GLIDE-II allowed very flexible development of a building specification. But this flexibility came
at significant cost. While the original GLIDE could create an object in a fraction of a second,
GLIDE-II took several seconds. Some layout procedures would create hundreds of objects at a
time, resulting in performance that was not really interactive, but rather batch operation oriented.
Like GLIDE, GLIDE-II wrote directly to disk, without transaction management. Thus if an error
occurred, the project might become corrupted. Multiple copies of a project were used as a (crude)
recovery mechanism.

2.5.3.2 The CAEADS Building Schema

GLIDE-II was used as a platform for developing a significant building model for the Army Corps
of Engineers. It consisted of the Frame structure shown in Figure 2.28, consisting of five Frames.
It consisted of three Frames below the project level, for program, building and geometry. As can
be seen in the schema, geometry was not emphasized.

# (project)

program building geom

architectural

Figure 2.28: The simple Frame structure implemented for the CAEADS project.

The schema within the building Frame is shown in Figure 2.29. It consisted of a hierarchical
structure that decomposed a building into systems and components. Systems and parts were
defined at multiple levels of abstraction. Performance properties were aggregated upward from
parts to assemblies. Boxes correspond to Records with the non-geometric attributes or relations
they carry listed inside. Lines identify relations between Records.
Chapter Two: The Evolution of Computer Models of Buildings 65

Within the building lattice, the top-level Frame was thought to correspond to the project. It in-
cluded properties important to the overall project as project goals. These were aggregated cost,
area, number of units or rooms, and so forth. In addition, it held Boolean flags, each signifying
completion of a particular subsystem. These flags served as the top value for each subsystem hier-
archy. The top Frame also carried references to its component Frames and Records. At each lower
level, additional details were added. The structural hierarchy might be decomposed into aisles,
bays and foundation, then these into their subcomponents or, for mechanical systems, into sub-
systems and zones. There are, in fact, many ways to do such a decomposition. The resulting
structure was an early example of an abstraction hierarchy.

BUILDING
attributes
exterior
surfaces
stories
foundations

STORIES
floor(s)
ceiling(s) ZONES
vertical partitions zone
spaces type
successor story

MASTER SPACES
FLOOR/CEILINGS attributes
space type
floor/ceilings
bounding
vertical
surface

WALLS FLOOR/CEILING
attributes attributes
wall sections floor sections
surfaces surfaces
elements elements

WALL SECTIONS FLOOR SECTIONS SURFACES

attributes attributes attributes
materials
composition composition
elements

HOLES OVERHANG & VERTICAL

DOORS WINDOWS SHADING ELEMENTS
attributes
attributes attributes surrounding attributes
generic types generic types materials
walls
parts parts

GENERIC GENERIC WINDOWS WALL FLOOR STAIR SPACE ZONE

DOORS attributes COMPOSITIONS COMPOSITIONS attrib- TYPES
attributes
attributes glazing materials layer material layer material utes attributes

GLAZING MATERIALS LAYER MATERIALS SURFACE MATERIALS

material properties material properties material properties

Figure 2.29: Diagram of a building model schema developed within GLIDE-II, in-
corporating different levels of abstraction, used in the CAEADS project. Different
technologies could be plugged into the high-level functional requirements.
66 Part One: Context and History of Building Models

The main structure implemented was the spatial one. A building was decomposed into walls
(exterior and interior), floor/ceiling structures and spaces. The relations among these were those
needed to support updating and editing. Other hierarchies were used to organize information about
different functions, where a function corresponded usually to a building subsystem. Each
subsystem had a global definition, which, in order to be satisfied, was decomposed into a
hierarchy of subcomponents and analyzed. Managing these systems led to a series of applications
whose results were aggregated over subsystems, then systems, up to the overall project Frame. We
describe the various objects in some more detail below.

The building object was the root of the model. It defined a single space-enclosing structure. It
also provided the entry point and access path references to the rest of the design.

The story Record was used to represent stories as well as all floor-ceiling levels between
floor/ceiling constructions. A story was stored in a linked list, starting with an inclusive story
(the aggregation of all floor-ceilings on a story) and then linked together each floor-ceiling level
contained in that story. Each member in the linked lists had a back-pointer to the inclusive story of
which it is part. A story references all the walls and spaces that were part of it, i.e., were
bounded by that particular floor/ceiling combination.

Zone was a part of the building that was defined as one major spatial unit with a certain purpose.
It was usually the combination of a set of adjacent Spaces (see below). For example, a thermal
zone could be defined as a part of the building that is controlled by one thermostat. The
characteristics needed for describing a zone were specified by the zone type.

Space was the volume bounded by a closed loop of wall surfaces, the upper surface(s) of the
floor(s) and the lower surface(s) of the ceiling(s). A Space belonged to a story, is of a given
(programmatic) type and has a user-defined Activity.

Wall was a vertical partition within the building. Each wall lay on one straight line, defined on
the X-Z plane (horizontal plane). The body of the wall was bounded by two parallel surfaces, two
intersecting walls at each end and one or more floors and ceilings. The two endpoints, as
determined by the intersection of the wall's line and intersecting walls, were labeled 1 and 2 and
were used for determining the wall's direction. The direction was used to distinguish the right-
hand and the left-hand side of the wall. A wall could be ended with a line perpendicular to the line
on which it lies if an intersecting wall does not exist at that end. The right-hand or the left-hand
surface could be divided into segments not lying on a common straight line if the wall had more
than one wall section (such as resulting from application of a wainscot or tile on a part of the
wall).

The wall composition was defined as a set of wall sections (WallSection) and a list of
layers that reference materials in the architectural catalog. Each of the layers held the
elements enclosed within it and WallSection held the elements that were in all layers
(used in spatial conflict checking).

Floor/ceiling was any building partition that was not vertical. A floor/ceiling was a body
bounded by two surfaces, the lower one and the upper one, and a set of perimetrical surfaces,
which when combined formed a closed loop. The upper and lower surfaces could lie on planes not
perpendicular to the X-Z plane, and not necessarily parallel to one another, as long as the planes
did not intersect one another within the perimeter boundary. The perimetrical surface belonged
either to a wall (the common case) or is derived through an intersection between two
floor/ceilings.
Chapter Two: The Evolution of Computer Models of Buildings 67

Hole was a body composed of a space and its bounding walls. It extended vertically over several
levels and cut through at least one floor/ceiling, e.g., a stairwell. Element was an object that was
embedded within another object. In walls, for example, these could be windows and doors, or
piping and ductwork.

Material and material properties were all defined in libraries accessed separately.

WALL: a particular wall

composition

a construction section
preliminary within a wall
CWALSECT
design elements,
layers, section

another
component
element is in
ELEMENT
location, a generic entity
enclosure within a wall
WlSect: layer:
or floor/ceiling offsets, material,
material elements

design DOOR: WINDOW: Material:

development properties

Findoor Dgeneric Finwindow Dgeneric

detail
Side Door Side Window
design
Finishes Model Finishes Model

Figure 2.30: The GLIDE-II data structure for the wall model in CAEADS.

Each design specialty was assumed to have its own hierarchy (this one being the architectural
hierarchy), with a subset of the properties needed to manage the performance of concern. It was
the different functional areas that led to components being part of multiple hierarchies. While each
specialty could be treated as a hierarchy, all of them together required a partial ordering or semi-
lattice.

Walls could be defined at different levels of detail, depending upon the stage of development. A
wall’s structure is shown in more detail in Figure 2.30. Initially, they were defined as centerlines.
Their topological connectivity with other walls was defined, so that if one wall was moved, all
those attached to it would grow or shrink. Doors and windows and other elements were located
within the wall. The detailed wall definition was a solid model, which was parametrically defined
so that its shape changed in relation to the walls to which it was connected and to the location of
the floor and ceiling surfaces. Its construction was defined in layers, consisting of a structural core
material with finish layers defined on both sides.
68 Part One: Context and History of Building Models

USER

architectural structural civil electrical site plan

USER DIALOGUE subsys. subsys. subsys. subsys. subsys.
APPLICATIONS PROJECT
PROTOCOL SUBSYSTEM DEVELOPMENT MODULES PROGRAM INDEPENDENT
BLAST DATA
SEARCH
INTEGRATED BUILDING MODEL 1391 PROCESSOR
EDITSPEC
GENERAL SCHEMA MODEL DRAFTING SYSTEM
MODULE INTERFACE COSTS

GLIDE LANGUAGE
DATABASE FACILITIES APPLICATIONS
PROGRAMMING ENVIRONMENT LANGUAGE
GEOMETRIC MODELING
GRAPHICS INPUT/OUTPUT

OPERATING SYSTEM OPERATING SYSTEM OPERATING SYSTEM

workstation onsite processor remote network processor

Figure 2.31: The system architecture of CAEADS.

The CAEADS schema was defined as a collection of abstract data types. Thus operators were
defined in each Frame for the objects defined within it. A limited form of object inheritance was
utilized that did not include procedural inheritance. There was more focus on defining parametric
shapes and embedding complex relationships than determining a single fixed model.

CAEADS was a large system organized with several modules, as shown in Figure 2.31. The
General Schema Module and Integrated Building Model were implemented in the GLIDE-II
Language, the Applications Language. The schema supported various applications and this was
assumed to be an extensible set. The application modules were assumed to involve layout and
simple configuration testing, as well as interfaces to external applications. The University of
Michigan developed the habitability application and the interface to BLAST, a dynamic load,
energy analysis program. Of those shown, only the 1380 specification, the habitability application
and portions of BLAST were fully integrated. A CAD drafting system was purchased and
although the plan was to integrate it into the environment to support quick revisions, the
integration was never completed.

The overall user configuration was that shown in Figure 2.32. It was conceived so that several
users could access the building model in time-sharing mode (which today would be considered
client-server mode). They would first define the building model instance and then later extract
data from it as input to the various applications. Some applications would be executed centrally on
the model itself, while others would eventually run at remote sites. In practice, CAEADS had only
file locking as a means to control access, limiting access to a single user at a time.

Graphical interaction with GLIDE-II was through an Evans and Sutherland Picture System, an
early line of high performance, vector-based, real-time graphical hardware. While geometric
models could be developed on that system or on the VAX machine on which GLIDE-II ran,
proper communication between them was not fully operational.
Chapter Two: The Evolution of Computer Models of Buildings 69

DESIGN INDEPENDENT DATA:

DESIGN GUIDES, COST DATA

PROJECT INFORMATION SYSTEM

USER USER
USER USER
VIEW VIEW
1 3
GLIDE
INTEGRATED
BUILDING
MODEL
USER USER
USER USER
VIEW VIEW
2 4

DEVELOPMENT
PARTS
& DETAILING
INFORMATION
ROUTINES

Mapping Mapping Mapping Mapping Mapping

SEARCH BLAST
Habitability Thermal COST 1391
Evaluation Analysis Analysis Processor

Interactive
Drafting
System

Figure 2.32: A general diagram of the user architecture of the CAEADS system.

The funding for CAEADS ended in the Fall of 1981. Later GLIDE-II was made available in the
public domain and was picked up by several commercial firms. It was developed into at least one
commercial product (unrelated to buildings).

The GLIDE-II and CAEADS effort involved a significant amount of explicit systems-level
development. It was one of a few efforts to develop computer languages supporting design. Some
of the language features developed in GLIDE-II were later incorporated into object-oriented
databases. Because it specifically dealt with a programmable database model, CAEADS involved
an explicit building model schema that had some of the characteristics of current building models,
including a high-level core building representation, with extensible, construction technology-
dependent subschemas. The work on GLIDE-II development focused on the kinds of
language/database features needed to support building model extensibility, a continuing research
issue. GLIDE-II also was based on modern solid modeling geometry. Thus each shape was a
parametric solid, which could be resized during design by changing its attributes.

The sequence of efforts in developing software facilities for building modeling by the Carnegie-
Mellon team identified a number of open-ended research issues:
70 Part One: Context and History of Building Models

• One issue was how to develop appropriate transaction management methods allowing
concurrent access to and updating of a building model by multiple users.
• Another issue was how to specify and manage relations during design. While the meaning and
use of attributes to define the properties of building objects were reasonably well understood,
the definition of relations was not.
• Finally, a third issue was how to set up intermediate object abstractions for the designer's use.
Design works through a lattice of abstractions, moving incrementally to finer levels of detail.
At the bottom level are the physical components making up the design, which are well
understood. However, those at the intermediate stages are highly varied and reflect different
design strategies. For example, spaces may be defined before walls, then walls as centerlines,
then with a thickness. How should these different abstractions be organized?

2.6 SUMMARY OF THE MID-1980S

The projects reviewed in this chapter span a period from the late 1960s to the early 1980s. While
the hardware used in CAEADS was far superior to that used in the SSHA system, other aspects
moved at a slower, even negligible pace. All approaches represented a building as a set of
components with associated attributes—what is now called an object-based representation. The
initial building models integrated special-purpose applications, while later ones began to integrate
applications that were stand-alone. All were designed to address both design and construction-
level details. The schemas of the SSHA and OXSYS systems were mostly fixed for a particular
type of construction technology. The CAEADS system supported schema extensions during
design and thus was potentially more general, but it supported extensibility only in a particular
top-down order. All systems relied on single hierarchies of predefined objects, organized into
multiple levels of abstraction.

By the early 1980s, it was apparent that a building's description required multiple, overlapping
hierarchies, one for each method of analysis during the design phase. Also needed was a way for
users to define the various intermediate levels in the hierarchy—corresponding to intermediate
abstractions—as well as the bottom-level components. In architecture, different designers, or even
the same designer doing a different type of project, might use different abstraction hierarchies,
though in structures, acoustics or energy, the levels in the hierarchy were somewhat more regular.
All the systems here predefined the levels of abstraction, but this met with resistance from many
architects, who developed their own abstractions unique to their design process.

Another general issue was how to deal with side effects. Locating a window also created a
potential light source for a lighting program. Placing mechanical equipment in some location also
created structural loads. The functions that an object affects depend upon the behaviors being
considered. All these systems worked well if a fixed set of functions was built into the model.
However, extensibility called for more powerful procedures and was recognized by all three
research groups as an unsolved problem.

Each of these efforts developed a building model as part of a custom designed design
environment, with applications operating on the building model. At the time of their development,
there were few external design applications, and thus the need to integrate multiple external
applications was not heavily considered. The CAEADS project was the only one to interface with
standard applications. The interface, however, was one way, unidirectional from the model to the
applications. It was recognized that some applications create data that would be useful to other
applications, but managing the identity of application data, identifying which model instances
were modified, was an unsolved problem.
Chapter Two: The Evolution of Computer Models of Buildings 71

These three efforts were developed using very limited computational capabilities, in regard to
processing and display capabilities. CAD systems in the early 1970s were typically limited to 32K
words of memory with much less than one MIP speed. Displays could only deal with a few
thousand vectors per refresh (without filled polygons). And solid modelers and geometric
modeling capabilities had yet to be commercially developed. When viewed in this light, these
early capabilities were ambitious, providing examples that even today are not easily replicated.

2.7 THE CURRENT TRANSITIONAL STATE

The easiest way to utilize a new technology is to use it to replace existing manual tasks. The
framework and goals of the task are well understood and only the task methods need to be revised.
Both the marketing staff of CAD companies and the early users recognized CAD's potential in
production drafting and the systems evolved to better respond to this particular task.

From this rationale, based both in terms of how firms could effectively utilize this new tool and
how CAD companies could market them, initial, crude systems were refined to support electronic
drafting. The features needed to effectively support drafting emerged through market competition.
In other areas, electronic calculation of manual, analytic methods were replaced with
computerized ones in engineering. Rendering also was automated, first by computer-generated
perspective line drawing, then later by visualization programs supporting shaded color definition
and lighting simulation. In large offices, such tools could be selected for use by a department head
or project leader and were often purchased and paid for by a single project. Such adoption on a
task-by-task substitution basis allowed computers to be adapted without challenging basic
practices or the way people had been educated. It also allowed the effectiveness of computers and
the decision to use them to be assessed, at least roughly, against doing the same task in the
traditional, manual way. As a result, productivity has been a continuing justification for the
purchase of a CAD system.

Early automobiles were called “horseless carriages”. This mental concept implies that automobiles
were thought of as an augmentation of the existing carriages of the day. The revolution in
highways and transport came later. In the same way, computer-aided design and drafting (CADD)
is the horseless carriage equivalent of computers in building. Most of the traditional tasks involved
in manual design and engineering have been automated—drafting, 3D rendering, engineering
analyses—in horseless carriage style. In construction, the process of adaptation of computation is
not much different. Construction firms have automated their accounting systems, like all
businesses, and use electronic databases for cost estimating. Critical path scheduling and PERT
charts were used in project management before computers became available, but are now done
electronically. Other tools are available for earthwork planning, for managing storage and
preparation areas within the construction site, and for automatically defining and laying out
concrete formwork and defining the material list for the formwork. That is, packages now exist for
most of the tasks of construction management that were previously done manually.

Not all CAD efforts were directed at “horseless carriage” models of building design in the 1970s
and 1980s. A number of efforts attempted to redefine the process of design and, in some cases, of
building. The three systems reviewed here are examples of the more radical efforts. Many
judgments of the time considered these systems intellectually interesting, but too radical to be
accepted by current practice. Hoskins' comment about being naïve in believing that a new tool
could lead to radical new processes is instructive. Convincing a customer of a new tool's worth
also required teaching the potential customer a new way of designing and operating, something
that was often resisted and very expensive to the seller. Twenty-five years later this reality has not
changed.
72 Part One: Context and History of Building Models

Productivity assessment is based on a comparison of doing similar tasks, using different media and
technologies. Productivity is not an easily applied argument when significant changes are made in
the methods of production, because its effectiveness cannot be easily compared with previous
procedures. It can only be assessed at some large aggregate, such as a total project, after a long
learning curve.

Of the two paradigms of CAD presented at the beginning of this chapter, it is fair to say that the
dominant usage in the building industry is still based on using CAD as a graphics editor. The
primary representation for architecture, civil engineering and construction work associated with
buildings is a set of drawings. In the effort to support sophisticated users, most CADD systems
also support application development. However, appending these to a general-purpose CAD
system has proven a complex undertaking, with changes being required to the CAD system. Only
applications in some specific areas have been successful, such as piping, electrical and mechanical
systems. Almost all of the applications are integrated at the level of platform only. That is, while
graphics can be exchanged, attributes and relations among objects cannot be passed among
applications in different domains.

Now, in the late 1990s, with current markets becoming saturated and the price of a CAD system
dropping, major CAD companies in the building area are looking to advance the market to another
level. Efforts are being made to develop new platforms from the bottom up for application
development. These include the newest application development tools and libraries. A new
paradigm for building modeling is emerging, based on 3D and solid modeling, object-oriented
languages and databases, effective graphical user interfaces and Web-based communication. It is
also recognized that they must provide means to coordinate and exchange data between separately
developed vendor-produced applications.

While the application software part of these environments may vary, there are important reasons to
develop a public and sharable data description of the building.
• Users are likely to want to use applications developed by different software vendors. It is
unlikely, possibly undesirable, that any one CAD vendor should supply all building
applications. Thus, there is a need to have a common framework that can exchange data
across vendors.
• Building product suppliers, such as those providing information in Sweet's Catalog and
Architect's First Source, are ready to provide their product information in a format that can be
readily used to produce designs and support various forms of analyses. They need to have a
standard format to put this information in so it is accessible by all.
• With the downsizing of most design firms and the move to collaborative team design, there is
an increasing need to exchange design information electronically in an easy but reliable
manner. No such process exists today unless all members of the design team agree on a single
CAD system.

The challenge before us is

to develop an electronic representation of a building, in a form capable of supporting
all major activities throughout the building lifecycle.
This challenge is the focus of building modeling, and is justified by its support of more significant
changes in current practice. Its advocates claim that building modeling facilitates changes to the
process and conceptualization of how buildings are designed, how they are constructed and
operated. Visionaries in the field point out many new possibilities: electronic walk-throughs of
candidate designs; rapid development and simulation of a design's appearance and performance,
allowing refinement and possibly optimization during design development; planning and
simulation of construction while still in the design phase; development of computer-aided
Chapter Two: The Evolution of Computer Models of Buildings 73

manufacturing production methods of building components; and new methods of coordination of

work crews on the construction site.

Building models will only be realized when a significant professional community needs to use
information represented in a building model to design, construct or manage buildings—buildings
that are more complex, easier to construct, and more easily maintained than is possible with
current technology. That is, building modeling must prove its advantage in the marketplace. The
user community will have to move from current practices, based on a paper-generated information
trail, to electronic ones. This applies to architects, civil engineers, building product suppliers,
contractors, building regulation organizations, and building operators, among others.

It is quite possible that the development of a broad-based, sophisticated user community that can
perceive the advantages of building modeling could happen only after electronic drafting and
simple add-on applications have first introduced the techniques and practices of computers in
building. That is, the learning curve in building may entail incremental steps from current
practices to future ones. Even now, the challenge is not as much the goal itself as it is making the
incremental transition.

2.8 NOTES AND FURTHER READING

The major publication from Sutherland’s thesis was [Sutherland, 1963]. There have been very few
papers describing CAD system architectures. Two are Sedgewick [1974] and Eastman [1990].

The work of Coons was the first to focus on modeling an object, rather than a drawing of an
object. The original report was Coons [1967]. Coons’ patches are a restricted form of Hermite
surface that is no longer widely used in commercial CAD systems. For a review of Bezier’s work
and contribution to CAD, see Bezier [1993]. The volume incorporating the Bezier paper presents a
history of the basic concepts in computer-aided design.

The seminal papers on solid modeling are Baumgart [1974], [1975], and Braid [1973] and [1975].
Early formal work on solids was presented in Requicha [1980]. A survey of early work is
presented in Baer, Eastman and Henrion [1979]. The standard text for solid modeling is Mantyla
[1988]; a more general survey for surfaces and solids is Foley et al. [1991, Chap. 11].

The three different efforts in building modeling surveyed include much material never presented
in published form, though some were presented at conferences. The author has drawn upon these
documents and on technical reports and personal correspondence with the original researchers.

The Scottish Housing Council system developed by Aart Bijl's group is presented in internal
reports that may not be widely available [Bijl, Renshaw et al., 1971], [Bijl, Shawcross et al.,
1974]. A published report is by Bijl and Shawcross [1975]. An early review of this work is given
in Bijl [1979]. Bijl's later work, reflecting on these early efforts, is presented in Bijl [1989].

The BDS system developed by Applied Research of Cambridge is reported on in Hoskins [1973],
[1977], [1979a], [1979b]. This section benefited greatly from comments and internal papers
provided by Ed Hoskins and Paul Richens.

Three different building model environments were developed by the author's group at Carnegie-
Mellon University. The first, Building Description System (also BDS), is reported in Eastman and
Baer [1975] and Eastman, Lividini and Stoker [1975]. The second system, Graphical Language for
Interactive Design (GLIDE), was presented in Eastman and Henrion [1977] and Eastman [1978].
The third system, GLIDE-II, developed for the US Army Corps of Engineers, is presented in
74 Part One: Context and History of Building Models

Eastman [1980b]. Some of the system-level issues are reviewed in Eastman [1980a]. Treatment of
some complex relationships embedded in a model are given in Eastman [1981]. All three systems
are reviewed in Eastman [1993b]. This paper includes sample code written in GLIDE-II. Some
aspects of the CAEADS wall model are presented in Yasky [1980]. Detailed documentation of the
CAEADS model schema is in Yasky's Ph.D. thesis [1981]. The transaction management issues
growing out of the CAEADS effort, and a conceptual solution, were reported in Kutay and
Eastman [1983].

Other historical surveys are Mitchell [1977] and Galle’s annotated bibliography [1994]. Other
significant early efforts included the CEDAR [Thompson, Lera et al., 1979], [Thompson and
Webster, 1978] and HARNESS [Meager, 1973] hospital design efforts. The Karl Koch and Bolt,
Berenek and Newman system, supporting the Techcrete construction system, was reported in
Myer [1970]. Harold Borkin's group at the University of Michigan undertook important early
efforts, but few journal articles were ever produced. Two are Borkin et al. [1981] and Patricia
McIntosh's Ph.D. thesis [1982].

The line of development initiated in the 1970s and presented here has continued to the present
time. Some of these efforts include the KAAD modeler by the team of G. Carrera and G.
Novembri at the University of Rome, and Y. Kalay at the University of California, Berkeley
[1994]. It incorporates its own design applications and focuses on the representation of design
knowledge and goals. SEED (Software Environment for Early phases in Design) is a project at
Carnegie-Mellon University by Flemming et al. [1995] that also incorporates special applications
and focuses on new methodologies for the early design stages. Another knowledge-based modeler
that incorporates default knowledge and some knowledge of presentation formats is the CAD/CG
system by Watanbe [1994]. The ICADS system by Pohl and Myers [1994] incorporates multiple
actors, implemented as expert systems, that automatically apply their expertise in the development
of a design. Another knowledge-based system that incorporates heterogeneous applications but
provides a consistent user interface is KNODES, by Rutherford and Maver at University of
Strathclyde [1994]. The IBDS developed by Fenves and his colleagues at Carnegie-Mellon
University was another important example of integration, focusing on a suite of special
applications around a common representation [1994].

2.9 STUDY QUESTIONS

1. To better appreciate the historical evolution of CAD systems, one can look up old copies of
trade journals, such as Computer Graphics World or Cadence, and examine old articles and
advertisements, for example, in the 1975-85 timeframe. Select some now common
capabilities, such as integrated visualization, or development of an application language, or
attributes associated with a graphic entity, and try to plot a history of these features,
identifying when they first became available, how they spread to many CAD systems, and
how they evolved over time.

2. For a specific application area, such as energy analysis or construction of formwork, identify
the entities and attributes needed to describe the objects used in that application. Also,
identify some of the topological relations.

3. As a study of the history of computer-aided building design, take an early research or

commercial system and trace its evolution, in terms of the principal parties involved, the
special concepts it used, and the innovations it made. Systems that might be studied are the
CEDAR and Harness hospital systems in the UK, the commercial Techcrete system, and the
ARCH-Model program from the University of Michigan in the US, and the early commercial
architectural CAD systems, such as TriCad, Calma, and GDS.