CS 294-5: (Spring 1995)
ARCHITECTURAL CAD

  1. --> Catalog Entry
  2. --> Course Description
  3. --> Participants
  4. --> The Computec Project
  5. --> Emerging CAD Tools
  6. --> Current Assignments
  7. --> Course Discussion

Catalog Entry

  • CS 294-5: ARCHITECTURAL CAD
  • FULL COURSE TITLE:
    Computer Aided Tools for Architectural Design and Construction
  • INSTRUCTOR: Carlo H. Séquin
  • COURSE NUMBER: CS 294-5
  • COURSE CONTROL NUMBER: 25019
  • UNIT VALUE: 1-4 units
  • PREREQUISITE: Competence in C programming
  • FIRST OFFERING: Spring 1995
  • CLASS TIME: Mon. 2-4pm, Wed. 2-3:30
  • LOCATION: 405 Soda Hall or 801E Wurster Hall

    Course Description:

    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.


    Initial Participants

    CS 294-5: Architectural CAD

    Prof. Carlo Séquin : : : sequin@cs

    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

    Architecture 101: Computer-Aided Design Methods

    Prof. Yehuda Kalay : : : kalay@ced

    Gustavo Llavaneras : : : gllavane@ced

    Ivan Azerbegi : : : azerbegi@ced
    David Hwang : : : dhwang@ced
    Francesco Nerici : : : fnerici@ced
    Park Sook Woo :


    The "Computec" Project

    The joint task tackled by the two courses in Spring 1995 is to study a design of a
    computer science building with more or less the same specifications as Soda Hall,
    but for a different site on campus.

    Design Specifications

    Capturing the Good Old Soda Hall Design

    Emerging Conceptual Designs of the Architecture 101 Studio

    The Surviving Design Teams and Their Work


    Emerging CAD and Communications Tools

    Here is the Original Wish List:

    Emerging Tools and Their Manual Pages:

    == Many of the links below have withered away over time, as studdnts have left, and accounts have become inactive. Sorry ! ==

    The FINAL TOOLS and Their Manual Pages:


    List of Assignments

    #1 DUE: 2/1/1995:

    Think about desirable CAD tools; -- describe one of them in about 1 page.

    #2 DUE: 2/8/1995:

    Each student should make sure they have an active home page
    from where they can link to other Cs294arch project related pages.
    -- if necessary study:  HTML for Beginners

    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.

    #3 DUE: 2/15/1995:

    Each team with their architects will present their emerging designs on 1/13/95 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}.

    #4 DUE: 2/22/1995:

    Each team with their architects will present their emerging floor space allocation.

    The CS294-5 students will prepare prototype schemes to capture such floorplanning info.

    #5 DUE: 3/01/1995:

    Make Two CS-294-5 Tool Proposals:
    Each 1 page total, containing a few sentences for:
    Name and brief high-level description of tool.
    What is the problem that this tool tries to address ?
    Which do you consider the most tedious part in it that needs help the most ?
    What is the key idea / algorithm / interface element that addresses above problem ?
    Outline spiral development steps for your tool;
    -- give at least three turns (levels of development).

    #6 DUE: 3/08/1995:

    As a group discuss and refine the format and structure of the database.

    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.

    #7 DUE: 3/22/1995:

    Make a prototype version of the tool that you picked.
    Encourage one or two of your colleagues to try out the tool.
    (This is the first turn on your tool development spiral),

    #8 DUE: 4/05/1995:

    If the prototype looks promising, embellish and refine it,
    (this is the second turn on your tool development spiral),
    else, try some other tool and build a new prototype.

    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.

    #9 DUE: 4/12/1995:

    Formal written proposal for the second major round of tool development.

    #10 DUE: 5/12/1995:

    Final tool descriptions and manual pages, properly inserted into this WWW document. The sources and executables should be in a permanent, readily accessible place.

    Course Discussion

    Overall Organization

    Pairing the two courses described above, and setting up the network-based WWW infrastructure to allow electronic interaction between the two courses, required a somewhat larger-than-usual logistics overhead. The excitement experienced in the course itself and the final results made this investment well worthwhile. At first, there were some concerns that the different levels among the students (undergraduate architects and graduate computer scientists) might pose some sociological problems. We were pleased to find out that they did not. Rather, a courteous professionalism developed, where each group respected the knowledge of the other. The built-in role reversal of the courses, where both groups were at the same time designers and clients, made each student appreciate the difficulties and positions of the other party.

    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.

    Progress During the Course

    The collaboration between the two courses started out very well. The architects listened carefully to the requests of the clients and seemed to understand quickly what this building program was all about. The computer science students quickly got a grap of the initial phases of the architectural process leading to conceptual designs and of the aspects of this task that lend themselves well for the introduction of computer-aided tools.

    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.

    Conclusions

    Overall, we think the direction plotted by these joint courses holds much promise for the future. The combination has provided added value to both parties involved, and generated some useful tools which can be reused in future courses. We plan to repeat this experiment, perhaps even on a broader basis, by including the participation of other professionals, e.g., civil engineers or construction managers.

    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.