In the 1950s and 1960s the apparent similarities between the adaptable abstract computing machine and the human mind led many to expect the rapid emergence of human-quality intelligence from computers. They were disappointed. Human brains and human thinking seem to be much more complicated than we thought, and the particular strengths of machine intelligence are perhaps of a different sort. While asking how designers think has not been immediately productive, asking what designers do has been. Focusing on observable information-processing behaviors—the creation, sharing, and modification of calculations, drawings, and other documents—has produced the current state-of-the-art in design practice.
In the shift from centralized mainframe systems to desktop productivity tools that accompanied the microcomputer revolution, interactive graphics became an important feature. Starting with the commercial success of the Apple Macintosh, the WIMP (windows icons menus and pointers) interface became the standard for both operating systems and programs. The availability of inexpensive graphic displays and input allowed drafting and rendering applications to develop. In the last two decades computers have advanced beyond the role of personal engineering and drafting platform to that of 2D and 3D visual arts platform, dramatically improving their utility and appeal across design fields. Network connectivity has made collaboration and data sharing both routine and efficient, while providing access to information worldwide. The combination has driven computing to the center of most design practices, though analysis and documentation remain an important part of workflow.
To understand the state-of-the-art, we must consider architectural applications in sketching, drawing production, building information modeling, automation, analysis, fabrication, and even operation—all aspects of buildings where design computing has had an impact. First, however, due to the centrality of geometry and form in modern design software, we need to review 2D and 3D software principles.
Architects aren’t the only designers who draw. Software vendors, seeking to spread the cost of developing the hundreds of thousands of lines of code and appeal to as many users as possible, have made their products as generic as possible. This has meant, until fairly recently, that architectural design tools could be shared with or repurposed from fields as diverse as movie animation, engineering, aircraft design, and jewelry design. In particular, the high-quality rendering needs of Hollywood animations and special effects have combined with the purchasing power and visual thirst of video-game players to revolutionize computer graphics. Sophisticated software and data structures for manipulating and rendering 3D objects have been developed, widely shared across the computer graphics industry, and turned into special-purpose graphics hardware which is now found in almost every modern desktop, laptop, tablet or smartphone, as well as dedicated game consoles.
There is more to a building than its geometry, more involved in creating, servicing, and using it than how it looks. The digital representation of a building is more complicated than shape, but as graphics has long been a key part of design it does provide a starting point. There are currently two broad strategies for recording, storing, and manipulating 2D computer graphics (vector and raster) and four for 3D (wireframe, surface, solid, and voxel). We’ll look at those in this chapter, returning in Chapter 8 to consideration of their architectural application.
The international standards for representing numbers and text are precise to the level of the bit. More complex data, including 2D and 3D graphics, often follows very standard conceptual conventions, but these do not extend to the level of precision we can find for elemental data types. As the emergence of ASCII as the dominant representation for text was aided by the market dominance of the personal computer, several other de facto standards have emerged in the area of graphics. These are built on top of simpler standards, becoming increasingly complex, and increasingly difficult to negotiate broadly, as they rise.
Imagine communicating a drawing to a colleague over the phone. Speaking “architect to architect,” you might say: “There is a brick-veneer stud wall on the north and east, with an 18-inch (500 mm) double-hung window centered 36 inches (1 m) away from the north wall. The 2-inch (50 mm) walnut inlay around the perimeter of the oak strip floor turns the corner inline with the southern edge of the window.” The communication is precise and clear, but contains lots of architectural jargon and lots of information about intent. This is a “high-level” architectural representation. It relies on knowledgeable architectural interpretation. This is the level of interaction that BIM programs aspire to.
Now, imagine communicating a drawing to a less knowledgeable worker over the phone. Speaking “architect to drafter,” you might say: “Using a double-line spacing of one-quarter-inch (10 mm), there is heavy double line 1 inch (25 mm) from the left edge of the paper. It meets another heavy double line 1 inch (25 mm) from the top. One and a half inches (40 mm) from the top is a short heavy horizontal line to the left. Two and a quarter inches (60 mm) from the top is another short heavy horizontal line to the left. Using a double-line spacing of 1/16 inch (2 mm), two and a quarter inches (60 mm) from the top edge, a thin horizontal line is drawn. It meets another light line drawn two and a quarter inches (60 mm) from the left edge.” (Such descriptions become quite long—this one has been abbreviated.) The communication is all about the graphics, free of architectural jargon. This is an object or vector graphics representation. It relies only on a precisely defined, if limited, drawing vocabulary and a coordinate system. Drawing or CAD programs are vector-based.
Finally, imagine communicating the drawing to a colleague over the phone, but rather than describing each of the graphical or architectural elements out of which the drawing is constructed you might just slip it into your fax machine and press send. The fax machine doesn’t know anything about architecture or drawings. It just scans the page using a grid of sample points. Each sample is either white or black. The fax machine scans the page left-to-right and top-to-bottom, generating a series of tones that communicate the sample values it detects. The second fax machine, miles away, prints dots on the page whenever it hears the black tone, and in almost no time at all … out pops a finished drawing. No disciplinary jargon is used. Drawings and text can both be sent. No explicitly architectural or graphical information is included, but the drawing is kind of rough or pixelated in appearance. Figure 5.1 illustrates this dichotomy for a simple circular shape.
The “fax” scenario describes paint or raster graphics; the name derives from the pattern of beam scanning in old cathode-ray-tube (CRT) televisions. The image consists of a grid of individual picture elements or pixels. The quality of the resulting image depends on the number of pixels in the image (resolution), as well as the number of colors each pixel can have (color depth or color resolution). Confusingly, the term “resolution” is often used to reference either pixels per inch (ppi) or the total number of pixels horizontally or vertically, leading to such odd sentences as: “A 3 inch by 5 inch (7 cm by 13 cm) image with a resolution of 150 ppi will have a resolution of 450 by 750 pixels.” Paint programs use raster graphics.
To store or display a raster image you must know the individual color values for each pixel of the image. That means a blank image has as much data in it as a complex one, and files may need to be quite large in order to capture detail. Reducing spatial resolution and reducing the amount of color information per pixel keeps the file size down. Mathematical treatment of the data may allow you to compress the file, saving space in storage and time in transmission. When you want it back you simply decompress it. Compression/decompression schemes are called codecs. If decompression gives back exactly what you started with it is a lossless codec (TIFF, PNG, etc.). If compression involves simplifying the file or removing detail that is not restored during decompression, it is a lossy codec (GIF, JPG).
For sketching and thinking it is important that the drawing tools do not intrude on the designer’s thinking. This is one of the features of pencil and paper that remains compelling. A paint program’s individually editable pixels, especially when combined with a touch-sensitive screen or tablet, go a long way towards recreating that simplicity. While the tactile drag of a soft pencil point over rag paper may be missing, software can visually simulate the behavior of a watercolor wash or the irregular marks produced on toothed paper.
Using a raster approach does have drawbacks beyond the feel of the pencil on the paper: You can only zoom in so much before the pixel nature of the image becomes obvious; editing is largely restricted to copying groups of pixels from one place to another; changing the line-weight or color of an existing line is painful; and the data does not lend itself to analysis tasks that need to know lengths, distances, or names. However, since the raster grid gives a color to every pixel and accounts for all parts of the image, color-coding can make computation of some information, e.g., rentable area on a shared office floor or the shaded area of a plaza, as easy as counting pixels of a particular color.
Pencil and paper can be used both for free-form sketching and careful drafting. When interactive drawing programs were developed, those using a vector- or object-based representation were generally more supportive of drafting tasks.
Returning to the hypothetical phone conversation with the drafter, if you ask them what they are doing with their tools you probably won’t be told that they’re recording ideas. You might be told that the lines represent cuts through walls or the edges of materials, but most likely you’ll be told that they are “drawing up” the design, working out the geometrical implications of design decisions in a precise way. Such drawings are constructed as miniatures, carefully scaled and abstracted representations of the real world. In the 1980s the American Institute of Architects (AIA) standard contract allocated 40 percent of fees to this task, which involves care, adherence to conventions, and frequent modifications, so it should not be a big surprise that the principals of firms were interested in efficient digital ways of carrying out this activity. This is the market that 2D drafting addresses—creating, editing, and managing carefully constructed line drawings.
Adopting and abstracting the drafter’s view of drawing (and the traditional tools of straight-edge, triangle, compass, and French-curve), CAD systems treat a drawing as a collection of marks of different sorts, including straight lines, circles, text, and so on. The different kinds of marks are called primitives, and each instance of a primitive is distinct, controlled by critical points stored as Cartesian (x,y) coordinates. As an improvement over manual drafting, these coordinates are usually created using real-world dimensions, which eliminates one source of errors during their creation (scaling is done during plotting).
If the user has a mouse or graphics tablet for input, it may be desirable to correct their imprecise human input through the software, ensuring that lines are exactly straight and perhaps horizontal or vertical. Sometimes it will be important that a new line meets up exactly with the end (or middle, etc.) of an existing line. Using the mouse’s coordinates it is possible to search the existing list of instances to find the nearest endpoint. Those coordinates can then be used as the endpoint of the new line, ensuring that they touch precisely and completing an endpoint snap, just one of many object snaps available in drafting software. Notice that the snap does not create a persistent relationship between the new endpoint and the existing line.
A drawing can thus be stored and edited as a list of lines, circles, arcs, and text, using real-world coordinates. Graphic attributes, such as color, line type (dashed, dotted, etc.) and line-weight (thin, wide), are associated with these lines.
There is also a layer associated with each drawing element. Layers are an important data-organizing attribute. The drafter can record, via the layer name, what a given line represents (interior wall, edge of roof above, steel structure, to be demolished, etc.), or what the material is (brick, concrete, etc.). By turning layers on and off, different plan drawings (existing, new, reflected-ceiling, framing, etc.) could be produced without duplication of drawing effort. Of course, significant energy went into defining and conventionalizing layer names so that data (and workers) could be exchanged between projects and consultants (NIBS 2014). To this day, large organizations such as government agencies and large manufacturers require work to be done using their particular layer-naming scheme.
A notable characteristic of many construction drawings is that identical groupings of primitives often appear in multiple places, windows in elevations, doors in plan, etc. CAD software allows the user to create collections of lines, often called blocks or symbols, give them names, and add or insert them repeatedly as needed to speed up drawing work. When the master copy of a symbol is edited, all instances are changed as well.
While the CAD data only indirectly represents a building, the existence of underlying coordinates means we can compute the real-world length of lines or areas of closed shapes. Using appropriate layer names we might indicate materiality (brick, wall board, etc.), making it possible to do material takeoffs. Symbols, which often represent manufactured items such as windows, sinks, or toilets, can be sorted by name and counted for furniture, door, and window schedules, in contrast to copy-and-paste line work. In short, and in contrast with raster representations, a vector drawing begins to represent the building in a computable fashion.
Vector graphics started out focused on the kinds of graphics that can be constructed by moving a pen around on a piece of paper, much as a draftsman would. They were called “vector graphics” because they were made of line segments or simple geometric primitives such as circles or arcs. Storing such drawings is simply done by making a list of the individual primitives, their attributes, and coordinates. The more complex the graphic, the longer the list is and the bigger the file. Primitives are added to the list as the user draws them. Symbol definitions might be included in the file or kept in a separate library. Attributes such as layer name and line weight can be interpreted during plotting as a pen change, or a line can be stroked twice with a little offset to make it fatter. Objects on layers that are marked as “off” can be skipped.
There were efforts to standardize this kind of representation. The SIGGRAPH and GKS metafile projects sought to standardize graphic imagery (Henderson and Mumford 1990), but these efforts were largely eclipsed by the overwhelming successes of PostScript for printing and the Autodesk Drawing Exchange Format (DXF) for architectural drawing data (Fallon 1998).
Because the early CAD systems were sold to multiple disciplines, each with a distinct vocabulary, they provided simple geometric primitives in order to serve a broad market. Building “walls,” if available at all, might be created by discipline-specific add-ons, extensions of the basic software that drew walls as two parallel lines with mitered corners and a T at junctions. While such extensions facilitated drafting, they were usually incomplete in some way—when you added a window you had to make a hole in the wall first, and when you moved the wall you had to remember to move the window too. That’s because they were not really walls or windows—they were just lines. The understanding of them as architectural objects happens outside the software, in our heads. Only in the last decade has software become widely used that truly understands walls in an architectural way.
Vector graphics can be enlarged or reduced without loss of information, but raster graphics become visually boxy if enlarged enough. If a raster graphic is scaled down to a lower resolution, detail is permanently lost and cannot be restored. Almost all modern displays and printers are raster in nature because of the speed and flexibility that this technology makes available. While architects use drawing in multiple ways, the computer graphics industry distinction between raster and vector graphics has become associated with the difference between sketching and drafting. Paint programs offer the unconstrained fluidity of sketching, while vector-based drafting software offers the precision and detail required for construction documents in a compact file format.
Two-dimensional vector, or “object,” graphics are usually employed to capture the precise kinds of data that are needed to create construction documents for buildings, landscapes, etc. This is why drafting systems have such complicated snaps and grids, and even sometimes require the numeric entry of data.
The world of three dimensions, on the other hand, is more often used during the early design process to assess and present the visual character of different design ideas and to answer questions such as “Can we see the garbage dumpster from the deck?”
Oddly, 3D representations are usually simpler than their 2D cousins, at least in terms of the number of primitives they support. They may not include text primitives and rarely include dimensioning tools. Instead, they focus on making it easy to create and view a 3D representation of the design via renderings of simulated views.
While they may use simpler data, three-dimensional systems are very different from their two-dimensional counterparts in that the 2D image you see on the screen changes dramatically as you manipulate the viewpoint, adding substantial complexity to use of the program. Where the display list data in a 2D system directly represents the drawing, the model data of a 3D system is only the raw material from which the screen image is made. In fact, you never see the 3D data, only 2D representations of it. The data is delivered to the screen through what is called a graphics pipeline, algorithms, and (often) hardware that convert 3D representations into 2D imagery.
Prompted by academic demonstrations in the early 1960s (Sutherland 1963), a few large architecture, engineering, and construction (AEC) companies developed their own 3D software (Fallon 1998), as did a number of universities, so that 3D software began to be generally available on mainframes in the 1970s. These programs were largely controlled by commands entered at a keyboard. Monochrome line drawings were the main product, either plotted in batch mode or displayed as static images on simple graphic terminals, requiring many seconds or minutes per frame to complete.
Two technological advances disrupted this situation in the 1980s. The first was the appearance of standalone color raster displays, enabling the display of multicolor shaded images as part of mainframe computing. The second was the introduction of microcomputers. While text-only at first, or limited to very crude graphics, it wasn’t long before color raster displays and microcomputers merged and the mainframes faded into memory.
As with 2D CAD, most 3D systems are editors and most models are simple lists of primitives, but with two differences: First, the implementation of general-purpose hidden-line and hidden-surface removal means that it is possible to produce traditional 2D plan, section, and elevation views from 3D models; and second, advances in 3D information modeling mean that models can begin to maintain the semantic content that designers recognize (“walls,” “windows,” etc.). Unfortunately, most hidden-surface processes produce raster images, limiting their utility for automated vector drawing extraction, and the remaining techniques don’t often render line-weights with the finesse expected in traditional practice. On the plus-side, color renderings and animations are now possible and 3D models can be used as the foundation for energy and lighting analysis, laying the foundation for the more sophisticated building data management systems (BIM).
There are four main categories of 3D data, illustrated in Figure 5.2. The first three can be thought of as extensions of vector graphics occupying the geometric domains of 1D lines, 2D surfaces, and 3D solids. The fourth fills the 3D niche corresponding to 2D raster data: volumetric elements, or voxels, in a 3D grid. A fifth form, point clouds, consisting of (sometimes colored) arbitrary points in 3D space is also emerging, driven by laser scanning technology.
If the data consists simply of lines in space it is called wireframe (a term which may also be used to refer to a “see-through” drawing and occasionally to any drawing done only with lines). Wireframe data is quite easy to create and maintain and can be converted easily from 2D data, such as that of a 2D drafting system, by just adding an extra coordinate or extruding lines from 2D into 3D. However, as the name implies, it is not possible to view the model as if it were solid since opaque surface data simply isn’t present. Nor is it possible to prepare shaded views of wireframe data. Once common, software limited to wireframe is now rare, though modern 3D software often uses wireframe rendering (rendering as if the data were wireframe) during editing because it is computationally fast. Most programs use surface (boundary representation) or solid data models.
Data consisting of two-dimensional surface elements or polygons, defined in a 3D coordinate system, is often called a surface, boundary representation (b-rep), polygon mesh, or polyhedral model. This is because, like a cardboard or paper model of a shape, it achieves its form by describing the surface faces or facets of the 3D shape. Because b-rep models contain explicit surface information, they may be used to produce renderings: hidden-line images and surface-shaded images. More complex renderings displaying surface reflectivity and texture can also be computed from b-rep models. For architects and other form-oriented designers, this is often as complex a system as is needed. The problem with this kind of data is that their geometries need not be real. For instance, it is perfectly legal to create a single polygon floating in space. Since polygons are (by definition) one-sided and have no thickness, they have no volume! It might look like a piece of paper, but a stack of them does not fill up a box! They may work for rendering, but you couldn’t manufacture (or 3D print) such a shape because it can’t exist in the real world.
A b-rep model can represent a very real-looking scene, but there are challenges. If you’ve visualized a b-rep model as a cardboard box, you are on target. Now imagine representing a hillside, face, car fender, or a teapot with that same cardboard. These irregular shapes are common in the world, but they do not reduce to abstract shapes such as spheres or cylinders any better than they reduce to planes. Two strategies have been developed to work with such shapes: rendering better and modeling better.
The rendering strategy works like this. Approximate irregular forms with flat polygons. This tessellation will cause them to be rendered with slightly different shades in the image, but since rendering is raster we can then work to smooth out the resulting color transition along the edge(s) joining adjacent faces. This approach, generally called shading or smoothing, has been around since the 1980s and is used extensively in the computer graphics industry; it is supported in graphics hardware on most PCs. These algorithms allow us to render even crudely faceted models so they look smooth most of the time, and are common features in video games and immersive online environments. They make the model look better in renderings, but if you 3D print it or mill it with a CNC router, the faceted nature or the geometry data will be apparent.
The modeling approach replaces the flat polygon faces with something better: non-uniform rational B-spline (NURBS) surfaces (Figure 5.3; Foley et al. 1990). In a NURB surface each polygon is treated as a patch or fragment of a larger surface. Each patch is divided into a grid of orthogonal curves, each of which is a composite of several polynomials. The infinity of the patch is tamed by a standardized mathematical representation and some unique parameters. The mathematics behind the representation enable a fairly small set of control points and related values to be used to compute the coordinates of any point on the surface to an arbitrary level of precision. This formulation assures that (a) edges align (no slits or gaps), (b) slopes match (no creases), and (c) curvature matches (human eyes are incredibly sensitive to light changes!). An appropriately low-resolution polygon mesh can be generated from the mathematical surface as needed and used with the smoothing algorithms mentioned above to deliver the right visual experience. In addition, the geometry can be used to 3D print or cut a shape that looks and feels correct.
There is no difference in the appearance of b-rep and solid models, so either can be used for rendering. Most of the difference lies in what you can do with the model. When the basic shapes that the system works with are 3D and the software is able to perform operations such as Booleans (e.g., union, difference, and split) on those shapes, the system is then said to be a solid modeling system. Surface or b-rep models aren’t quite enough. For example, six squares, glued together along their edges, make a cube-shaped box. It might look “solid” but if you run it through a band saw you’ll see the cavity inside. Run a cube of timber through the band saw and you have two solid parts, and no cavity. The cutting operation corresponds to the Boolean operation. To complete it, the system must know quite precisely what is inside the boundary shape and what is outside. Curiously, much the same information is needed to 3D print a shape.
The basic boundary representation can be extended to define solids. A b-rep that satisfies a relationship called Euler’s Formula is considered solid—also closed or watertight. Boolean operations, defined in terms of a set of elemental Euler operators, can be used to compute unions, differences, and intersections between two such objects, while assuring that the geometry remains that of a solid. Using NURBS as the surface elements, the geometry of projects from Peter Eisenman’s Holocaust Memorial in Berlin to Frank Gehry’s Guggenheim Museum in Bilbao, can be modeled, rendered, and potentially fabricated (at least in model form) reliably.
Solid modeling systems are commonly used in industries that actually manufacture objects from CAD data, such as the aerospace, automotive, and consumer-products industries, because the software can guarantee that the shapes it produces can exist in the real world.
One type of solid modeler, called a constructive solid geometry (CSG) modeler, goes a step further. Using geometric primitives that represent both the raw material (e.g., a block of aluminum) and the “negative” volumes of cutting, drilling, or milling operations, a CSG modeler tracks the history of edits applied to the initial form. This information can be used to completely define the part geometry, as well as the manufacturing steps needed to make it. In addition, the part’s mass properties (volume, weight, centroid, etc.) can be computed, and it can be virtually combined with other parts into functional assemblies such as an automobile engine whose operation can be simulated to test dynamic clearances, etc. As the description may suggest, it is not commonly used in architectural design.
The 3D equivalent of raster data is voxel data or point clouds. Until inexpensive laser-scanning systems began to appear in the AEC workflow, this data was largely restricted to diagnostic medical imaging. Think of them as (possibly colored) points in space. Voxel data will follow a grid pattern while point clouds simply provide points of color in space. Though there are no surfaces, with enough points you can render the scene from different points of view, and if you work at it you can identify and extract elements of geometry (pipes, surfaces, etc.).
While not common, such data is increasingly used in AEC workflows to establish as built conditions in projects such as refineries or buildings with complex mechanical systems, though it is difficult to reconstruct surfaces (or building elements) from the point data.
There are ongoing efforts to create robust and flexible standards for representing building models in academia as well as national and international standards-setting organizations, though none appear strong enough to be widely adopted yet. We’ll talk about these efforts further in Chapter 8, but for now let’s just get a sense of the problem by considering a couple of related issues: topology and geometry.
The visual aspects of a building, both interior and exterior, can be captured in a 3D surface model. Such a model may include visual textures for rendering, but is unlikely to have information about the material, structural or thermal properties of the assemblies it helps visualize or even their geometric details. This model is all about visual geometry and texture.
Architecture, on the other hand, is about space, not the objects in the space or the walls around it. What goes on in the space matters, so one common tool for attacking a design problem is a “bubble diagram,” as illustrated in Figure 5.4a. It identifies spaces and their relationships, but not their sizes or (necessarily) walls. The list of spaces and their connections establishes what mathematicians call a planar graph. Between the nodes (spaces), the connecting edges, representing connections, imply doors, and the doors imply walls. After squaring up the rooms and providing preliminary dimensions, the dual of the graph emerges as a preliminary floor plan in Figure 5.4b. This is non-manifold geometry. Like a literal soap-bubble cluster, it uses surfaces to divide the world into volumes or spaces. Moving a surface affects both adjacent volumes, so the representation is inherently spatial and topological. However, viewed as walls, the surfaces face both ways and often form T-junctions, two conditions that traditional solid models do not allow because it confuses the meaning of “inside” and “outside.”
The similarities and differences between 3D wireframe, boundary-representation, and solid models can be used to illustrate a general problem related to conversion between representations: There is often directionality to such conversions, with one direction being easy and the other hard. As shown in Figure 5.5, given only the 12 edges of a cube, there is no way to know if they represent a cube, or a box, a tube, or a wire sculpture. Even if all the wires of a wireframe cube are known to be polygon edges, there are ten possible b-reps that can be defined (six ‘boxes’, three ‘tubes’, and one ‘cube’). The correct interpretation is ambiguous, and only the closed volume of the cube, which satisfies the Euler equations, could be a solid, though it remains ambiguous whether it is a hollow cube (a boundary representation) or a true solid.
Going the other way, beginning with a representation such as “a unit cube, centered at the origin and aligned with the axes,” you can easily work out a boundary-representation listing the six faces and their corner coordinates. The boundary-representation, in turn, is easily turned into a wireframe representation by turning the edges of the faces into simple lines. At each stage we’ve used higher-order geometrical knowledge, but discarded some of it in performing the conversion. Wireframe, b-rep, and solid representations contain different amounts of topological and surface information in addition to the coordinates of the vertices. It is easy to discard information; once gone, assumptions or interpretation (guessing) are required to get it back.
The term graphics pipeline refers to a series of steps needed to convert 3D geometry data into a 2D screen image. While variations exist, and rendering algorithms such as ray-tracing take a very different approach, the pipeline is so standard that it has been implemented in hardware as part of the graphics subsystem of most computers. The complete pipeline, like an assembly line, is composed of several distinct data-processing stages, with data passing along the pipeline unaware of other data ahead or behind. Depending on the desired product, we might leave out steps or add steps to the process.
Just as a building doesn’t require a human presence to exist, 3D geometry data need not reference the human eye. However, to draw an image or rendering of a 3D scene, reference must be made to a human viewer or a camera. Most texts on the subject use the term “eye-space” to describe the world as seen from the camera, with the x-axis pointing off to the right, the y-axis pointing up to the sky, and the z-axis pointing into the scene.
To control the camera or eye, the program will provide a mechanism (called a viewing model) by which the user can adjust position. There are two basic ways to approach this: the environmental viewing model and the object viewing model. While they are equivalent, in that each may be used to specify any view possible in the other, the relative ease with which a given view is specified is very different.
In environmental viewing models the user positions the camera or eye point in the same geometrical world (i.e., in the same coordinate system) as the geometry itself. Thus, very precise questions may be asked, like “How much of that building will I see if I stand in the mayor’s office and look out the window?” As suggested, this is a fairly common model for architectural visualization.
Object viewing models behave as if the camera is fixed in space and the object (the model) is being manipulated in front of it—as if you held it in your hands. You bring it closer, turn it this way or that, and so on. You always look toward the center of the model but you never know exactly where you are relative to the geometry. This is a common model for engineering part design. It doesn’t work well if the point you want to look at isn’t near the center of the model (e.g., when generating a pedestrian’s view of the street in an area of high-rise buildings).
Not all parts of the model will be visible. The clipping process removes the parts that are outside of the view frustum—a pyramidal volume defined by the edges of the screen or window and the eye-point (Figure 5.6). Objects that are not within this volume are not rendered in the final image. Some software enables a “near/far” or “hither and yon” clipping constraint as well, with planes along the line of sight, effectively enabling perspective section views.
Rendering of the visible data begins with a process called projection. Using matrix multiplication, the 3D geometry data is flattened into 2D geometry image data. While many projections exist, most programs offer only perspective and parallel. You can think of the projection like the lens on a camera—when you point a camera at a scene the type of lens (zoom, wide angle, fish-eye) on the camera changes the character of the image on the film.
Clipping and projection are just the beginning of the process. If the program simply projected the vertexes of the model into the image plane and connected the dots it would create a wireframe graphic in which all lines are visible. To simulate opacity, programs include algorithms for hidden line or hidden surface removal to make the model look solid by obscuring or not drawing the hidden lines or edges. These algorithms determine which geometry in the model is responsible for particular pixels on the screen, after which they are carefully colored or shaded. Each of these algorithms makes trade-offs between computation time and image quality.
Once projection and hidden surface removal have occurred, the visible surfaces are rendered. This step depends in part on the hardware you are using (you can’t display color on a black-and-white screen). Surface color (a data attribute), light-source information (more data), and algorithmic shading models that describe how light interacts with the surfaces of the model all contribute to shading. Such algorithms are generally called flat or cosine shading algorithms. When models have been tessellated (like a hexagonal tube) and we want them to look smoothly curved (like a true cylinder), some form of smoothing, such as Gouraud (Newman and Sproull 1973) or Phong (Foley et al. 1990) is also used.
During shading the opportunity arises to define variable surface coloration or bumps. Texture mapping allows these surface characteristics, and others, to be applied to the geometry like wrapping paper or wallpaper.
Separate from shading is the casting of shadows. Shadows occur in those parts of the scene that you can see, but the sun or other light source cannot. One approach projects the model’s edges, as seen by the sun, through space to define shadow volumes. Another computes a view of the scene from the sun’s point of view and then projects that as a texture onto the elements of the model. For close-in views of large models or low-resolution shadow maps, the result is often distinctly jagged.
The various steps of the graphics pipeline algorithms have been turned into hardware on graphics processing units (GPUs), the hardware that drives rendering for video games, immersive worlds, and interactive 3D modeling programs.
More complicated rendering algorithms with names like ray casting, photon-mapping, and radiosity take into account how light bounces between surfaces within the model, but take longer to run. With moderately complex data they can take several minutes to render an image, even on a fast computer. They also make images that look so real that they are called photorealistic.
In an interesting convergence, rendering algorithms such as radiosity make realistic-looking images by employing what we know about the physics of light. In contrast to many renderings in which extra light sources and textures are added or shadows suppressed to adjust the appearance of the scene, such physically based renderings are not renderings so much as simulations of the scene. That is, the results are calculated to be correct, not just look nice.
This pursuit of rendering as reality simulation is deeply rooted in the computer graphics industry, but there is recognition that it has ignored rendering as emotional communication or visual exploration. There is room to investigate the communications and decision-support roles of images—still, animated, and immersive—in understanding and memory of virtual spaces, as well as the potential of non-photo-real (NPR) rendering to communicate or visualize other aspects of our environment (heat-loss, air-flow, occupant circulation, glare, etc.).
The major categories of software used routinely in the AEC industry include office automation, file sharing and project management, 2D and 3D sketching, 2D and 3D CAD, BIM, clash-detection, scheduling, and cost-estimating.
While not the differentiating use in the AEC marketplace, there is no question that tools for word processing, spreadsheets, file sharing and file management, operating on top of networks of high-performance personal computers (PCs) and file servers are part of almost every office. Businesses with multiple offices are often linked by networks and shared file systems. Increasingly, firms have added cloud-computing resources for computation-intensive activities, and outsourced selected tasks such as high-end animation or rendering.
Due to the potential costs of mistakes or delays in the construction process, the desire to document and control information flow and access between parties to the process has prompted development of formal systems of information distribution and archiving.
Sketching refers to casual 2D and 3D data constructs that are almost always seen as preliminary or temporary documents. Simplified interfaces enable some of these programs to be learned quite quickly, in contrast to the more complex drawing production systems which can take months to master. The broad availability of 3D graphics hardware in PCs means fairly simple models can be quickly generated and manipulated during site visits, client meetings, and design sessions, and used to produce simple textured and shaded renderings. Two-dimensional sketching, possibly on touch-displays, may include line-weight variation in the sketch, and copy-and-paste entourage elements, but may not extend to such document-centric features as dimensions, schedules, etc. While there are usually data-transfer paths by which models may be moved to drawing production systems, re-construction is often easier than import-and-repair, as imported sketch data is often not accurate enough to use going forward.
Two-dimensional CAD systems are ubiquitous in architectural practice. At the heart of CAD software is a vector-based drawing. Each drawing file can have only one editor at a time, each usually represents a single sheet or layer in the documents, and each is a simple list of primitives (lines, circles, text) whose visibility and appearance is governed by local or shared (layer) attributes. Invariant graphic elements (blocks or symbols) may be imported or defined and then placed repeatedly in the drawing, or saved as separate files.
Since they first appeared in the 1980s, these systems have grown very elaborate, with networks (including cloud storage) enabling sharing of passive (read-only background) data, and a combination of usage strategies and software features supporting complex drawing sets at varying scales, with a minimum of duplication. Dynamic parametric graphic elements such as other design documents, elements that change appearance at different scales, and elements that change appearance depending on the use case, are all becoming more common. Challenges regarding scale and size of graphic elements such as labels, dimensions, etc. have been addressed by differentiating between paper space (for plotting) and model space (for project data). Live-link inclusion features (reference or xref) facilitate change propagation by linking files together, helping to reduce replication, though the resulting tangle of interconnected files can make project management and milestone archiving a challenge.
While there are some offices that limit their use to 2D, most CAD software is actually 3D and capable of some degree of rendering beyond basic wireframe display. This means that 3D architectural CAD can be seen, largely, through the same lens as 2D CAD in terms of tools, structure, and trends. However, there are some differences, including the addition of sophisticated rendering functionality and the emergence of building information modeling (BIM, see next section).
Many disciplines use 3D data, including architecture, visual effects, animation, and engineering. Each of these requires slightly different features in their 3D modeling software, such as rendering, kinematics, motion-control, and digital fabrication. At this time, someone wishing to perform all of these tasks in a workflow would need either a collection of add-ons for their 3D modeler or several different tools, and it is likely they would have to build more than one shared model.
Thanks in large part to research done in support of the motion-picture industry, and the subsequent rise in expectations in general, powerful and accurate 3D rendering with realistic light-transport, surface models, textures, and synthetic camera controls is now available on PCs, though heavy use still requires multi-PC render-farms or cloud-computing resources to bring rendering times down from days to hours.
Around the year 2000 the concept of a “building model” began to catch hold. The concept originated as far back as the 1970s, but it depends on the use of a centralized data system such as that found on mainframe computers. When PC systems (which were not networked, had limited storage, and were not very fast) became popular in the 1980s for economic reasons, users were forced to accept the “each file is a drawing” paradigm as well. Now that PCs have multi-user operating systems, fast networking, and much more powerful hardware, the idea has re-emerged as BIM. In contrast to 2D CAD, in which the data represents conventional working drawings, and 3D modeling, in which the data represents only geometry and surface properties, a BIM represents a virtual building in 3D. The primitives are walls and windows, not lines and arcs or polygons. They have material properties in addition to geometry. Multiple users may edit the model at the same time. Walls can be rendered differently at different scales. Software extracts 2D drawings and schedules from the central model, assuring consistency within the construction document set by minimizing repeated representation of features that appear in more than one drawing. In addition to geometry, BIM data may include material or manufacturer information, analysis results, and links to related information such as operating manuals. This allows a BIM to serve as an information repository throughout the life of the building.
BIM is more demanding computationally than 2D or 3D CAD. Modern high-end PCs and networks can usually deliver the necessary communications and computation, but Martyn Day reports (Day 2011) that Autodesk had to use Navisworks software to do clash detection in the redesign of their Boston offices, because the BIM model was too large for Revit to handle the task on available hardware.
BIM is widely seen as critical to the effective future use of computing in the AEC market and is linked to the emergence of alternative practice forms, such as integrated project delivery (IPD), that attempt to enhance construction outcomes by sharing data and expertise more efficiently throughout the design and construction process. As a strategy, IPD aims to introduce appropriate expertise into project development at a time when the impact is greatest. It is often accomplished through sharing of a BIM dataset. As responsibility for creating the data and benefits from use of it shift between the different players in the process, it is likely that further change will occur (Scheer 2014).
Another force for adoption and further enhancement of BIM technology comes from large institutional and government owners, operators, and regulators of buildings, who have begun to perform more systematic cost and/or energy analysis of designs in their oversight roles, as part of which there is a clear trend to push or require use of BIM tools at some stages in the design process.
The move to BIM faces a number of challenges, including interoperability, intellectual property rights, incorporation of consultant expertise, mismatches of model granularity, representational range, change management, and phasing (use from sketching to construction and occupancy). We’ll come back to these subjects under the general headings of “Representation” and “Expertise” in the next part of the book.
Although document production via BIM or CAD is important in a practice, it is not the only area of digital tool use. Software for structural, energy, air-flow, and lighting analysis has grown very sophisticated in the last decade, with easier-to-use interfaces for less expert users, and with (somewhat) automatic conversion from standard 3D model and BIM file formats, while producing better-looking graphic results. Production of analysis results has gotten easier but, by and large, identification of the changes needed to improve the design remains the designer’s task.
The exception to this may reside in the rapidly evolving domain of scripting and the related field of parametric design, in which practitioners, researchers, and academics are using automated analysis tools to produce assessments and creating feedback loops linked to generative design strategies such as genetic algorithms and parametric optimization. We’ll talk about these in more depth in Chapter 12.
Construction is a collaborative activity; the work of many individuals needs to be coordinated in space and time to complete the project in a safe, economical fashion. Even before construction begins, the designers consult with specialists regarding aspects of the project. The representation created by the designer or design team will almost certainly become the central means of communicating design intent to other members of the team. The representation must fit the cultural frame, as well as the cognitive and information needs of the designer, the consultants, and the contractors.
Contractors make extensive use of software for tracking (and costing) material, scheduling material delivery and work crews, and detecting clashes or interference between building subsystems prior to construction.
While computer numerically controlled (CNC) machines have been around for several decades, they have until recently seen limited application in construction. One reason might be that the size of a fabrication tool is usually greater than the part being made, making buildings difficult to fabricate at full size. The aesthetics, analysis, and economics of the modernist box all favored use of identical repetitive elements. However, our computer systems and parametric design software now enable us to work quickly and reliably with unique sizes and dimensions rather than representative units, while digital manufacturing and scheduling systems have made it possible to manage the analysis, production and delivery of these many one-off design elements at modest premiums, making custom-cut steel sections and custom-fabricated façade elements almost commonplace in many situations where corporate branding or technical challenges warrant.
Building owners and operators need information about their buildings. In addition to knowing operational details such as which tenants pay for what offices or services, or who to call if there is a break-in or a leak, they may need to know what equipment is installed, how to operate it, who provided it, what maintenance operations are required, and when they were last performed. Over time, as building use changes, they are likely to need to know where conduit and plumbing is hidden in walls, which data ports are live, which electrical circuits serve what areas of the building from which panels, etc. They don’t need everything the designer or contractor needs, but they need a substantial part of it.
In the past this information would be provided in the form of an operating manual containing copies of the construction documents and all the equipment manuals. It was then up to the operator to maintain and update that information. Acquiring them in digital form seems ideal, as they can be extended with post-occupancy data, backed up regularly, and, on multi-building campuses, maintained by a central management team. A BIM may also be integrated into the building’s real-time building automation system (BAS).
Building operations rely increasingly on real-time systems for lighting, access-control and security, elevator operation, control of automated shading and irrigation systems, heating, ventilation, and air conditioning (HVAC) system operation, plus the more esoteric jobs of monitoring photovoltaic (PV) array output and managing gray-water recycling. Selection of these systems occurs during design, but owners are responsible for operating, maintaining, and possibly updating them. Commissioning of a building often includes handover of a BIM model corresponding to the as-built conditions, with digital versions of manuals, invoices, maintenance schedules, etc. While there is concern about maintaining such repositories over time (Johnson 2014), the information gives owners a strong foundation for implementing a BAS.
Increasingly, design of the building needs to include operational considerations and might involve selection or specification of particular building or equipment features and their integration into the BAS. Complex buildings may require complex management teams, but they also challenge designers to consider operation during design. As much of this will involve digital technologies, it fits within the umbrella of design computing.
Offices have built complete project workflows around 2D CAD using complex hierarchies of file-in-file referencing to minimize duplication while allowing information to appear at different scales and in different contexts. Some sketching (2D or 3D) is occurring, though such models may be re-constructed during production. Three-dimensional BIM is rapidly replacing 2D CAD for design development and construction documents, though it is often thought to be too cumbersome to use in schematic design and there remain issues regarding data interoperability when it comes to sharing design data with owners, contractors, and consultants. Increasing use is being made of all-digital file-to-factory fabrication workflows, including weatherproof modular off-site construction, though this is not yet widespread. Building owners such as the government and large corporations are pushing BIM in the belief that it will reduce costs and improve the product they receive and that it will make ongoing management more productive, though only the technologically more advanced building operators may see long-term benefits.
Fallon, Kristine. 1998. Early computer graphics developments in the architecture, engineering and construction industry. IEEE Annals of the History of Computing 20 (2): 20–29.
Foley, James, Andries van Dam, Steven Feiner, and John Hughes. 1990. Computer graphics principles and practice (2nd edn). Reading, MA: Addison-Wesley.
Scheer, David Ross. 2014. The death of drawing: Architecture in the age of simulation. New York, NY: Routledge.
Day, Martyn. 2011. The trouble with BIM. AECMagazine (October). http://aecmag.com/technology-mainmenu-35/450-the-trouble-with-bim.
Fallon, Kristine. 1998. Early computer graphics developments in the architecture, engineering and construction industry. IEEE Annals of the History of Computing 20 (2): 20–29.
Foley, James, Andries van Dam, Steven Feiner, and John Hughes. 1990. Computer graphics principles and practice (2nd edition). Reading, MA: Addison-Wesley.
Henderson, L. R. and A. M. Mumford. 1990. The computer graphics metafile. Borough Green: Butterworth.
Johnson, Brian R. 2014. One BIM to rule them all: Myth or future reality?, in Building information modeling: BIM in current and future practice. Edited by K. Kensek and D. Noble, 175–185. Hoboken, NJ: John Wiley & Sons.
Newman, William and Robert Sproull. 1973. Principles of interactive computer graphics. New York, NY: McGraw-Hill.
NIBS. 2014. United States National CAD Standard: V6. Washington, DC: National Institute of Building Sciences. www.nationalcadstandard.org/ncs6/history.php
Scheer, David Ross. 2014. The death of drawing: Architecture in the age of simulation. New York, NY: Routledge.
Sutherland, Ivan. 1963. SketchPad: A man–machine graphical communication system. AFIPS Conference Proceedings 23: 323–328.