So its been awhile since I've created a post... Architecture is like that, it tends to suck up your time. :)
The good news is that we've done some very interesting things recently. We've written an in house specification for family creation. It is written in the same way as an outline spec for building design and construction. There are numerous "fill in the blanks" where information specific to the family you need can be filled in by the spec writer. In this way we are able to assure a certain level of quality and uniformity for any family created across our 7 office (600+ person) firm. The plain spec is only 4 pages, obviously depending on how much an author writes, it could get much longer. As an accessory to the spec document we've also created an excel table where the spec writer can define all the parameters that they know they want or require, as well as the types to be defined and the settings for each parameter per type. We also expect anyone writing a spec to include sketches & other graphical information to illustrate the intent of the family. We plan to use this specification as a means for having new content created on a contractual basis. That said, already from personal experience in using the spec, it is a great tool to help define and figure out a family before you even put cursor to Revit desktop. :)
Another interesting project we have on-going is matching Revit graphic standards to our 2D CAD standards. Currently our firm has a very thorough 2D CAD standard implemented for both Microstation 2D and AutoCad, the standards are so thorough that we have a complete custom layer/level set, complete custom line styles, and custom line weights, and, on top of all that we get reliable output from both programs that looks alike, even on all the different printers our various offices own, from 8.5" x 11" to 42" B&W plotters!
That said, our custom tools in ACAD & M-station both use a replicated CSV file to define our layer set and the various attributes defined "by layer". This was fine in the 2D CAD world, however we have now introduced a new guest to the party, Revit. Revit is rather unique in the fact that it has two line weight tables (one of which has multiple line weights by scale) and as we all know it has categories and subcategories, which for the purposes of 2D DWG output, must be mapped to various layers. To that end we are going to create a database that essentially allows us to set-up all the necessary translation tables, ie, categories and subcategories to layers, layers line patterns and weights to various categories and subcategories as appropriate, and our custom line weights to Revit line weights. This database will also have the advantage of allowing us to track all of our custom subcategories, which will aid in writing the previously mentioned family specification. We also expect that the new Database will help as we begin to implement both Revit Structural & Systems.
Quite a bit to wrap one's head around, but when attempting to implement a program like Revit in a firm our size, there are a number of challenges that get magnified. I won't even bore you with the issues of attempting to troubleshoot and help someone 400 miles away, as well as simply capturing knowledge and talent, and having it shared and available across the whole firm.
Subscribe to:
Post Comments (Atom)
2 comments:
DMW,
I'm afraid to say that I care not to share the actual spec document at this time. Though I will talk it over with the team. The best thoughts I can give is that once you have at least one or two people who are very comfortable with regards to family creation, that it is merely a matter of breaking down what you expect in a well crafted family. For instance, making sure that reference planes are named, that their "is a reference" setting is changed from the default. There are any number of details related to having a good family; symbolic geometry, sub categories, visibility and level of detail settings, etc... Our outline spec merely provides a vehicle for detailing exactly what we want, so that all of our families meet certain expectations.
With regards to text, our 2D CAD standard is Aerial Narrow. So, we've set-up our defualt project template to use Aerial narrow, it actually matches pretty darn well, even when we link CAD details/drawings into a Revit project for placement on sheets.
This is a fantastic idea! I was probably a few arguments away from coming up with something similar. Teams are always asking for "insert generic family" but cannot define what they actually want. So far, my strategy has been to require drawings with dimensions at the very least and cut sheets if available. The additional issue this solves is that the scope or specifics of the original request change between the time they ask for it and the time you deliver it. Having a document explicitly detailing what is expected helps keep the family maker out of the dog-house. It also forces the person making the request to put some thought into what they really want.
On a larger scale, our firm goes through a similar process for projects when we deal with consultants. The document we're using details what is expected from consultants models and determines who is responsible for what information. The intent is the same but on a larger level!
Starting my family-request spec right away...
Post a Comment