48,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Geisteswissenschaft
- Serie: Disruptive AEC Technologies
- Sprache: Englisch
Learn to apply new digital design technologies at your own firm with this practical and insightful resource Digital Sketching: Computer-Aided Conceptual Design delivers a comprehensive and insightful examination of how architects and other design professionals can best use digital design technology to become better designers. Celebrated professional, professor, and author John Bacus provides readers with practical and timely information on emerging digital design technologies and their effect on professional practice. By focusing on the big picture, this rigorous survey of conceptual design technology offers professionals realistic strategies for reclaiming time for design in the ever increasing speed of project delivery. This book helps architects (and others like them) learn to use digital sketching techniques to be better designers, right from the project's very first sketch. As part of the groundbreaking Practical Revolutions series of books, Digital Sketching furthers the conversation of the practical deployment of emerging technologies in the building industries. This book provides readers with the information they need to evaluate digital design technology and decide whether or not to adopt and integrate it into their own processes. Readers will receive: * An accelerated and accessible introduction to a highly technical topic * Practical and applicable guidance on how to adapt a firm's business to adopt new technology without losing the benefit of existing intuition, skill, and experience * Real world implementations of specific techniques in the form of illuminating case studies that include results and lessons learned Perfect for professional architectural designers, Digital Sketching also belongs on the bookshelves of interior designers, landscape architects, urban planners, contractors, and specialty fabricators of every kind. A disciplined sketching practice, especially through the digital methods discussed in this book, is a transformational benefit to anyone who designs and builds for a living.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 550
Veröffentlichungsjahr: 2020
Ähnliche
Table of Contents
Cover
Title Page
Copyright
Prologue
At the Beginning of Every Sketch, There Is a Line
Notes
Chapter 1: Sketching for Conceptual Design
Introduction
Creative Rigor in Design
How Do You “Design”?
Design Starts in the Studio
How to Sketch
Sketching Digitally
Be the Designer
It (Really) Isn't about the Tools
Stay Agile
Version Control Systems
Notes
Chapter 2: The Elements of Design
Designing the Elephant
The Measurement of Space
The Qualities of Space
Geometry and Form
Freeform Curves
Surface
Building Objects and Other Higher-Order Primitives
Notes
Chapter 3: Representations of Space
Descriptive Geometry
Architectural Scale
Cutting Planes
Orthographic Projection
Plans
Elevations and Vertical Sections
Oblique Projection
Perspective Projection
Cinematic Perspective
Free Perspective
Stereoscopic Perspective
Unfolded Projections
Sketching in Diagrams
Notes
Chapter 4: Sketching in 2D
Your Sketchbook
Sketching with Purpose
Let's Get Sketching…
Physical Sketching
Materials for Physical Sketching
Carry a Sketchbook, Really
Tools for Digital Sketching
Physical and Digital Together
Notes
Chapter 5: Sketching in 3D
There Is No Hiding in Models
Benefits of Sketch Modeling
Physical Modeling
Digital Modeling
How 3D Modeling Actually Works
Sketching Lines in 3D
Sketching Surfaces in 3D
Sketching Forms in 3D
Assembling 3D Models from Parts
Notes
Chapter 6: Sketching in Code
Rules-Based Design
Materials for Digital Sketching
Getting Started with Programming
Notes
Chapter 7: From Sketch to Production
Sketching for Presentation
Sketching for BIM
BIM Levels of Development
Sketching in LoD 100 BIM
Sketching for Construction
Note
Chapter 8: Epilogue
Technology Is Incremental – Even Revolutionary Technology
Computation Is Powerful, But It Isn't Limitless
An Imaginary Scenario about Construction
How Close Is This Future in 2020?
Appendix A: What Computer Should I Buy?
Some Basic Assumptions
Get a Great Monitor
Get a Great Keyboard
Get a Great Pointing Device
Get Fast, Reliable Connection to the Internet
Get a Fast, Stable, and Reliable Computer
What I Use, FWIW, in 2020
Beware of Gadgets
Don't Throw GAS on the Fire (Gear Acquisition Syndrome)
Buy Things Without Cables Every Chance You Get
Note
Appendix B: Integrated Development Environments (IDEs) for Architects
Learning to Talk to a Computer
Visual Programming Languages
Note
Appendix C: Sketching in Virtual Reality
What Makes a VR Display “Immersive?”
Materials for Sketching in Virtual Reality
Using Your VR Sketches Outside Your VR Headset
Sketching in VR Will Be Pretty Great, Eventually
Bibliography
Index
End User License Agreement
List of Illustrations
Prologue
Figure 1: George Chaikin and his algorithm, drafted by hand: “Cutting corner...
Figure 2: Modeling in 3D with ArchiCAD.
Figure 3: Modeling in 3D with SketchUp.
Chapter 1
Figure 1.1: Sketching at my desk.
Figure 1.2: “If you don't know where to begin, begin anywhere.”
Figure 1.3: Sketching an ensō to check my status.
Figure 1.4: Letting it go.
Figure 1.5: Iterate, iterate, iterate.
Figure 1.6: Put. The pencil. Down. You're done. The charette is here for you...
Figure 1.7: Rule 30, an elementary 1D cellular automaton, evolving from a si...
Figure 1.8: My once-beloved NeXTCUBE computer.
Chapter 2
Figure 2.1: The parable of the blind men and the elephant (Hanabusa 1888).
Figure 2.2: 1D space.
Figure 2.3: 2D space.
Figure 2.4: 3D space.
Figure 2.5: Compensating for spherical distortion in road alignments; Driftw...
Figure 2.6: Steps in an animated rotation of a hypercube.
Figure 2.7: My own “states of mind” remembrance of the Forum Romanum.
Figure 2.8: Wet line (Sumi ink and brush), dry line (vine charcoal).
Figure 2.9: Red line, black lines.
Figure 2.10: Sketch of the desert, from Ghost Ranch in Abiquiú, New Mexico....
Figure 2.11: Glowing neon line, sketched digitally. By printing this image o...
Figure 2.12: A straight line (L) can be drawn between any two points (p1, p2...
Figure 2.13: A straight line segment (L) can be extended infinitely in a str...
Figure 2.14: A circle (C) can be drawn from any line segment (L) given one e...
Figure 2.15: All right angles (90°) are the same.
Figure 2.16: Euclid's fifth postulate, the “parallel postulate.”
Figure 2.17: Parallelism, as restated by Lobachevsy, Bolyai, and Gauss.
Figure 2.18: A single point.
Figure 2.19: A line.
Figure 2.20: Sketching lines by hand; after an image by Valerio Adami (Adami...
Figure 2.21: Rasterization on a low-resolution digital display.
Figure 2.22: An arc.
Figure 2.23: Drawing a circle by hand, the ensō; too much coffee today.
Figure 2.24: A circle drawn in 3D space.
Figure 2.25: A compass and straight-edge construction of the complex geometr...
Figure 2.26: Segmented arcs, at high-enough resolution, are indistinguishabl...
Figure 2.27: Hand drafting a perfect ellipse.
Figure 2.28: A sketch of a parabola in architecture; L'Oceanogr...
Figure 2.29: Hanging structural simulation of La Sagrada Familia. Gaudi's us...
Figure 2.30: Chaikin's algorithm, step one.
Figure 2.31: Chaikin's algorithm, step two.
Figure 2.32: Chaikin's algorithm, step three.
Figure 2.33: Chaikin's algorithm, step four.
Figure 2.34: Chaikin's algorithm, step five.
Figure 2.35: Bézier curve (de Casteljau's algorithm), step one.
Figure 2.36: Bézier curve (de Casteljau's algorithm), step two.
Figure 2.37: Bézier curve (de Casteljau's algorithm), step three.
Figure 2.38: Bézier curve (de Casteljau's algorithm), step four.
Figure 2.39: Bézier curve (de Casteljau's algorithm), step five.
Figure 2.40: A diversity of triangles.
Figure 2.41: Bézier surface, step one.
Figure 2.42: Bézier surface, step two.
Figure 2.43: Bézier surface, step three.
Figure 2.44: Bézier surface, step four.
Figure 2.45: Bézier surface, step five.
Figure 2.46: A plurality of architectonic forms.
Figure 2.47: The five Platonic solids, individually and nested together.
Figure 2.48: some common architectonic solids.
Figure 2.49: Architectural form from blocking and stacking.
Figure 2.50: Simple extrusions.
Figure 2.51: Revolved surfaces.
Figure 2.52: Joining cardboard pieces to make a house.
Figure 2.53: A computational surface model of the same house.
Figure 2.54: Removing a wall makes the space inside accessible.
Figure 2.55: SketchUp's winged-edge data model.
Figure 2.56: The “right-hand rule” in SketchUp defines the front and back si...
Figure 2.57: A collection of chair models, available for SketchUp on 3D Ware...
Figure 2.58: “Ceci n'est. pas une pipe.” With apolo...
Figure 2.59: A photograph of a real brick.
Figure 2.60: A brick sketched in context.
Figure 2.61: Generic model vs. specific model; which is the right level of a...
Figure 2.62: Trimble's 3D Warehouse.
Chapter 3
Figure 3.1: The size of a building vs. the size of a piece of paper.
Figure 3.2: Plato's allegory of the Cave.
Figure 3.3: Hand shadows, From “Le Magasin Pittoresque,” 1861 Le Magasin Pit...
Figure 3.4: Albrecht Dürer's shadow casting algorithm, as ...
Figure 3.5: An example of descriptive geometry used to rotate an object.
Figure 3.6: The technology of descriptive geometry: pencil, straight-edge, a...
Figure 3.7: Plan, elevation, and section compared; Palladio “Villa Rotunda.”...
Figure 3.8 Sketching at architectural scale.
Figure 3.9: Understanding the proportions.
Figure 3.10: A graphical scale reference.
Figure 3.11: How big is this cube?
Figure 3.12: Standard cutting planes.
Figure 3.13: Detailed sketch plan.
Figure 3.14: “Plan d'un sanctuaire ou d'une maison privé...
Figure 3.15: A pile of plan sketches.
Figure 3.16: A pile of sections and elevations sketches.
Figure 3.17: A curious vignette from “The Kanxi Emperor's Tour of the South....
Figure 3.18: Formalized axonometric projections.
Figure 3.19: Military projection.
Figure 3.20: Sketching vignettes in the emperor's arrival.
Figure 3.21: Detail sketched from “Theabid,” Fra Angelico.
Figure 3.22: Albrecht Dürer's explanation of perspective.
Figure 3.23: Tracing a photo in perspective, digitally, on an iPad in Procre...
Figure 3.24: One-point perspective, simple case.
Figure 3.25: Constructed perspective (two-point) compared to camera lens per...
Figure 3.26: A typical OpenGL perspective construction.
Figure 3.27: Frames from a walkthrough animation (Miles Davis Archive projec...
Figure 3.28: A typical 3D modeling viewport, free perspective.
Figure 3.29: A mechanical stereoscopic viewer.
Figure 3.30: A cross-eyed perspective projection, generated with SketchUp.
Figure 3.31: The first demonstrated augmented reality (AR) headset; from Iva...
Figure 3.32: An unfolded sketch.
Figure 3.33: Dürer's polyhedral unfolding technique.
Figure 3.34: From
De humani corporis fabrica
(Vesalius 1543). Suzan Oschmann...
Figure 3.35: An optimal diagram of the adjacencies in a house, digitally ass...
Figure 3.36: A path through space, folded by desired adjacency.
Figure 3.37: Variations on a theme.
Figure 3.38: A three-dimensional path through space, folded by the same desi...
Chapter 4
Figure 4.1: One of my old sketchbooks, a sketch from Piazza Navona in Rome....
Figure 4.2: A pile of sketches on tracing paper.
Figure 4.3: Drawing live from a model.
Figure 4.4: Some of my favorite drawing materials.
Figure 4.5: My iPad and Apple Pencil, ready for some digital sketching.
Figure 4.6: Tablet computers, compared in size to common drawing pads.
Chapter 5
Figure 5.1: Seymour Papert and Lego Mindstorms.
Figure 5.2: Froebel blocks.
Figure 5.3: Lathed forms from my shop.
Figure 5.4: Ivan Sutherland's “Sketchpad” application, running at MIT Lincol...
Figure 5.5: Modeling in 3D with SketchUp.
Figure 5.6: Modeling in a glove box.
Figure 5.7: SketchUp's line tool.
Figure 5.8: A model progression, from line to detailed AEC object.
Figure 5.9: How would you pick the table out of this model?
Figure 5.10: SketchUp's outliner.
Figure 5.11: Picking a point in free space.
Figure 5.12: Drawing precise lines in free 3D space.
Figure 5.13: Using SketchUp's inference system.
Figure 5.14: Modeling in SketchUp, one line at a time.
Figure 5.15: Surfaces in SketchUp are a product of their bounding lines.
Figure 5.16: Front face, back face.
Figure 5.17: A free-form surface, faceted for construction, at five differen...
Figure 5.18: A simple NURBS patch; simple extrusion.
Figure 5.19: A ruled surface, between two different curves.
Figure 5.20: A complex freeform surface, using Mathematica's “BSplineFunctio...
Figure 5.21: SketchUp's PushPull tool.
Figure 5.22: Pillowed reflections on water.
Figure 5.23: An ant modeled in SketchUp, using only basic modeling tools.
Figure 5.24: Closed cube, open cube.
Figure 5.25: Length, area, and volume calculations.
Figure 5.26: Some typical AEC-specific modeling objects, from ArchiCAD 23 fo...
Figure 5.27: Components in SketchUp.
Figure 5.28: A well-organized sketch model.
Figure 5.29: Kit-bashing in SketchUp.
Chapter 6
Figure 6.1: A Palladian Villa, in plan.
Figure 6.2: Mathematica's Notebook user interface.
Figure 6.3:
Hello World
.
Figure 6.4:
Hello World
, in 3D.
Figure 6.5: A simple line, in 3D.
Figure 6.6: A more carefully styled line in 3D.
Figure 6.7: A table containing four copies of a line, equally spaced.
Figure 6.8: Six random lines.
Figure 6.9: Six random lines, combined together in the same space.
Figure 6.10: A thousand random lines.
Figure 6.11: Experimenting with the
AnglePath[ ]
function.
Figure 6.12: A line drawn with
AnglePath[ ]
from the range of integer nu...
Figure 6.13: 100k steps, drawn with curves instead of straight lines.
Figure 6.14: Ten million steps.
Figure 6.15: Plotting a parabola.
Figure 6.16: Replacing ×2 with ×3.
Figure 6.17: A parabolic surface function.
Figure 6.18: Flipping the vault right-side-up.
Figure 6.19: Varying both
x
and
y
.
Figure 6.20: Trying for a dome…
Figure 6.21: Add a
Sine
function to make it a little curvier?
Figure 6.22: Trying to make it even curvier.
Figure 6.23: Trying a lower value.
Figure 6.24: Trying a range of variations.
Figure 6.25: Exporting a surface from Mathematica using the
Export[ ]
fu...
Figure 6.26: Mathematica surfaces, imported into SketchUp.
Figure 6.27: A basic
BSplineCurve
[ ].
Figure 6.28: A
BSplineSurface
[ ].
Figure 6.29: Exploring some random surface variations.
Figure 6.30: Ten variations on Rule 110 from random initial conditions.
Figure 6.31: Variations on a Rule 110, drawn as lines.
Figure 6.32: Progressively longer line drawing computations.
Chapter 7
Figure 7.1: A platypus.
Guide
Cover Page
Table of Contents
Begin Reading
Pages
ii
iii
iv
ix
x
xi
xii
xiii
xiv
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
223
224
225
226
227
228
229
230
231
232
233
234
235
237
238
239
240
241
242
243
PRACTICAL REVOLUTIONS: DISRUPTIVE TECHNOLOGIES AND THEIR APPLICATIONS TO BUILDING DESIGN AND CONSTRUCTION
Digital Sketching
COMPUTER-AIDED CONCEPTUAL DESIGN
John Bacus
Copyright © 2021 by John Wiley & Sons, Inc. All rights reserved
Published by John Wiley & Sons, Inc., Hoboken, New Jersey
Published simultaneously in Canada
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with the respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor the author shall be liable for damages arising herefrom.
For general information about our other products and services, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.
Library of Congress Cataloging-in-Publication Data:
Names: Bacus, John, 1969- author.
Title: Digital sketching : computer-aided conceptual design / John Bacus.
Description: Hoboken, New Jersey : Wiley, [2020] | Includes index.
Identifiers: LCCN 2020020368 (print) | LCCN 2020020369 (ebook) | ISBN 9781119640769 (paperback) | ISBN 9781119640806 (adobe pdf) | ISBN 9781119640790 (epub)
Subjects: LCSH: Architectural design—Data processing. | Architecture—Computer-aided design.
Classification: LCC NA2728 .B24 2020 (print) | LCC NA2728 (ebook) | DDC 720.28/40285—dc23
LC record available at https://lccn.loc.gov/2020020368
LC ebook record available at https://lccn.loc.gov/2020020369
Cover Design: Wiley Cover Image: John Bacus
PROLOGUE
It is a magical thing to start from nothing and bring something new into the world.
For some, the primal act of creation is a moment of self-doubt and fear. What if what you make isn't good? What if people don't like it? What if it causes you to lose face, or money, or to waste a bunch of time and energy on a useless folly? To people who think this way, the best strategy is to follow some pattern, some standard, or some best practice that worked out last time. Adopting a vetted standard reduces your personal responsibility if something goes wrong. And, anyhow, if there is a single right way to do it, why would anyone choose a different way?
If you picked up this book, I hope you are already thinking differently. Real acts of creation must acknowledge the norms and standards of practice as an important historical precedent. But they must also look beyond them to imagine something the world hasn't seen before. I am optimistic that the best designs for the future are those that question acknowledged norms, critique the ideology of their inception, and look past them to imagine something different. Design is a progressive act. You must believe that the future you propose is better than where the project started. Embrace that and treasure any opportunity to take part.
There are people in the world who know how to do design. As a society, we know how to train them, and we generally recognize that the work they do is uniquely valuable. They can put themselves into a unique mental state, fusing reflection and action into a laminar flow state, which takes input from the world and produces as output proposals for how things should change for the better. In architecture, the most effective designs are those that are buildable, that perform well against all objective design criteria, and yet at the same time that add a mysterious quality to the final product that cannot be rationalized easily but is evident to all. If you are one of the people who know how to do this, this book is for you.
Technologists like me tend to solve the problems we know how to settle before the harder challenges that we know might be more important. Since the 1960s, people like me have been building tools designed to remove the drudgery of professional design work. First, we made 2D CAD systems to help architects draft more efficiently. Then we built rendering engines to help architects present their work more beautifully. Most recently, we have been developing full building simulation tools (building information modeling, or BIM) that help to describe the proposed building to fully constructible levels of detail before the first shovelful of dirt is moved on the construction site. We have built tools to help estimate cost, to manage the flow of resources on a project, and to widen the bandwidth of communication between all members of the team.
There is visible, measurable, and repeatable value in all such tools. Likely, your firm is using some variations of all of them somewhere in your practice. You may well have trouble imagining doing your professional work without them. Can you imagine, for example, leaving your email behind for a return to the fax machine? This is not the full story, however.
It seems to me there is a harder problem that we have forgotten in our industry's heady rush of technological enthusiasm. Simply defined, it is the primary and essential work of architectural design. Your technological toolbox helps you to drive a design through production and construction with greater and greater efficiency. But all of that improvement is irrelevant if you haven't got a good design at the beginning.
Since 2002, I have been a member of the product management team responsible for the design and development of a digital sketching tool called “SketchUp,” which we designed to speak to the problems of designers (particularly architects) doing conceptual design. At its invention, few other tools existed to satisfy this need. That is still mostly true today. To this day, we have users who can't understand why we haven't developed more tools for CAD drafting, for rendering, or BIM. The answer is simple, often repeated, but widely misunderstood. We haven't built those tools because that isn't really what SketchUp is. It is for doing design, which is an inherently messy, abstract, and iterative process. SketchUp is where you do the design work that you will later document, render, and otherwise simulate to obsessive detail – design work that may, if you're lucky, translate through to construction. But the long journey to that result always starts with a simple sketch.
A sketch is often little more than a collection of lines and ideas, often captured on paper, that together suggests the future only in the most abstract way possible. A sketch captures the essence of an idea and exposes it for reflection.
At the Beginning of Every Sketch, There Is a Line
In 1974, shortly after graduating from the Cooper Union School of Architecture, George Chaikin invented a quietly elegant technique for drafting curved lines of remarkable complexity using only a compass and straight-edge. Chaikin’s algorithm, as it is now known, approximates smoothly curved lines by progressively cutting corners off a series of connected straight line segments. If more smoothness is needed, the draftsman simply knocks off another set of corners. And so on and so on until the curve looks smooth enough (Figure 1).
Figure 1: George Chaikin and his algorithm, drafted by hand: “Cutting corners always works.”
To someone who has drafted by hand, this algorithm is intuitively apparent. The explanation probably sounds a bit silly. However, it happens that this algorithm also makes it possible for computers to represent smooth curves. Mathematically, Chaikin's algorithm produces quadratic Bézier curves. In other words, Chaikin's algorithm creates the same kind of curves that Adobe Illustrator does.
I had the good fortune to study with George at Cooper Union when I was a student there in the early 1990s. George's computer class (the only one taught at the time in the School of Architecture) was unusual – perhaps more like a design studio than a programming class. I learned, based on things like George's curve drawing algorithm, that a pencil is a pretty powerful piece of design technology, and there are not many forms that you cannot precisely describe using one.
Of course, computers can draw 3D form on-screen many orders of magnitude faster than I can with a pencil on paper. Graphics pipelines running on specialized hardware can transform and draw 3D models to the screen at 30+ frames per second. With a pencil, my (personal) frame rate is probably less than one frame per minute for a straightforward model. Computers are always faster, and faster is always better. right? To members of the first fully digital generation, this probably sounds pretty obvious. But if all I want is a single 2D view of a 3D object, paper and pencil are probably about as fast as modeling the entire object and letting the computer draw that 2D composition for me.
The transformative moment for me, when drawing on a computer changed the way I thought about design, came when I wanted to have a look at what I was designing from some point of view that I didn't know I was going to want when I started. I picked up the model and spun it around. As I moved my point of view, I got a smooth transition. I could watch the model move by in front of my eyes. I didn't get lost. I could have a cinematic sort of experience as I zipped from place to place in the model, experiencing multiple points of view as quickly as I could move my mouse. The computer transformed the experience of space by merely drawing fast enough that I could see past the individual frames and fall into the immersive spatial experience we call “3D.”
In the late 1980s and early 1990s, right when I was completing my education as an architect, practices around the world were being sold computer-aided design systems that were affordable and (relatively) easy to learn. Architects were told that conversion from hand drafting to drawing on-screen would allow them to complete projects faster, and with considerable cost-efficiency. In the end, architects switched industry-wide to using CAD systems like AutoCAD. And the promise was fulfilled. Projects did become more comfortable to document, and changes did become easier to manage. The future, it seems, had brightened for the profession.
My first real professional experience with CAD was in Berlin, during the construction boom that followed Germany's reunification. Working together with young colleagues from around the world, I got my introduction to production drafting work. Working against a madcap weekly review schedule for Hochtief Construction, I helped document a million square meters of space for the Messe Berlin, working in the offices of O.M. Ungers, Walter A. Noebel, and (later, on other projects) Müller + Reimann, Architekten. We used a tool that was at the time the absolute apex of design technology, the “virtual building” simulation tool ArchiCAD,1 from Hungarian software developers Graphisoft, running on state-of-the-art Power Macintosh computers (Figure 2).
When I returned from Berlin to the United States, I took a job with Boulder, Colorado-based Communication Arts, Inc., where I worked for over six years as a designer on a wide range of large retail and other commercial projects. Still working on Macintosh computers, I traded ArchiCAD for FormZ2; traded the drudgery of construction documentation for the drudgery of rendering. But at Communication Arts, I had an opportunity to learn under some of our industry's most talented design communicators. I learned from guys like Mike Doyle (2006), whose book Color Drawing is now in its third printing – a bible for architectural rendering that is as relevant today as it ever has been.
Figure 2: Modeling in 3D with ArchiCAD.
From Communication Arts, I made a change. I knew that technology had an opportunity to change the way design work was done, but I wasn't satisfied that it was doing so in the right ways. Technologists usually automate the things they know how to automate, not always the things that are the most important to the users they are serving. The designers of those early AEC CAD systems rightly assumed that architects would know how to apply these new tools effectively and would protect the work they were doing that couldn't be automated. But I'm not sure this is exactly how it played out.
Technology, though automation of that which was judged to be manual drudgery, may have also reduced (inadvertently) the quality of design. Because if you can jump straight to the conclusion, to get a set of drawings produced that looks consistent and complete, then you can get paid quicker and move on to the next job. Admittedly, however, this isn't the fault of the tool. Magical buildings have been built that could only have been completed with computational help.
Leaving the traditional path to professional licensure and a full career in architecture at Communication Arts, I joined a snappy tech startup in Boulder with a dream that 3D modeling should be as easy as sketching by hand, and as powerful. Our company was called @Last Software, and in 2000, we released the first version of a product called SketchUp (Figure 3).
If the success of SketchUp has been any indication, the design tools of the future will not only work primarily in 3D, but they will be much simpler than what we're using today – simple like a pencil and paper is simple. As designers, we've got about all the “powerful” we need for a while.
If you're like me (and like most software users), you use less than 10 percent of the features available to you more than 90 percent of the time. The word processor I'm using to write this book has about a dozen buttons in the toolbar, of which I've used a total of three. I downloaded it for free from the web, and this book is the first time I have ever used it. This is an excellent tool for writing. Not particularly “powerful” from a feature perspective, but it does every single thing I need a word processor to do. Simple, complete, and powerful.
Simple tools are not just easier to use. They are also easier to share. When we released the first free version of SketchUp back in 2006, we found that both architects and their clients started building and editing 3D models together. Some architects were threatened by this, fearing that it undermined their design authority. But I think it led to much better design work all around. If your client has an idea about where the front window should go, allowing them to show you that idea in a 3D model is just so much more useful than listening to them try to describe it verbally. To be historically fair, clients also know how to use pencils to communicate their design ideas.
Figure 3: Modeling in 3D with SketchUp.
The great thing about sharing tools isn't really that projects move faster (although that tempts business-minded folks), but instead, that streamlined communication gives everyone more time to iterate. More time to think and to try things that don't work out. More time to improve the design and work the bugs out of it. More time to make the design a great design. The real democratization of design is happening right now, right under our noses.
The rising tide of information technology has brought some improvement to the construction industry. The now-ubiquitous tools for communication and collaboration afforded by the internet (email, the world wide web, search engines, and live videoconferencing) have forever changed the way we work. Designers are also learning that their design proposals can be fully simulated in the computer to constructible levels of detail before construction begins. BIM promises to encode into a designer's model not only the fully realized properties of a design but also a nongraphical encoding of every attribute, property, or even the chain of decisions that have gone into them throughout the lifecycle of the project.
But with this technology has come a breathless temptation to leap to constructibility too fast, glossing over the core design research and the traditional reflection-in-action that defines an architect's design process. As a profession, it has become all too easy to simply skip the careful thought and considered thesis/antithesis/synthesis that separates a competent design from a great one.
In this book, I will explore a category of design technologies that serve the needs of working designers in architecture. There are innumerable books available on the subject of BIM, and countless others focused on advanced architectural visualization (ArchViz). Neither of these popular categories attempts to cover quite what I'm interested in here, however. Simply put, I want to explore the myriad of ways that an architectural design process at the very earliest stages – from cocktail-napkin to a fully formed conceptual design proposal, can be supported by digital technology. I want to think through those first steps, from a blank page to a design concept.
This book is not a how-to guide that will teach you how to use any particular piece of software on the market today. Unavoidably, I will refer to critical components of technology that are contemporary to the time in which I'm writing. And I will inevitably talk about SketchUp – because that is my best answer as a technologist to the modern challenge of sketching in 3D for architecture. But, technology in general moves too fast for books, encoded in paper and ink, and subject to the lengthy timelines of a physical publication, to remain relevant for long. Where I need to go more in-depth on such topics, I've pulled that detail out to an appendix that can be updated more quickly in the future.
This book will explore the general principles of conceptual design in architecture and will propose a reframing of them in the context of modern digital technology. This book is for you if you have been confronted by monolithic software packages that cost more than your car payment every month but block your creative flow with every button click. Tools that are sold to you with fear tactics suggesting that if you don't buy them, learn them, and convert your work to their ways of thinking, you can't be an architect anymore. This book will help you learn how to use computers to expand your creative reach, to iterate faster, to learn more quickly, fail earlier, and be, in the end, a better designer.
Notes
1
ArchiCAD invented the idea of “virtual building” in 1984, over a decade before the first release of Revit popularized BIM.
2
I had many late nights and long days with FormZ, and I developed a genuine affection for it. In the mid-late 1990s, there was nothing more powerful on the market and it seemed like there wasn't anything I could model with it. It's still a great product today, especially for architects.
Chapter 1Sketching for Conceptual Design
Introduction
Good design is easy to recognize but difficult to describe. When it is missing, you immediately notice even if you can't say precisely why. Design has consistently defied all attempts at logical rationalization since before the Enlightenment, though, not for lack of trying by generations of design theorists. We observe in the world examples of effective design every day, but the rules and standards that led to that design's realization are notoriously tricky to decode.
Armed with a rigorous knowledge of building science that has been informed by thousands of years of historical precedent, architects can engage in a uniquely iterative process of design and reflection that produces constructible, functional, and at the same time, inspiring, and delightful buildings. The good ones can do it on demand, skillfully dropping themselves into a flow state where sketches pour out in a flood of work. Once in that state, they can reflect-in-action with consideration for hundreds of individual requirements, including unstated but inferred ones and all their various opportunistic affordances. By accommodating both objective reality and ethereal poetics, architects can bring a rigor of thought to any set of inputs, framing and reframing the original problem as necessary and iterating collaboratively until a path forward has been reached.
Creative Rigor in Design
The design work of a professional architect is rigorous, in-depth, and (to outsiders, anyway) more than a little mysterious. Building construction projects are notoriously complex, with little opportunity to rehearse solutions before committing fully to them in construction. Once construction has begun, the cost of making changes to the design can be astronomical. Every detail must be considered before construction begins.
Architects are trained to start sketching from very little concrete information, perhaps only a brief list of requirements, a site, and some local building codes and ordinances. The project may have exciting opportunities that are evident or at least implied by the available information, but it may also include unrealistic expectations and hidden, self-contradictory dependencies. It might be challenging to make many formal propositions about the building at first, but architects are trained to dive right in regardless. In time, through a process of sketching, reflection, and reframing of the problem, they know how to figure it out. As professionals, architects are great at just “winging it,” figuring out both the real issues (including unstated requirements that only later become evident) and their ideal solutions.
Some architects, particularly those who fancy themselves a bit closer to art than science, may actively resist any external attempt to rationalize their process. Design, to them, is a mystical art open only to those properly initiated. In truth, they may not really know how they do what they do, though few of them will readily admit this. But there's nothing to be afraid of if you are one of these kinds of designers. The magic of your work is not diminished because you can't rationalize it for others. Most designers, even the most rational of them, cannot describe how they do what they do or how they know what they know about the design. The intuitive leaps you make while working are not diminished because you can't entirely explain how you reached them. Your ability to make those leaps, correctly and effectively, is what defines you as a designer.
If they are honest with themselves, all designers have trouble describing how they reach the conclusions they reach while designing. They may talk about how individual decisions simply “feel” better than others, how one design direction is inherently better than another one because of where it leads the design next in its evolution. When pressed, they may be able to post-rationalize their past right decisions, even citing evidence and prior art to lend a sense of rigor to their overall design process. Skillful action almost seems defined by the fact that the professionals who engage in it know much more than they can say. And they can act based on more than they know, as well. This seems contradictory, irrational; perhaps even to the most rationally minded, it may seem irresponsible. If you can't say how you know something to be accurate, how can it be?
It happens as well outside of the design professions that the most skilled professionals, even among medical doctors, lawyers, and business managers, are actually at their best and most productive when they are working in ways they can least describe to others. A lawyer making an impassioned plea on behalf of a client in front of a jury, while certainly well prepared and rehearsed, may improvise new arguments on the spot as they watch the faces of their jurors. A trader on Wall Street may “feel the pull” of a barely visible market dynamic. Expert accountants can see through a wall of numbers in a spreadsheet and make accurate conclusions about the health of the organization it represents or the opportunities ahead of it in the market. Even baseball players “know” intuitively what they need to do to win a game … though they have no way to explain how they will pull it off. None of this makes any rational sense; we think of it as the “art” in their practice and (rightly) respect it deeply.
Since the Enlightenment, our culture has relentlessly applied the structures and norms of scientific, rational thought to all professional practice. “Ars sine Scientia nihil est.1” wrote Jean Mignot, fourteenth-century architect of the Milan Cathedral. Without a basis in some kind of rational theory, the practice of any art is without worth. That theory must be logical, consistent, and reducible to first principles that are universal enough to provide a common foundation beneath all similar work. In professional practice, trained architects should be able to apply the theory to real-world situations and come up with logically consistent design results.
Contemporary architectural theory isn't consistent in the same way that the underpinning theories in physics or philosophy are. Where the traditional work of architects could be rationalized, that rationalization has often led to the identification of a new profession that specialized in just that more rational act. For example, Structural Engineering. Or Construction Management. Perhaps even Interior Design, with its increased dependency on premanufactured lighting and furnishings, could be thought of in this way. In time, as more and more of the rationalizable components of the traditional matrix of responsibilities of an architect have migrated to new professions, only the mysterious, intangible design work of the architect has remained behind.
Once everything that can be rationalized and specialized has been accounted for by others, it is tempting to assume everything of merit has been covered. What a heartless and cold world we would build for ourselves if this were, in fact, the final solution. The sum of all rational processes in architecture will not give you a complete design, not even close. It is intuitively obvious to people when the spaces in which they are living their lives do not delight them, even if they can't say why or how. They, of course, also know if some obvious box wasn't checked in the design if the roof leaks, the garage has collapsed, or the driveway washed out in the last storm. But it is easy to tell when the poetic concerns haven't been met, too. Few people will care that the roof doesn't leak, because they won't care about the building at all.
The problems faced by architects may be different from those faced by doctors or lawyers. They may be more ambiguous and less consistent. Every building inevitably presents a different set of problems, a different set of requirements, and a different set of opportunities. There are undoubtedly universal principles that apply. The building must provide light and air to its occupants, must protect them from weather, and must support them against the pull of gravity, for example. But there is little guidance for architects seeking to add truly delightful, life-changing space into the world. It is tough to rationalize this part of the work.
How Do You “Design”?
So how is it done? How does great design happen? It is certainly wrong to assume that design practice can in no way be defined. Even the purest of abstract expressionist painters acknowledge there is significant science underpinning their practice. The physics of light, the chemistry of pigment, and the biology of seeing all have roles to play; without them, there could be no poetry. They also know how to get themselves into the mental space where the work can happen. Maybe it is about waking up early or maybe staying up late. Or perhaps it is about just the right music on the stereo. Somehow, it is repeatable for them. And no matter what you think of architectural designers as professionals, anyone who has been trained through an architectural education intuitively “gets” the processes and practices that lead to being able to accomplish a great design. Design thinking is reproducible and persistently observable in human behavior. There must be some way to describe it.
Architects speak of their work as being part of their “professional practice,” and I think we can find the answer we're looking for in that language. There are norms and standards that all architects must know – from building codes that you must meet to pass inspection before occupancy to the universal principles of gravitation that you must know so you design buildings that won't fall on their occupant's heads. Architects have to become the people who can answer questions about the building that nobody has thought to ask yet, and they must be able to do so consistently, decisively, and (even) defensibly. The best architects have fully internalized these and many more physical and philosophical truths. But to work exclusively within their mandates is to be blocked before you've even begun.
I think the practice we refer to when speaking about architectural work is more akin to the practice of a professional musician. Like an architect, a professional musician must know some physics, some historical precedent for their chosen music, and many other things. They must (probably) memorize the music they plan to perform – or at least internalize it enough that they don't need to waste time in performance reminding themselves what notes to play next. They must do all of these things in preparation for their performance, and they must reinforce them and drive them into instinctual behavior through relentless repetition. They “practice” endlessly, obsessively, repeating the same themes over and over again, testing variations, exploring newly discovered nuance and expression. They learn their subject so profoundly that they “become” it, physically embodying the music they will soon perform in public.
Malcolm Gladwell claims you need 10,000 hours of practice before you can be any good at something new (Gladwell 2008). I think most professional architects would say that they are just beginning to get warmed up by then. John Hejduk, who was dean of the Cooper Union School of Architecture when I studied in there in the early 1990s, taught that few architects were able to accomplish works of any real merit before their 50th birthday. There is just too much to learn, too many experiences to be earned in the field, and too few opportunities to try something genuinely new. The knowledge of a professional architect must be driven so deeply into their beings that it is instantly accessible, “… as easy as riding a bike.” And it takes time and experience to do that. It takes lots of practice.
A well-practiced architect knows a collection of artistic themes that have worked well for them in the past, and they can synthesize new interpretations of them that respond to differences in programmatic conditions in a profoundly intuitive manner. They are practiced at recognizing new opportunities in the design as they are uncovered and know well how to “listen” to the design while they are working when it starts to “talk back” to them. They know the basic universal theory, where it exists, so well as to be able to take intuitive leaps beyond it into new ideas, new territory for exploration.
In his work The Reflective Practitioner, (Schön 1983) described the work of architectural design as closer to jazz improvisation than to engineering. The architect is like one of a group of musicians who are working together to improvise new music based on a shared theme, a jazz standard. The musicians all know the tune and their own instrument deeply. They have confidence in their necessary skills that permits them to explore the space around the melody, responding to new interpretations from their fellow musicians as they appear. We love listening to jazz music precisely because of the tension between the standard and the musician's interpretations. Everyone in both the band and the audience probably knows the melody. There is a basic musical structure (play the tune together, take some individual solos, then play the song together again) that is also understood by all. The music is exciting because of its interpretation, the musician's exploration, and the unique expression in the moment of this particular performance.
A skilled jazz musician is unlikely to be able to describe precisely why a particular sequence of notes was chosen in their last solo. And it is equally unlikely that they planned their solo out much in advance of the performance. Upon reflection, after the performance, they might be able to name a few of the events that lead to their decision in the moment, perhaps something they heard from the preceding soloist, or maybe just a memory of something from farther back than that. If forced to fully post-rationalize, a logical and consistent story could emerge based on history, physics, and prior practice. But in the moment of the performance, none of this would be in the musician's mind. They would be too busy playing.
In a more rational problem-solving profession, a practitioner might consult standard practices or industry norms to model the problem, then optimize a set of variables until a fixed set of performance criteria are met. The basic requirements (e.g., “the building must not fall down”) can be modeled using real physical simulations and adjusted until the criteria have been objectively met. There is some room for interpretation, of course. You might choose steel over concrete for some complicated set of reasons. A unique soil condition might be discovered on-site during excavation that inspires a different solution for the foundation. Skilled engineers, well-practiced in their art, will know how to reflect-in-action just like a jazz musician.
Schön found in his research that all professions – even those most commonly assumed to be driven wholly by the most rational of scientific standards, have a component of intuitive, creative, design-like thinking in their practice. A doctor, for example, when confronted by a patient presenting symptoms for some illness, must intuit a diagnosis quickly and accurately. The majority of symptomatic conditions are unique, likely something the doctor has never herself quite seen before. In the moment, relying on years of practice to inform an intuitive response, she can respond with a plan of action. A life may depend on the accuracy and speed of response, so it has to be right.
Medical school prepares doctors by embedding in their minds an exhaustive collection of theoretical knowledge in biology, chemistry, anatomy, pharmacology, etc. Then, in grueling years of residency, they practice the application of that theory to real-world conditions under the guidance of a professional with many more years of experience than they have. Finally, they graduate into their professional practice, prepared for a career diagnosing and curing illness.
It is the “art” of medicine that is the most difficult to teach to medical students. Their primary knowledge may be profound, and their ability to recall scientific precedent may be without peer. But it is only through practice, in a professional setting on real patients with real problems and under the guidance of a doctor who has more experience than they do, that students learn how to do the work they do. The best doctors are those who know the science inside and out but can synthesize unique solutions for unique problems immediately, intuitively, and creatively. “Scientium sine Ars nihil est”2 may be an appropriately enduring counterpoint to the reforms of the Enlightenment that favor rational thought over intuition.
Architecture doesn't have anything approaching the body of scientific or philosophical theory that underpins medicine. Still, it does have an intellectual rigor of its own that blends art and science in a practice of design, which is both reproducible and trainable. Like doctors, skilled architects can make decisions for reasons that they cannot describe in the moment of their making. Unlike doctors, this ability is taught right from the beginning of their training. The education of an architect is distinct from that of other professionals in that it actively teaches both science and art right from the outset. A skilled architect is comfortable from an early age with the process of reflection-in-action that allows them to work pragmatically as both scientist and artist.
Design Starts in the Studio
The key to this training is in the studio environment, where students work side by side for long hours on poorly defined problems in design. In the studio, young designers learn to think with their hands, to draw by seeing, and how to apply a unique intellectual rigor in framing and reframing problems as unanticipated opportunities present themselves. In a range of contexts from the most intimate of desk critiques to the most public of project reviews, young architects learn how to practice their profession. All architects have this experience in common, and for all of them, it is life-changing.
From academic design studios, young designers graduate to professional practice, where the studio process begins again. Desk critiques with a professor are replaced by desk critiques with a partner, only this time with the added dimensions of time and money bearing down as well. It is easy to forget the theory and the art in professional practice, to double down on project delivery and efficiency, and to select out all the time spent on design exploration in favor of a faster deliverable. That is, after all, the most rational thing to do. It may not, however, be the best thing to do.
Most software is built to automate rationalized processes, based on an offset understanding of what is the most important thing a future user will want to do. Product managers in technology firms are trained to interview their customers and ask them pointedly about what it is they most find onerous about their work so that valuable tools can be built to assist them with those tasks. This works well for accounting packages, but it is difficult to create software that supports a process that the user cannot describe. Design thinking, particularly during its earliest, least definable sketching phases, is difficult to explain by even its most practiced professionals.
How to Sketch
“We see with the eyes, but we see with the brain as well. And seeing with the brain is often called imagination.”
—Oliver Sacks (2009)
What is the first thing you decided about your last project? And what was the thing you decided before that? And before that? What was the decision you made before all the other decisions that you made? (See Figure 1.1) Can you remember what it was?
The composer John Cage advised, “If you don't know where to begin, begin anywhere.”3 For architecture, everything starts with a sketch. It might be a sketch of an idea, a sketch of a proposal, or just a sketch to fill the emptiness and uncertainty. Nothing is more terrifying, more exciting, more filled with risk, and opportunity than a blank sheet of paper. In the beginning, anything is possible. Maybe, even everything is possible. If that moment isn't exhilarating, you might want to take up a different profession. For most creatives, this moment is pure, solid gold (Figure 1.2).
To be sure, no design ever starts from a completely blank piece of paper. Particularly in architecture, design always begins with a site and a set of other requirements and opportunities. Requirements are functional. They help to put some structure into that terrifying void; that is what your project looks like at the beginning. If you feel like your project has no constraints, you haven't looked closely enough. And if you absolutely can't find any, you're going to have to make some up on your own.
The moment you make the first mark on the project, whether a literal line on a piece of scrap paper or something else, it will be wrong. If it doesn't seem that way to you, you're probably deluding yourself about something. Maybe about a lot of things. Usually, the first idea you capture is the one that's been standing in the way of all the better ideas still to come. The best thing to do is to purge it out of your mind quickly. Clear the road and get ready to move on.
Your first sketch on a project might be a physical sketch (to be sure, I recommend that), or it might be a formula in a spreadsheet. Maybe it is a great conversation over coffee with your client. Or it might be a haiku. Or an interpretive dance. Whatever gets your blood moving conceptually, whatever purges the bullshit that was occupying your attention before you got started on this new thing. Keep it simple. Move fast (Figure 1.3). There's better stuff ahead.
Figure 1.1: Sketching at my desk.
Figure 1.2: “If you don't know where to begin, begin anywhere.”
Figure 1.3: Sketching an ensō to check my status.
If you are relatively inexperienced with your creativity, you are almost sure to hang on too tightly to your first sketch. Because it is hard to make things, it is hard to be creative. You're exposing yourself to critique the minute you pick up your pencil. What if the idea is terrible? What if the concept is OK, but the drawing doesn't communicate well? Or maybe the sketch looks like it is saying something completely different than what you meant it to say. What if your client looks at the sketch and sees that you didn't know what you were doing this whole time and you're nothing but an imposter4?
Experienced creatives know this moment well, and they recognize it for what it is. It is just something to be acknowledged and moved beyond quickly. Take that first sketch and throw it away. Crumple it up, toss it on the floor. Set it on fire, maybe. Poof, it is gone. Mourn its passing quickly and move on (Figure 1.4).
Figure 1.4: Letting it go.
Now, make another sketch. And another. And another. Throw most of your work away – that helps you move past initial ideas and get faster to the good stuff. Keep your inner critic behind you as much as you can. Every sketch you make is going to be better than the last one was, but you're going to want to learn from the mistakes you've made. Every sketch has a purpose, even if it is only to prove to you that it represented a dumb idea (Figure 1.5).
Figure 1.5: Iterate, iterate, iterate.
Be prepared for unexpected consequences and happy accidents. They can come from anywhere, at any time. It is your job to see them when they appear and to understand what they might mean to the project. The simple truth that ideas sometimes come from unexpected places is singularly frustrating to less-creative people. If the breakthrough approach for a project came from somewhere other than the designer's mind, why do we need the designer? Let's just save that money for something else, right?
