Scripting and Drawing: Rough notes #1

I need to give a lecture this coming Friday on scripting and drawing, for our ARCH 114 “2D Representation” class at Pratt.

It’s a very exciting topic to me.

My first instinct is to approach this thematically. E.g. projective drawing as an essentially parallel system and way of structuring design, and scripting as an essentially serial or linear way of doing so. BUT of course as soon as we parametrize a script we are setting up parallelisms. So this distinction is only valid or even interesting as a way in to each discipline… since, fundamentally, lines operate in parallel with one another, and code is executed seriatum by the needle of the computer.

There is also the technical concern — how to get the students’ hands dirty with scripting? At first I thought Scriptographer would be great, because they are learning Illustrator anyway, but at this point I unfortunately don’t have time to get into it. So I turn to Processing, gladly enough, since in addition to being fairly easy to install and kick-start something with, it is also a tool that is seeing more and more use (Marc Fornes having expressed disgust a few months ago at the notion that I would show the students any scripting tool they wouldn’t actually use in their coming practice… this in response to my idly mentioning AUTOLisp as a tempting option, since the class is primarily an AutoCAD class, after all). Right, so, P5 all the way. I intend to send an email tomorrow night prompting all students to install it before the lecture.

Next up is the necessity of finding good examples, not just of current scripted work (of which there is a lot, though not necessarily a lot that is clear for this kind of example), but also of historical examples of work executed with drawings that exhibited some script-like thinking. And here I hit on the real nut and challenge of the lecture: what is this transition from drawing to scripting? Is it a transition? Most scripts draw, in the practices I’ve seen, so in some ways scripting is just the Taylorization of drawing.

But turn the mirror, and we see that most computer drawings contain scripts, or, at least, the hidden connections that characterize digital parametric models. E.g. I change something in the “front” view in Rhino, and of course that change is reflected in the top view (where appropriate). If I myself were responsible for the projection, then I myself would have to propagate the change. Aha, here I’m hitting on one of the things that troubles me about computer production in general. Was there any important design thinking in the propagation of change, in the updating of models, which we used to do ‘by hand’ (even in CAD, for years)?

Well, certainly by tracing out the changes from an elevation to a plan, one thinks them over, one is able to ponder the implications for detailed features as well as the overall formal changes. Much of this is simply the reflection that comes from taking a bit of time. You might say that, if one is a professional draftsman, one doesn’t think all that much at all, but I REJECT that notion, since I’ve been spending about 10 hours a day in CAD for the past two years and I find I am only *more* sensitive to details, *more* sensitive to the implications of every change in plan or section, *more* able to internalize the model of the building based on the drawings I have executed. Maybe after twenty years this would be different, but I doubt it. Drawing, even point-and-click (CAD) drawing, is a deep craft.
“Taking a bit of time”, of course, is the target of many of the advocates of BIM (essentially a heavily parametrized — scripted — drawing system). I am actually still in doubt that we can do good work much faster than a firm from the 40s, though. Maybe twice as fast? In any drawing system where the designer propagates the changes, sure more time is spent on that propagation, but as a percentage of project time this actual propagation is not so great. I can draw in CAD much faster than I can think, much of the time, so of course my drawing is limited by my thought. The opportunity cost of propagating changes manually is therefore small.

Risk of error is a whole other rationalization for BIM, natch.

But parametrics, and their systematization into things like BIM, is only one aspect of scripting. Another deep power of scripting is its capacity for repetition, and the incrementalization of any change. This has led to what I consider to be the surprisingly dry well of “emergent form”, through various structures, such as “agent-based” code (the interaction of little automata to produce qualitatively alien effects at larger scales), and ……. huh, is all emergence actually based on automata of some kind or another? There are huge varieties in types of automata systems, natch.

Now, agent-based systems do produce incredible effects, but for some reason not inspiring architecture. This may just be a question of time… what are the challenges facing them?

- scale — scale (weight, speed, depth, volume, etc.) is hard to register in a script, whereas the human eye can make an incredible number of scalar decisions (and assumptions) in an instant. This is what gives drawing a lot of its power. At any point the gesture is roughly the same to draw a line that makes a radical change, vs. a line that makes a subtle change. I suppose scripting has some of this power in its implementation of global vs. local variables and functions, but the control points in a script are rarely as refined, in terms of scale, as the control one has in a drawing.

- hmmmmmm … I’m going to sketch a bit.

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>