This first offering is an experiment in creating a set of concurrent courses being taught in different departments, centering around the study of the architectural design process, and the methods and tools to support this process.
The core is the "Computer-Aided Design Methods" studio course (101) taught by Prof. Yehuda Kalay in the Department of Architecture, CED, at U.C. Berkeley. Students in this design studio will design one or more buildings in a semester, using existing as well as newly developed computer tools to support the interdisciplinary design process and the communication among the participants. The architecture students will focus on the design methods for buildings: they will play the role of the architects and designers in the context of a major design such as a new computer science building.
The focus of the graduate course CS 294-5 in Computer Science is to help develop new modules for a flexible and extensible CAD system that supports the whole design process. This includes the enhancement and extension of data bases to capture not only the geometry of the emerging design but a wide variety of design information from the original wishes of the customer, through formal specifications for the building program, conceptual solutions, problems arising and their resolution, elevation and floor plans, and a 3D visualization of the whole building in interactive walkthroughs. The CS students will play the role of the customer and will develop software that will make it easier to check whether they will be getting what they asked for.
Through their interaction, the participants of the different courses will gain a better understanding of the complexity of designing a building and will learn about the benefits and difficulties of collaborative design and problem solving and how to use modern computer and communications equipment to support these activities.
The course will involve reading several papers, studying and evaluating one or two existing architectural CAD tools, and a substantial programming project enhancing an existing CAD system, or creating a prototype tool from scratchsuch as a database tool, a geometrical synthesis tool, or a checking/verification agent, or an AI planning tool.
David Bacher :
: : drbacher@cs
Rick Bukowski :
: : bukowski@cs
Laura Downs :
: :
laura@cs
Rob Hitchcock :
: :
RJHitchcock@LBL.GOV
Randy Keller :
: : rkeller@cs
Rick Lewis :
: :
rickl@cs
Roxy Lo :
: : roxy@po.eecs
Houman Meshkin :
: : houman@po.eecs
Tuan Nguyen :
: : ntq@po.eecs
John Sefler :
: : sefler@cory
Maryann Simmons :
: : simmons@cs
Gustavo Llavaneras : : : gllavane@ced
Ivan Azerbegi :
: : azerbegi@ced
David Hwang :
: : dhwang@ced
Francesco Nerici :
: : fnerici@ced
Park Sook Woo :
In each group, capture the discussed building specifications
on the computer.
Make your captured specifications accessible through the above
links,
or send me a different html address if the above one is
impractical.
Prepare a 1-2 page description of your scheme.
You will make a 5-min. presentation in class.
These emerging designs, at the level of the massing studies and
rough floorplan allocations and, perhaps, an elevation or two
should be captured somehow in computer-readable form.
Each group should make an innovative attempt at finding a
sharable, extensible format.
As for assignment #2, prepare a 1-2 page description of your
scheme.
Make this description as well as the captured designs accessible
to everyone
by linking them to your personal WWW pages as well as to the
prepared pointers
in the Emerging Conceptual Design section
above,
{typically cs294/design.html}.
The CS294-5 students will prepare prototype schemes to capture such floorplanning info.
Create floors at three levels of abstractions.
You will find the model floors #2, #5, and #7 on the Mac in 634
in CARLO/SODA95.
Follow the instructions in the
handout.
Select one of the suite of
desired tools
and take responsibility for it.
Study its description(s) and specifications, and refine the
specs according to your own taste.
Write your own specs and a plan (about 1-2 pages), concentrating
on the following items:
Plan:
What is the quick-hack-trial tool (turn #1 on the spiral) going
to do ?
What are all the operations that the user can do ?
And, specifically, what is the tool NOT going to do.
E.g., it will deal only with rectangles, not with more general
polygons.
Interface:
What data is your tool exchanging with the general data base ?
Talk to the data base person and make sure that this data can be
supported.
Key Decisions:
What are the crucial issue that define how efficient and user
friendly your tool might be;
but more importantly, how difficult it will be to make the first
prototype work ?
E.g., in database only represent rectangles; let elliptic and
circular bubbles
simple be a viewing mode where the shapes are generated on the
fly from rectangle information.
E.g., make rubberbands go from center to center of bubbles; draw
them first
to make the result look prettier.
Get those revised specs approved by CHS on Wednesday in/after class.
When you have a useful tool, create some documentation for it: in the form of a WWW home page which can be linked directly to tool list in the Section above.
ALSO:
Think of another tool development or of a substantial extension
of the tool that you have built
as the final course project to be done in the last 4 weeks of
the course.
We did not attempt to revamp dramatically the traditional processes involved in learning either architecture or computer science. That is, we did not attempt to make architects of the computer scientists, nor computer scientists of the architects. Neither did we force them into a mode of collaboration that is radically different from the practices they have been used to.
A cohesive suite of design tools was defined which would support, rather than take over, the conceptual design process. These tools should reduce the tedium of keeping track of a detailed and extensive set of floor area specifications for the various functions in the building and of the desired adjacencies between the various spaces. They would allow to gradually massage a conceptual set of spaces, first expressed as a bubble diagram, into a set of schematic floor plans, integrated into floor outlines that result from slicing tentative massing models at the appropriate heights. These floor plans could then be fleshed out into tentative floor layouts with thick walls, containing automatically generated token door and window openings. These layouts would then be extruded into a consistent solid model of the shell of a building, which in turn can be explored with a real-time interactive walkthrough program running on a Silicon Graphics workstation.
While the CS students were developing simple skeletal prototypes of these CAD tools, the architects were developing their designs, experimenting with many different massings, different forms, and different kinds of facades. In this process, the exact functional specifications seemed to get forgotten, since no CAD tools existed yet that could have kept track of the requirements automatically. When the "final" conceptual designs were presented, there were substantial differences with respect to the specified floor areas, and the desired adjacencies were often grossly violated. Clearly tools are needed to keep track of these issues in a way that detracts the architects the least from their creative conceptual design activity; they have plenty of other issues to be concerned about, such as esthetic issues and the relationship of the emerging design to the site and its surroundings, -- issues in which CAD tools can be much less helpful.
The repeated conceptual re-design activity went on much too long. For most of the designers, the conceptual design only settled about a month before the end of the course, leaving just enough time to document the design and to create the computer-based models. There was no time left to do any design development or to deal with the interior design of some selected spaces. Clearly, in subsequent course offerings, a hard limit on the time for conceptual design will have to be imposed, particularly if we also want to include a group of structural engineers in the process. Hopefully, the CAD tools developed in this course will make this possible.
In the first half of the course, the architects were reluctant to use 3D CAD modeling tools. The initial learning threshold for Form.Z proved to be much higher than we had expected; its potential power comes at the price of a bewildering set of menus and options. Yet by the end of the course, the architects had become quite skilled with the use of Form.Z and were able to created rather complex models. I was struck by a comment of one of the students who said: "This is great ! I think I will never touch cardboard models again ! This is the way of the future !" I was surprised by this enthusiasm about CAD in view of the rather inadequate computer resources that were available to the computer architecture students. It was painful to watch them to try to get a suitable view of their projects up on their Macintosh screens, waiting for multiple re-draws of models with several 10-thousand polygons, often resulting -- after several minutes of waiting -- in a crash because of memory limitations.
The key lesson here is that we need better tools that can work in an easy and natural way with multiple levels of abstractions, so that one can keep under control the complexity of the model with which one works at any one time. One would like to seamlessly switch back and forth between: simple symbolic floor plans, the outer skin of the building, or just an overall massing model without details. Ideally these different views are coupled so that if one makes a major change in one of them, it gets adequately reflected in the others as well. The tools that were developed in this course don't go that far, but they should be a step in the right direction.
In the last couple of weeks, suddenly things started to come together in both courses. In the CS course, a well connected tool suite had been developed that would indeed allow a designer to massage a building program from an automatically generated bubble diagram into a schematic floorplan and then to extrude it and visit the empty building shell with the Berkeley WALKTHRU program.
On the architectural side, three realistic conceptual designs for our rather complex building program were completed. All three buildings look like potentially realistic designs that could be implemented, and they seem to interpret the specifications sufficiently closely so that they could indeed work as a home for our Computer Science Division.
The EECS department at U.C. Berkeley has a long-standing tradition of combining research and graduate education with positive results in both domains. The interdisciplinary collaboration of researchers in integrated circuits and in computer science lead, during the 1980's, to the emergence of relatively simple yet powerful CAD tools for VLSI design, many of which, after some refinement and embellishment, have become commercial products or even industry standards. In the next 10 years, the combination of architecture and computer engineering may well prove to be an equally fertile breeding ground for new CAD tools and for a revolution of the design process. A combination of courses in architectural design and in CAD tool development seems to be an excellent environment in which experiments can be run and creative ideas can be explored and tested quickly.
