Dave writes: "Does it seem to your readers that it's often more efficient to create separate families than try to make one that "flexes" correctly to make all the possible types we need? It seems that way to me at times."
So what do my readers think? Post a reply in a comment and let Dave know.
I do remember an interesting discussion at one of AU's Un-Conferences. A few of us remarked that we were seeing a trend away from trying to create super-families. I can relate to Dave's comment, which seems, to me, like voicing some specific frustration perhaps. I think that it is natural to be inclined toward building very parametric families. As soon as we see what is possible, why not?
However, as fast as some design solutions change a single solution family might get built quicker than the one we make trying to anticipate how it might change. If the family is rendered irrelevant as soon as the design changes then investing a lot of time in making it parametric may not make sense. This is where our intuition and experience make a big difference. These will help us decide when we know enough, are confident enough that it is worth putting the effort in.
Keep in mind that a family can evolve. It can start out simple, singular and then grow into a much more parametric version as the design evolves, settles down. I see designers focus on the big picture and then seconds later fret over the smallest detail. That's the nature of design, back and forth from macro to micro. It's hard to be general and at the same time be highly specific. That's the tension we are dealing with, transitioning to Revit.
9 comments:
I agree with Dave, generally. While it can be good to get a vendor's (well-made) family, there are many days when such a thing is not yet available, so we have to make something that will suffice. Also, we are usually on a time and money budget, so we must be quick about it.
Over here on the MEP side, we will take an hour to make, say, an air handling unit per the 2-D selection drawings from the vendor, add the necessary connectors, then 'load into project'. We will then save it as a stand-alone family, with a useful file name, in a server folder with the vendor's name. This useful name is essential for later re-use, of course, so that someone can grab it for a future project with a similar need, and adjust the family to suit.
We are a 400-person MEP engineering firm, and we ordinarily haven't the time, money, or, frankly, the need to fully paramaterize the families that we create. I'm sure there are cases where a full set of parameters would 'save money in the long run', but by the time that day arrives, the vendor will have changed the product, or he will be making good Revit models that we can download, or Revit itself will have morphed into the next big thing and the new families will not be compatible. Vendors were reluctant to create blocks for iDrop or mvParts because they knew that they would just have to do it all over again when the shareholder winds shifted again at Autodesk ....
As a content creator, I absolutely love it when I can make a one-off model instead of a fully parametric family that is fully customizable. While it's nice to see a family that you can adjust every which way and not break, it takes a substantial amount of time to organize, set up, test, and create. What makes it worse is when certain customizations need to be nested.
Meanwhile, I can do a single model with the exact needs in a small fraction of the time it would take to account for any future change or need. Certain families do need to be more complex and adjustable than others, given its purpose, function, and location (render important vs never visible), but some complexity is a better choice than too much complexity.
There is only so much we can guess at. I've used some super families, and frankly they are just way too complicated for the average user. I like to use smart families that have some flexibility, but not the ultimate flexibility. Window as an example: I have a 2x2 window that has 4 panes of glass and that can be different sizes, then I have a 2x3 window that has 6 panes of glass. I could do a whole bunch of programming to get them into a single window, but having multiple windows is much easier for my users.
I agree, I think in a lot of cases it is more efficient to model a non-parametric family or parameterized just a part of a family. Maybe you know that a elements length will vary so you make it line based or attach the length to a instance parameter. To me this is a less is more approach, less flexibility can be better because it’s easier added the right flexibility when it’s needed.
As Steve mentions designs change and it's hard to anticipate those changes sometime. If you can that's great, you can make the family flexible enough to handle those changes and that’s a big plus. But, project schedule, user experience, and maybe team management can stand in the way anticipating this and making good flexible families.
I like the middle ground. Im MEP, so we can start out with a place holder-type AHU, then as it evolves get more detailed, but having said that. We created template families that align to our schedules, and have a few parameters set, like height, width, and length. Also maybe a preloaded housekeeping pad family with the same built in size parameters. This way there is no remaking basic parameters, but you can start broad, and buckle down as the design "evolves". That has worked thus far without too much pain.
I've only recently gotten into Revit, but was asking myself this exact question relative to room name blocks - in this particular case, we have a need for slightly smaller blocks for some small rooms. Other users have created a whole different family for the smaller rooms names, but I wondered if you could do that as a type instead. Hopefully I can dig into that soon.
Sara, take a close look at the stock room tag. Start a project with the Default.rte (template) and create some walls, add a room. Select the room tag and look at the type selector, you'll see three types, swap them to see what happens.
All one family, three configurations. Select the room tag and click Edit Family to take a closer look at the room tag itself. Check out the labels and the parameters in the Family Types dialog.
I also fall in the middle-of-the-road category. The geek in me wants to make one family do as much as possible, but the little voice inside my head that keeps reminding me how the next deadline is rapidly approaching (or is that my project manager's voice?) wants me to do enough to resolve the problem at hand and move on to the next problem. The latter generally means not trying to anticipate every possible future use for this family firm-wide, and limiting the parametric flexibility to the immediate needs of the project at hand.
Even when I have the luxury of considering needs beyond those of the current task, there are limits to how much I want to put into one family. Our office standard has a fairly large number of door types, and we have a separate family set up for each type. Could we combine all the single, hinged doors into one family? Probably, but then that family would either have a very long list of types to scroll through or more parameters would have to be instance based.
I would also worry about the ability of many users (including me) to effectively edit a very complex "super family" should a condition arise that is not built into the family.
Personally I myself love to create nice well working families everytime I need one. Whether it be a Revit City download I tweak a bit or something from scratch, it doesnt really matter. Recently I have been trying to delve into type catalogs a bit more to see if there is a missed opportunity with them. I am not quite sure of their true power and subsequent true limitations. Seems like if they are as flexible as I think they are we could dramatically shrink the sizes of our families. anyone have any input on this.
I personally like to keep my family list down to a minimum as the search and drop family function in Revit kinda sucks.
Now if I could just get my company to invest in a couple licenses of Family Browser.... =)
Am I dreaming or did Revit use to have a family browser in earlier versions??
Post a Comment