We sent out 3 families specified using our new outline spec to a contract firm. We recieved their first pass at creating the families, and additional questions/clarifications. In general we are happy with what we have received. There are a couple of instance where they either did not carefully read the specification, ignored it, or mis-understood. There were several more instances however where we either did not clearly write our spec, or we had contradictory information, or we assumed that certain assumptions would be made, and didn't give as much detail as was needed. Particular areas that we missed on; neglecting to specify the name of the .rfa file (we felt kinda foolish about this :) ), not giving enough examples regarding a naming convention, so they literally adopted the one example, failure to explain that rendering material parameters should be attached to some geometry, and perhaps biggest of all, we realized that even though we make mention of sub categories, and our master sub category list, we need to include a part in the outline spec that deals specifically with sub categories, and how and when they should be assinged to objects or pieces of an object.
In general the modeling, and parametrics were acceptable in the families. One interesting thing though, with regards to one of the specified families they took an approach completely opposite of how I created the same family. In general, we feel that my method for creating the same family allows for better performance, and more flexibility than their method. So we are going to attempt to convey that we don't want to be in the posistion of telling them exactly how to model a particular family, however there are "best practices" that we need them to take into consideration when creating a family. This is particulary tough, as there is not really a way to specify something like that, without laying out exactly how you would like to have a particular family created. We are still waiting for the results of the third family we specified, which was a dynamic parking ramp that includes transistions. This a complex family from the standpoint of some of the parametrics and formula writing, so we are curious to see what they come up with.
Wednesday, May 31, 2006
Wednesday, May 24, 2006
Revit Standardization: Family Specs
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.
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.
Labels:
Families,
Family Creation,
Specifications,
Standards
Subscribe to:
Posts (Atom)