I am delinquent in getting this post... posted, but it has been an insanely busy time! A discussion was started on AUGI about custom content, and after a somewhat heated debate was had over the successes and/or failures of Revit Content sites like Seek, RevitCity, etc... A few of us were of the opinion that the failure isnt really on that of the content sites, but that of the content standardizers: They arent end users, and theyre not using the software to get the work out the door. How CAN they know what needs to be in the standards?
Autodesk has taken some initiative posting the Revit Model Content Style Guide, but many of us disagree on if it is helpful or not. It often recommends things that arent a value to the PROJECT, in the spirit of helping REVIT.
I would cut and paste my thoughts on the subject, but its quite lengthy. You can read them in this post, specifically addressing the Content Style Guide.
So what IS a successful standard? Well, in my VERY humble opinion: It needs to account for the most complex situations. Otherwise, when those situations DO come up, its a free for all. The beautiful thing about a complex standard that covers all bases, is it STILL works for a more conservative project. So... Whats critical in that standard? Well, here is my hope:
Im going to go category by category, and post what we are using at Beck, as "our standard." Then im hoping others will do the same. By Vegas time or a bit after, im hoping to have something we can share with the 'Desk. If- at any point in this discussion- it becomes useful, ill post our content as samples, along with the Shared Parameters files.
For the first Category, im going to start with Doors... As theyre often the most complex.
Admittedly, at Beck we like our Revit models a bit more Complex than- perhaps- they need to be. This is a diagram of one of our doors, and the Parameters they have.
This includes a series of Offset parameters and if/then statements, allowing the Door to stay "hosted" to the wall, but push itself off of the wall. This is primarily because we model our walls as multiple walls, so the "Revit Wall" cannot drive the size of the door frame in ALL cases.
Discounting that as something that is not necessary in a standard (as its just our desire), lets look at the rest:
Width: Some doors have one panel, some have two. Theyre not always equal. This NEEDS to be planned on. We have two independant Panel Widths. We have other functionality, to automatically make them EQ, but thats all fluff. i think we cal all agree we need to Panel Widths, STANDARD.
Panel TYPES: This starts the debate about Nesting. Though it may be arrogant to assume everyone works like us, ill go on the limb and say this NEEDS to be standard. Anyone whos done a job with the OOTB doors, knows how exponential the number of doors to edit becomes, with Panels arent nested.
FRAME Types: Always a gray area, since some people make the "Frame" families the Door family itself. But, having worked with them as seperate Nested Families, i have to say i think its great. Ill put up a vote for them being Nested. What are your thoughts? This also starts to delve in to Frame Dimensions, and WHERE should they be controlled?
But, if i WERE to desire Manufacturer Built Content, my personal thoughts are it should be like this:
Door parameters(parent family):
Panel 1 Width (Length)
Panel 1 Type (Family Type: Door)
Panel 1 Finish (Material)
Panel 2 Width (Length)
Panel 2 Type (Family Type: Door)
Panel 2 Finish (Material)
Overall Opening Width (Length- formula driven)
Panel Height (Length)
Panel Thickness (Length)
Panel Floor Clearance (Length)
Frame Type (Family Type: Door)
Frame Profile Jamb Width (Length) [for cutting the opening out wider]
Frame Profile Head Height (Length) [for cutting the opening out taller]
Door Panels (shared):
Panel Width (Length) [tied to the Panel widths in the door]
Panel Height (Length) [tied to the Panel height in the door]
Panel Finish (Length) [tied to the Panel Finishes]
Door Frames
Opening Width (Length) [tied to the Overall Opening Width]
Opening Height (Length) [Tied to Panel Height]
Okay, so ours have a bit more than that. These are also just thye basics. Of course the Frames will have more, as will the panels, for variations IN the panel. But these are (i8mvho) what need to SCHEDULE, and be made from a STANDARD shared Parameters File. But im out of time at the current moment. What are your thoughts on the above?
11 comments:
Hmmmm...
Aaron, how about as you post the blog entries, we upload the associated content on BIMexpert and point people that way on your blog?
Yeah... We could.... I just need to get the time to do it, hehe.
Aaron, I'm very interested in where your going with this since I had to hack something together for our offcie - it's still a work in progress. I'm glad your taking the initiative.
What about sidelight material and transom material? Hardware?
Posting your door schedule would be easy to see what "needs" to be scheduled.
Chris-
As soon as im in the office and have a spare moment, ill post it. Your question bring sup another of the interesting parts:
Our standard doesnt include S-lights and Transoms, since we include them in the definition of the Nested/Shared Frame Family.
We see this as a huge plus, since a Specific frame manufacturer could create just their frames with sidelights, etc. It also makes editing frames, sidelight sizes, transom sizes, something that DOESNT mean having to edit hundreds of door types, which is why we love it. F00 is a standard frame, F02 is an egress frame, F20-25 have sidelights one side, F30-35 have them on both, F40-45 have transoms, F50-50 have transoms and Sidelights varying, etc. (Thats just an example)
What do you think?
I only commented about sidelites and transoms as I'm now starting to schedule them, unless your firm does something different?
If the majority of your parameters are instance base, how do you document the different frame elevation configurations? A designer could go crazy...
They cant go any crazier than normal. :)
The variations in Frame Types is what makes the differences in Sidelights and Transoms. If they want different sizes, they can make new Frame types. Then they get elevated and dimensioned in our Frame Type Elevations. We dont include the dimensions of the Sidelights and Transoms in the schedule, because the schedule calls out which Frame type they have, which dimensions the Lights.
I agree there needs to be a standard on how content needs to be created. The entity that will really need this consistancy is the owner. If an owner has a couple of firms do work for them, the doors for instance will not all work together as they have all been built in differnt manners.
I also agree the use of nested panels and other methods will help reduce the number of families to maintain and upgrade. We created our HM Hinged doors in a substantially less number of families, if we would have unnested families there may have been 8 times more.
the question begs to be asked...
in an effort to push a more "standardized" system (and you make great arguments for such with the example of your doors) does it help to share such pre-created content?
While I understand the hesitation seeing as it's something you did and sharing it nets no profit, would it help the overall community of users to have a basepoint like this?
Doors are currently the issue at hand for our firm, and there's debate between using OOTB content and making our own.
There really is no debate, unless its a time investment or a monetary/budgetary issue. The Out of the Box doors are junk, and you will find some things regarding archtiectural documentation that they- flat out- wont do. Can you work with them? Sure. But you wont get Door schedules, Door widths, door panels, etc, to work the way you want.
Regarding sharing doors: The entire 2011 version of our Door Library is available for download on various sites. We have outdated versions on www.BIMExpert.com, i just havent updated them in a while. The 2011 downloads are floating around RFO.
The thing is, you wont be able to use them. They are tailored to exactly how we want them to work at our office, and every office is different (hence the problem). But deconstructing them is a good way to learn to build your own.
I *personally* am all for sharing content (to an extent), but it becomes a maintenance and support issue, as well. If a *real* standard could be agreed upon, i'll bet sharing would be much less of an issue, since the doors would all basically be the same.
I would be curious to hear your thoughts about whether you think the door paramaters that feed into the schedule (material, finish, frame type, panel type) should be TYPE parameters or INSTANCE parameters. I've worked at different offices that do this different ways. Is one better than the other?
Aimee- thanks for the question. This is something that varies firm to firm. I would say "officially" there isn't a right or wrong answer, but I can give you my setup, as follows:
1. Panel type and frame type: instance, as this is basically selecting what happens at THIS particular instance of the door.
2. Panel sizes: Instance. Sounds weird, but it's a much better way of working. Much less restrictive.
3. Materials: this one is interesting. We give each panel a MATERIAL and a FINISH. Material is a type property of the PANEL. Thus, it doesn't schedule directly. But the panel being called P00WD tells you it's material. The panel FINISH is instance, nested in to the parent door family, allowing interior designers to do their thing, and to render. (do you really wan a door type for each finish or paint color???)
Post a Comment