223 Two and a half dimensional objects and pseudo-spaces
220 The Form of Ink
277 Chapter 5 Futures
279 Still on Paper, Still Difficult, Slower, Longer
280 Craft
281 Drawing Discipline
282 Making and Re-making Technology
287 Appendix
289 Index
Preface
Computing and drawing have intertwined histories. The first computer art was drawn. Limits on processing power and memory storage precluded pixels and images. Instead, computers were programmed to control machines that moved pens to make marks on paper.1 Soon thereafter, the trajectories of computing and drawing diverged. The aim of this book, and the work within it, is to explore the implications of bringing them back together. Besides what computing and drawing mean, this book will explore what computing and drawing can collectively do. In most cases, merging computing and drawing involves merging cultures and methods. The territory within which we compute and the territory within which we draw are—with a few exciting exceptions—largely distinct. For these reasons, deciding to “make a drawing with a computer” or “compute in the space of the drawing” are no simple tasks. But they are exciting, productive, and creative.
I did not intend to set out on this line of inquiry. In January 2010 I was researching the role of computational media in the design process. My focus was animation, and I was seeking computational methods that might inform architecture by way of provoking animation to perform in ways other than the simulation or the diagram. I was programming using the Python programming language and animating the formation of path lines. In an online repository for drawing libraries in Python I stumbled upon Chiplotle,2 a library for controlling HPGL-era pen plotters that were salvageable thanks to the open nature of the HPGL protocol and some other libraries that
allowed serial-port communication via USB adapter. It looked interesting, and because we were between semesters I had the luxury of a tangent. I checked Craigslist and there happened to be one large format pen plotter for sale about ten miles from my apartment for $50—including pens and even some vintage paper. I would learn later that this was an extremely lucky and rare find. But at the time I thought, why not test it out? I remarked to a colleague that I’d give the pen plotter two weekends before moving back to my “serious” research. The first weekend went well. The Chiplotle developers were right, bleeding ink is incredibly seductive. The machines, beautifully engineered, were not exactly easy to use, but every challenge was an opportunity. Eight years have passed and nearly all my work relates to these drawing machines in some way.
This is not a textbook, nor is this a portfolio. However, like many in academia, my teaching and practice convolve. To some extent I bring my own interests to teaching, but much more significantly, my teaching influences my practice. As I mention later in the book, computer programming is like teaching to a computer. Moreover, teaching is ingrained in how I think about making. As a result, without even trying I often create pedagogical threads through my professional art practice. Though writing about my work is difficult for me, writing prompts or exercises that run parallel to it seems natural. I’ve developed and experimented with many different methods for artists, designers, and architects learning to code. I think everyone should code, at least a little, and I know everyone can do it. However, the best way to learn in any creative field, no matter what type of learner one is, involves a messy integration with an existing creative practice. In that spirit, the exercises that make up the core of this book do not form a “learn to code” course. Rather, in concert with other technical resources, they will guide the reader on a path that keeps the technical aspect of coding while drawing tethered to creative inquiry.
If you’re an experienced programmer, my aim in writing this book is to bring a theoretical perspective unique to my background within (and perhaps at times, near the boundaries of) the discipline of architecture. For the artist, architect, or designer who has dabbled in programming, you can dive right in with whatever environments and languages you’re comfortable with. The algorithms are programming language agnostic. They can be implemented in object-oriented languages, procedural languages, web-based languages, scripting languages, and often can be performed without a digital computer at all. For the beginning programmer (and others), I’ve provided an appendix with some resources. Those suitable for the complete novice are tagged as such.
A drawing is not final
All drawings are works in progress. Even when a drawing is done it’s open to interpretation. The ambiguity of a line leaves open the capacity for multiple interpretations. This means that if one is working to “get it right,” articulate something perfectly, or achieve an exact result, one may be “rendering,” “communicating,” “computing,” or “simulating,” but one is not drawing. Does this anti-definition mean that drawing can not be a disciplinary practice, that drawing is always in service of something else, a thing to think with, prepare with, or work out prior to the ultimate work? No, it does not. Drawing can certainly function as a discipline, but such a disciplinary practice would seem to require a conception of a work, or a project broader than an individual drawing.
The anti-definitions of drawing posited here expose a friction with contemporary ways of practicing architecture, art, or design. The nonoperative nature of drawing would seem to make it less valuable to architects than a model. Its capacity to surprise can disrupt a goal-oriented design process; yet the reality that drawing always involves human engagement means that drawing demands a degree of design intention, especially with respect to drawing’s position in the linage of a project.
while the number of marks is less than 100 mark
If the marking function was called, say, “squiggle” and it took as input to numbers, an average radius and a length, we can write:
while the number of marks is less than 100 squiggle (10, 100)
How would “the number of marks” be calculated? It is important to remember that unlike humans, the computer does not “see” marks or understand what a drawing is. The programmer needs to keep track of the number of marks made in order to compare that number to a datum. So when implemented, most likely the code would look something like this:
set count to 0
while count is less than 100:
squiggle (10, 100)
increment count by 1
Count is a variable created by the author of the code. It starts at zero, and each time the loop iterates, it increases by one, effectively counting how many marks have been created.
An example that is slightly more complex and uses if-then statements and loops together:
set count to 0
while count is less than 100: if count is even, then squiggle (10, 100) else
squiggle (5, 100)
increment count by 1
To conclude this chapter, consider some custom computational marks:
A squiggle is created in terms of radius, length, and the following actions
currentLength starts at 0
currentAngle starts at 0
Chapter 2 Structures
From Dirty Marks to Lines, Shapes & Representations
What is the difference between a mark and a line? A mark is literal, direct, and unambiguous in its creation. In the previous chapter, exercises prompted the codification of marks, but in some cases, it is important to note, the marks were not lines. This is not a matter of nomenclature, extremity or classification. No matter how bombastic, trail-like, curvy or straight the mark, it might not always register as a line. This is because lines are relational mental constructs. A line is what we read into marks. Sometimes, the association between marks and lines is not one to one. Consider two marks made by a pen in exactly the same location. Consider 100 such marks. The line read by those marks may be different depending on the number of marks, but it is still only one line. Consider the horizon line. The horizon line is real; it can be measured, photographed, described, and defined, but it is not a thing. It can be perceived without association with a single mark. A mark does not always lead to a line and a line is not always made up of one mark. Consider, further, that a line can exist because of the tension between marks—as in when our mind literally connects the dots—or a complete lack of marks—as in when marks fill an area to maximum density except for a small sliver of space.
A shift from marks to lines is important, first, because disciplined drawing requires that the artist, designer, or architect consider not just the actions performed, but the implications of those actions on the perception
A Taxonomy of Taxonomies of Lines
William Empson, a British literary critic, is renowned for his exhaustively close readings of text. His approach is analogous to an artisanal, technical, and critical inquiry into the individual marks in the creation of drawing. Empson is best known for his Seven Types of Ambiguity, 10 which meticulously defines, explains, and categorizes purposeful linguistic double-meaning and contradictions. As a work of critical analysis, Empson’s Seven Types is beautiful in its discipline, though laborious in tone. Later, a few of Epson’s types will be explored in more detail in the context of material and form. For now, it will suffice to note that Empson’s distinction between ambiguities is not ambiguous. With meticulous precision, he establishes seven absolutely unique and distict kinds of literary ambiguity and parses a range of examples to clarify his taxonomy. But can Empson’s structure serve as a manual for writing? The fiction author, Elliot Perlman, gives an answer: yes, but not in the way Empson intended. Perlman is also the author of a very different Seven Types of Ambiguity. 11 In Perlman’s Seven Types, the reader is treated to seven versions of the same story told by six different characters. The ambiguity is profoundly different from that elucidated by Empson, but the matching title is not a coincidence. Perlman’s ambiguity is a matter of voice, perspective, bias, personal identity, sexuality, and psychology. Repeatedly, however, Perlman references Empson’s types explicitly in his novel, using them regularly as a foil to the opinions of the protagonist, also a writer. The lesson from Perlman’s work is that artists often thrive by working with, and against taxonomies rather than working within taxonomies. That should come as a bit of a relief. It is not possible to list all the types of lines, nor do most drawings conform to a limited definition of line. Though a computational approach will require a structure, that structure can (and should) flow between more than one way of thinking about line. Therefore, although a taxonomy of lines12 is futile for the architect, artist, or designer, a taxonomy of taxonomies of lines allows for a structured ambiguity. Neither complete open-endedness, nor straightforward structure, it is somewhere in-between. And now, let’s consider four types of line taxonomy.
The auto-what? Taxonomy
Are lines automatic,14 autographic, automated, or autonomous? Though these four auto-words are exact and absolute in terms of line designation, they are not mutually exclusive definitions. If deploying this taxonomy, it might be tempting to create a category, “none of the above” to classify a line that would not seem to fit under any of those categories. However, despite sharing a common root word, it may be the case that these four terms cover the complete range of all possible lines.
Exercise 2.1 One mark, two readings
Make a drawing with one kind of mark that can be ambiguously read based on either the taxonomies articulated, or a taxonomy of your own. Respect a notion of ambiguity that involves two or more seemingly contradictory meanings being simultaneously sustained, which is very different from what would be visible by drawing one kind of line in one area and another in a different area. It will likely be necessary to edit a mark-making function and or “wrap” it in another function.
Exercise 2.2 Line Finder
Write a function that finds lines in an existing drawing. Create a drawing that highlights, isolates, or otherwise materializes the found line(s).
Exercise 2.3 Line-Maker+Line-Finder+Line-Maker
Incorporate a “line finder” into functions already written to create lines. Use the line finder to direct, limit, and/or bias the creation of new lines.
The final algorithm referenced in this chapter is an example well articulated by Neil Gershenfeld in his book, The Nature of Mathematical Modeling, in which Gershenfeld presents highly technical methods for mathematical modeling as a craft-based inquiry into the meaning of the models themselves, not merely their applications. Gershenfeld sets this up in his introduction by explaining,
“if you seek to make a mathematical model of a violin, you could use a numerical model based on a first-principles description. This lets you match your model parameters to measurements on a real instrument and change parameters between a Stradivarius and a Guarneri. However, running it in real time will require a supercomputer, and the effort to find good parameters for the model is almost as much work as building a real violin. Alternatively, you could try to use an analytical (pencil-and-paper) solution to the governing equations in return for some large approximations you may be able to
From Willful Misuse to Opportunistic Surprise
Exercise 3.1. Re-Code a Common Digital Tool
Identify an existing tool in a piece of software you regularly use. Some examples could include the “paint bucket” tool in digital imaging software, the “blend surfaces” command in a digital modeling environment, or the “array along curve” command in digital drafting software. The tool itself is not extremely important, though it should be a tool that you understand completely in terms of its performance.
Before you start, be sure you understand what it requires to function—its inputs. You should also be able to predict the outcome before you use it. That’s the one of the requisites of any tool: the ability to deploy it in a specific way to achieve some kind of desired outcome. Write code for your own version of that tool, from scratch.
That may have been the first exercise in this book that warrants the question of, was that really necessary? Beyond becoming a better programmer (certainly a laudable pursuit), what is the purpose of re-making a readily available tool? Why spend time re-inventing the wheel? In all likelihood, tool users understand tools less than is assumed. What actually happens “under the hood” may not always be apparent. It is equally unlikely that most designers will need to reach for a computer graphics textbook for the solution to this exercise. Some intuition about the tool was present in the mind of the user, but programming transforms that intuition into design knowledge. Roman philosopher Seneca is often attributed to what is now a truism, “While we teach, we learn.” Programming something–even something that we know on some level already–is like teaching to a computer. It creates deeper more solid understanding.
With the value of programming to articulate knowledge that was previously tacit, incompletely formed, or latent established, it is possible to shift focus to the creative potential of coding a tool that already exists. The next step is to consider the new opportunities afforded to given access to the code of a programmed tool.
Exercise 3.2 Misuse a Common Digital Tool
Make a work of art with your code by continuing to change and evolve it. Embrace the surprising results that may emerge as you treat your code not as tool to perform a single function but a medium to explore new possibilities. What may have been considered a flaw during the first part of the exercise now may be prized as a generator of a new kind of line, form, shape, or space. Furthermore, explore the productive misuse to the code. Can the code be modified to expand the set of possible inputs beyond what would’ve made sense within the narrower scope of possibilities when interpreted as a mere tool?
Depth is Inherently Difficult
Exercise 4.1 Automatic Drawing
Make what Psychologist David Maclagan would call an “automatic drawing.”5 Repeat until the perception of depth is unavoidable. If a class or a group is available, hold a group critique of automatic drawings in which depth is the only topic of discussion.
In chapter one, multiple anti-definitions of drawing were explored and drawing was considered not in terms of what it could be, but what it can’t do. Considering why we draw is a similar pursuit. The positive reasons are vast and varied, but they often reduce to a consistent pattern: drawing is helpful because depth is difficult. Depth in drawing, on a practical level, is minute. Drawing media is inconsequentially thin. The paper of this book is about .0004 inches thick, and the thickness of the original paper of the drawings reproduced in this book is about the same. A drawing with around one million line segments is still around .0004 inches thick, with no measurable change in thickness from before to after the drawing process is complete. Any real thickness is a matter of perception. Depth perception is a matter well-studied6 and in all 2-D image-based representation, various “depth cues” trigger our natural perception of space “in” an image. But in contrast to the advances in digital imaging, where the relatively low resolution pixel-based images advanced to become super-small in so called “retina displays” and virtual reality headsets that undermine the presence of the screen-as-distant-object in favor of an immersive experience, the drawing object reminds the viewer that it is there and it is flat. Depth can be implied, and our perception of depth can be triggered, but depth is in a constant, but productive, battle with flat reality. This may explain (along with the fact that, as Bruno Latour and Albena Yaneva explain,7 a building is always moving, and the key representational challenge lies not in the modeling of the form, but in modeling the multi-dimensional space of building parameters) why various “draw in space” technologies have never matured beyond the stage of demonstrative novelty. Though counter to what we often value about technology, when drawing, often what is most productive is unintuitive, seamful,8 and difficult.
