BIM Whitepaper

 

Vectorworks ARCHITECT:
A BIM Application Tuned for Architectural Design

dated April 2003

Executive Summary

Most of the major AEC design software vendors in the US have recently produced white papers regarding a "new approach" to architectural CAD that is variously referred to as "Single-Building Model", "Virtual Building Model", or "Building Information Model" (BIM), which has become the accepted acronym. Vectorworks ARCHITECT meets the key criteria for a BIM application by providing the following capabilities:

  • Parametrically-defined interacting building objects
  • Simultaneous 2D/3D/Parametric viewing & editing
  • Integrated reporting of non-graphical data

However, in the real-world process of architecture, BIM alone isn't enough-it needs to be "tuned" for architectural design. Vectorworks ARCHITECT meets this need by providing the following capabilities needed by the designer:

  • A flexible workflow to allow capture of design ideas
  • Transformation tools for moving data into the model
  • Graphic tools to enhance the BIM for contract documents
  • Some BIM applications require the user to work in two applications, or even to translate design data between two different file formats to fully achieve contract documents meeting their graphical expectations. We conclude our paper with a cautionary tale about the costs inherent in this approach.


    What Defines a BIM Application?

    Any vendor of BIM applications will tend to define BIM in terms of his or her own product [1] . Therefore, few if any "platform-independent" definitions of BIM exist. However, a recent white paper by CYON Research [2] reviewing a competitor's product sets out what might be considered "minimum requirements" for calling oneself a BIM product. These requirements are:

    • Parametrically-defined interacting building objects
    • Simultaneous 2D/3D/parametric viewing & editing
    • Integrated reporting of non-graphical data

    Let's examine each of these in turn and see how Vectorworks ARCHITECT meets these requirements:

    Parametrically-defined interacting building objects

    The CYON paper states that A BIM application approaches the process of architectural representation as an assembly of intelligent objects rather that as a drawing:

    "..a door is not simply a collection of points, lines, and curves arranged to look like a door--it is an object, with an object-oriented infrastructure, that displays many of the qualities and behaviors of a real door within the context of the building information model."

    From this statement, we can infer the following explicit requirements:

    • A BIM contains "objects" that display many of the qualities and behaviors of real construction assemblies within the context of the building information model. [3]
    • A BIM has "'underlying intelligence': when a door is inserted into a wall, the wall parts and 'heals' to accommodate it; a door will move with a wall in which it has been inserted."

    Vectorworks ARCHITECT provides these capabilities, served up in a user-centric and flexible manner. Simply put, for basic architectural modeling a user should never have to work "in lines". Vectorworks ARCHITECT's rich architectural objects (walls, roofs, columns, doors, windows, slabs) meet this basic criterion for BIM and provide the foundation for easy architectural modeling.

    These objects are hybrid, that is, they display appropriately in both 2D and 3D, depending on the user's view. For those times when the architect needs a truly "custom" object that doesn't exist among the objects provided, he can simply draw it (in 2D and 3D) and turn it into a "hybrid symbol" that has well-defined rules that allow the architect to define how it interacts with walls and roofs. So in addition to the flexibility in design workflow mentioned earlier, Vectorworks ARCHITECT allows for flexibility in design vocabulary.


    Simultaneous 2D/3D/parametric viewing & editing

    Vectorworks ARCHITECT, like any BIM software, provides strong benefits when creating coordinated model and views during the schematic design of a project, when the designer needs to study the project from as many different points of view as possible.

    The CYON paper has the following to say about simultaneous viewing:

    "This 'intelligence' makes for a realistic model, one whose every aspect is linked to every other aspect to reflect reality. A change made to any 'view' of the model, whether graphical or textual, is immediately reflected in every other 'view.'"

    From this statement, we can infer the following requirements for a BIM application:

    • A BIM supports multiple simultaneous views of a single, unified (2D and 3D) building model [4]. If the model is changed, that change should be reflected in all views: plan, elevation, perspective, detail, etc.
    • Changes to the underlying properties of the BIM Model should be reflected in all views of the model. BIM model objects, where appropriate, should have "parameters" or "properties" that will manage model geometry from a single entry point.

    In these respects, the BIM paradigm is a natural outgrowth and evolution of the venerable First Rule of CAD, which has been with us since the pin-bar and Mylar days, i.e., "Draw it Once". This "rule" once applied to the (predominant) plan view of architectural drawing and organization, and the BIM paradigm has expanded that approach to all views--plan as well as supplemental views (elevation, detail, and tabular views). Vectorworks and its predecessor MiniCAD have for over 18 years supported this paradigm, not only in plan view but in supplemental views (i.e., elevations, perspectives, detail views) as well.

    In addition to the "architectural objects" mentioned in the section above, Vectorworks ARCHITECT's advanced modeling and viewing features (hybrid symbols and parametric objects, the Layer Link and the Model View Tool) satisfy this BIM requirement at a fundamental level.


    Integrated reporting of non-graphical data

    Simultaneous viewing isn't limited to orthogonal drawing graphical views of a model. With Vectorworks ARCHITECT, points of view may be analytical and numerical as well as spatial using dynamic linked worksheets on the presentations that can report on costs, scheduled non-graphical data, program space conformance, and material or area take-offs.

    The CYON paper, in a particularly enthusiastic moment [5], makes the following observations about reporting of non-graphical data:

    "Of course, quantity surveys, bills of materials, window and door schedules, finish schedules, and cost estimates can be prepared almost entirely automatically from the Virtual Building. It offers a level of management control that is unheard-of in conventional construction processes."

    From this statement, we can infer the following reporting requirements for a BIM application:

    • A BIM allows analytical (tabular) views of graphical and non-graphical data contained in the building model. If the model is changed, that change should be reflected in tabular as well as graphical views.

    Such capability is "unheard-of" only if you've never seen or used Vectorworks. For the past 17 years, Vectorworks has pioneered exactly this kind of user-definable reporting, and in fact currently has the most mature and customizable integrated reporting feature among BIM applications. This allows not only "post-design" reporting (e.g. material takeoffs and schedules) but also analytical feedback during the design process (e.g. areas programmed vs. actual). Vectorworks data records, text linking, and customizable hot-linked worksheets put it at the forefront in this BIM requirement.

    What makes a BIM application "Tuned for Design"?

    Since Vectorworks ARCHITECT meets the "minimum requirements" for a BIM, why do we say it is "Tuned for Design?" The answer to this question revolves around one virtue of the Vectorworks approach: Flexibility.

    A second white paper by Cyon Research [6] suggests that architectural designers are "superstitious"" about their creative processes and that this lack of self-understanding (and a general aversion to computer-based processes) is what is slowing adoption of BIM. This same paper goes so far as to suggest that one reason that architects haven't adopted advanced computer techniques (by which they mean BIM) is that architects are reluctant to save building owners money, because this would mean a reduction in their fees! [7]

    Rather than impugning the professional ethics of architects to explain their technology preferences, we feel that this adoption rate is better explained by the fact that most BIM applications require the user to adopt a rigid design methodology. This inflexibility of process and workflow is limiting for architects because of the variety of abstract design activities they pursue as a matter of course. The architect shouldn't have to build a detailed model to communicate a concept at an early stage of the design process. (Architectural conceptualization is difficult enough as it is!)

    A recent real world posting to an email list server supporting one of Vectorworks' competitors echoes these issues:

    "I was wondering how far others are taking the [BIM] concept - in real life that is....Theoretically, one could go nuts and model every screw and nail, but what would be the point?I've experimented with full-on building information models - the size of a garden shed! - just to see how far I could take it - But I always seem to come back to "my old way". When it comes down to getting CD's out the door, looking decent, that's what ends up happening."

    This quote suggests that BIM alone isn't enough. What the user needs is BIM capabilities in a broader context of design tools. Vectorworks ARCHITECT provides just this by supporting the user's varying process with the following capabilities:

    • A flexible workflow for design;
    • Transformation tools for moving data into the model; and
    • Graphic tools to enhance the BIM for contract documents

    Let's look at each of these capabilities to assess how Vectorworks ARCHITECT supports the individualized approaches of architectural designers, and to learn more about why it has become known around the world as a designer's tool:

    A flexible workflow for design

    Architectural conceptualization, the creation of a set of core concepts upon which to hang all the formal decision-making that must follow through the entire course of the project, is difficult intellectual work, and it is only natural that it is a personalized process. We understand that designers approach this process from many different directions. Vectorworks ARCHITECT delivers a versatile array of tools that provide for many "points of entry" into the design process:

    • 2D sketching and diagramming;
    • 3D Mass-modeling, including "free-form" sculpture;
    • Bubble diagrams and space planning; or
    • Simultaneous 2D/3D modeling with walls, floors, roofs, and other parametric architectural objects.

    Let's look at a high-profile example, the successful Daniel Libeskind design for the new World Trade Center in lower Manhattan, to illustrate the importance of the simple design techniques of sketching during architectural conceptualization:

    Libeskind WTC concept sketch 1
    Libeskind WTC concept sketch 3
    Libeskind WTC concept sketch 4
    Libeskind WTC concept sketch 5

    Let's also look at some of Libeskind's early presentations that make use of mass-modeling, diagramming and mapping:

    Libeskind WTC phasing concept
    Libeskind WTC context map

    Libeskind WTC ground level concept
    Libeskind WTC level one concept

    These examples support the above assertion that architectural conceptualization is a multi-modal activity, one that draws on basic creative activities of sketching, sculpting, and diagramming, pursuits that will be approached in different ways by different users. Vectorworks ARCHITECT provides a wide variety of tools that support these activities (among others) as "entry points" into design, including:

    • Fundamentally strong 2D graphics and notation tools;
    • Support for scanned images integrated into a sketching environment;
    • The Space Planning and Programming tools;
    • Intelligent architectural objects for forming the detailed building shell;
    • The Massing Model object; and
    • The 3D PowerPack for advanced shape creation.

    Transformation tools for moving data into the model

    Whatever the initial approach of the designer, it's important that he not have to "throw work away" and that data in the designer's preferred conceptual form be transformable into the model that will aid in producing the orthographic architectural drawings. Such data might be sketched or it might be in tabular form, such as might be part of a design brief produced using Vectorworks ARCHITECT's Space Planning feature.

    Using the Space Planning and Programming tools, it's possible for an architect to begin with a "design brief", a tabular worksheet for input of programming requirements, turn those numeric requirements into abstract spaces, evaluate the spatial relationships by creating affinities between the spaces using "Space Links", and automatically turn the entire "bubble diagram" into BIM-style spaces defined by walls. The spaces and their relationships can remain as part of the project throughout its life cycle and be evaluated and/or re-examined at any point.

    Likewise, if a user has simple sketched shapes that want to become spaces and then walls, this conversion is also a standard feature of Vectorworks ARCHITECT. Once the user has converted his sketched shapes into space objects, they can be converted into wall-defined spaces. Likewise, a selection of walls can automatically be roofed or can automatically generate a shape to form a slab.


    Graphic tools to enhance the BIM for contract documents

    An unspoken but common assumption regarding BIM is that, once a BIM has been created, creation of production drawings is "automatic". This conceptual model makes some presumptions, including:

    1. The BIM is comprehensive enough to allow an arbitrary view (which view will become the production drawing) to be sufficiently complete for production drawings [8];
    2. The software creating the production drawing view can make reasonable inferences about detailing and the intersection of building systems and assemblies.

    In practice, however, virtually all architects will find the need to "overlay" the chosen view of the BIM with notations and dimensions and, often, additional graphics. Some of these graphics may convey information (e.g. floor and wall decorative patterns) while others may be present as a matter of office graphic standards or convention (e.g. line weight enhancement or graphic patterns and fills). Therefore, in practice the view of the BIM becomes a "geometric canvas" on which the architect will execute his final drawing. Therefore, without a strong drawing and graphics foundation any BIM program will fall short.

    The graphic conventions used in architectural drawings have evolved in some cases over the entire life of a firm. This graphical language can be essential to the fundamental communication ability of the "contract documents", not only by the architect, but also by the builder. Once again, at the end of the architectural design process as at the beginning, the process requires a robust set of graphical tools well tuned to the tasks at hand. Therefore, the ideal BIM program must not only "learn to draw like an Architect"; it must draw like one of "our Architects"!

    A very good example of the ongoing need for graphics tools in the context of the BIM can be found by reviewing the PDF file TutorialsImperialENU-Letter.pdf that is a tutorial for Revit 5 [9]. Reviewing the documentation section, "Detailing the View", on pages 286-301 (file pagination 297-312), illustrates the process of converting a "geometric canvas" provided by a BIM into a finished drawing. For those who don't wish to peruse this training data, a brief outline of the process for turning a BIM view (in this case, a detail of a wall-floor intersection) into a finished drawing is as follows:

    • Re-trace part of the view to add earth-fill pattern;
    • Add detail components (2D-only graphics that are not part of the BIM):
    • 2x dimension lumber;
    • Plywood sheathing;
    • Anchor bolts;
    • Lap siding;
    • Add line work to emphasize the cut plane of the detail section;
    • Re-trace part of the view to add fill patterns for gypsum sheathing;
    • Re-trace part of the view to add fill patterns for concrete foundation walls;
    • Add line work for a vapor barrier;
    • Add detail components for batt insulation;
    • Add detail components for break lines at the boundaries of the detail;
    • Hide the view so that only the detail components and line work are visible;
    • Add callouts for material descriptions;

    This documentation confirms that the BIM is creating a "geometric canvas" as an underlay for the actual detail drawing. Although this is a detail view, and therefore somewhat of an extreme example, it will be the rare plan or elevation view that does not also incorporate significant graphical information that is not contained in the BIM.

    The real question should be, "Why does it take all of fifteen pages of documentation to describe the above process?" The answer is because the process is describing a software application that is tuned only for BIM and not for graphics as well. Vectorworks' well-known graphical capabilities provide the broad palette of tools needed by the architect to tune his drawings.

    A Cautionary Tale: The Cost of Translation between BIM and CAD

    One of the strengths of Vectorworks ARCHITECT is that it supports its BIM capabilities with outstanding graphics tools in a single application program, utilizing the same file format, from a single vendor. Sometimes "Less is more [10]", indeed.

    If this seems obvious, it is not. The amount of time and money spent by architectural firms moving data from "Modeling" or even "BIM" programs in order to accommodate their graphical work product is staggering. Consider the amount of cost and effort in coordination and file translation required to move data between AutoCAD and Revit: the AutoDesk training documentation AutoDesk Revit Interoperability with CAD [11] is a daunting 26-page manual that sets out the procedure for exchanging data between two programs from the same vendor. These include:

  • File naming;
  • Layering standards;
  • Handling external (non-graphic) data;
  • Color and line weight mapping;
  • Guidelines for external references, and
  • The actual process of data export and import.
  • Therefore, for those offices who are using BIM as the "front end" of the architectural process and who expect to supplement that with traditional CAD or graphics for production or presentation, it may not be enough to look to a single vendor to streamline the process--it may require a single application program.

    Conclusion: BIM, Drawing and the Role of the Architect

    Ultimately, of course, the role of the Architect in society is unchanged--to create a built form of "firmness, commodity, and delight" [12] within the environment, (and to meet the client's budget!). The process by which the Architect realizes that role, moreover, will inevitably be affected by available technology. It seems clear that, for the foreseeable future, advanced capabilities such as those embodied by BIM will have to be supported with the capability to "draw well" in the successful architect's office.

    Vectorworks ARCHITECT does this by providing the broadest capabilities of any single BIM application in the industry to support the complete architectural design and documentation process:

  • A broad array of sketching, and modeling tools for conceptualization;
  • Programming tools for bubble-diagramming and space planning;
  • Complete BIM-capable architectural objects;
  • Transformational tools to move concept data "into the model";
  • Specialized as well as general graphical tools for creating contract documents;
  • User-definable data and reporting capabilities for scheduling and take-offs;
  • Will any BIM application eventually become "intelligent" enough to "draw like an architect" and replace the current paradigm where the architect chooses and embellishes the views that comprise the building description? This level of "intelligence" in software does not yet exist; in our opinion, this is not necessarily a bad thing, because people who become architects like to draw; it will be a long time before drawing ceases to be a part of architectural design.


    [1] We leave it to the reader to determine if we also follow this unfortunate trend.

    [2] The Building Information Model: A Look at Graphisoft's Virtual Building Concept, Cyon Research Corporation, page 4. At the time of this writing, this report is available online at: http://www.wbh.com/WhitePapers/Graphisoft_Virtual_Building_Model--a_Cyon_Research_White_Paper_030102.pdf

    [3] Another way of saying this is "the user interacts with his information as high-level objects instead of low-level (primitive) graphics."

    [4] Various vendors refer to the "Building Model" as a "Single-Building Model" or "Building Database" or some other combination of these terms.

    [5] Cyon Research Corporation, op. cit., page 4.

    [6] Architectural Automation: Facing the Challenges of Work-Culture, Cyon Research Corporation. At the time of this writing, this white paper is available online at: http://www.graphisoftus.com/whitepapers/Cyon%20Research%20Work-Culture.pdf

    [7] Cyon Research Corporation, ibid, page 5.

    [8] Some have suggested that the future of Construction Documents will be as a query of a Building Information Model. We feel that the Architect's right to determine the views of the building that define the Contract will survive.

    [9] At the time of this writing, this document is available online at: http://revit.autodesk.com/EN/5_0/Documents/TutorialsImperialENU-Letter.pdf

    [10] Ludwig Mies Van Der Rohe (1886-1969)

    [11] At the time of this writing, this document is a white paper, available online at: http://revit.autodesk.com/EN/5_0/Documents/DocumentsEN5_0.htm

    [12] Vitruvius' On Architecture, translated by Henry Wotton, 1624, as The Elements of Architecture

     

     

    Bookmark and Share