In New Zealand, much of the process of documenting the design and construction of a building project is still, in concept, a “paper-based” process. We use the language of 2D working drawings and 3D illustrations to communicate design intent and explain the requirements for the delivery of the project, and gain consent to carry out the work. PDF files are substituted for paper, and the general arrangement drawings, and some of the detailing, are derived from 3D models. Much of the detailing is not derived from the model, either drawn independently or imported from external sources.
There are two types of detailing views currently supported in Revit:
- The detail view
- The detail view is derived directly from the model as a linked view and augmented with detail item components and linework to provide the final view.
- The drafting view.
- The drafting view is independent of the model and is drawn as a drafting exercise or imported from external sources.
Over the fifteen years or so that I have used Revit, I have been frustrated with the way Revit handles the “Drafting View” class of views. The sharing of this class of detail is problematic in that the details cannot be easily linked across projects. We do use detail groups when sharing the same content across different drafting views within the same project, but this approach does not help the use of these views across different projects.
Also, the “Insert File View” approach to transferring this class of view across projects is slow and cumbersome. Libraries of drafting views must be stored in “container” .rvt project files. Managing dividual details requires an individual .rvt project file for each detail. These individual detail containers are around ten times the size of a comparable CAD file. In an AutoCAD environment, such details, and indeed any blocked object, may be refreshed directly from a central library source through tool palettes. Simple, direct and easy.
An Example
I have a set of ten Revit project files that all share the same drafting detail, “Pattern Book”. We copy the drafting views around the ten project files. If any detail requires updating, all ten project files have to be opened and updated.
This process is time-consuming and difficult to manage compared to using an approach similar to an AutoCAD-based xref structure or tool palette refresh system similar to the one described above. If the drafting details were linked, the detail would only be updated once and reflected across all ten project files automatically, and I could trust that all ten projects would be using the same detail sets.
General Arrangement drawings derived from Revit BIM models work well. However, a significant portion of the detailing is still 2d drawn, either based on callouts from the BIM model and augmented with detail item components and line work or as 2D drawn drafting views. Drafting views are discreet from the project, so there is no reason to have them “locked” into project files as system content. I find that they are basically “unsharable” from a usability perspective.
In my opinion, this is a major conceptual failing of the current design of Revit. A solution maybe is to place drafting details in a family type that can be shared, linked, remapped and easily reused across various projects. Having drafting views in family-type .rfa files would go some way in addressing this issue.
