Wednesday, April 11, 2007

Does a method to the madness count?

I can recall fondly, back in my days working with AutoCAD, i was pretty confident (arrogant) that i had a faster method of drawing than some of the people i worked with. I used "fence trim" while they clicked individual lines, i would array while they would offset and offset, id do this vs theyd do that... And in the end, the end result was always the same. We had all drawn the same door, the same wall, the same window.

So it didnt matter, that i used P-line, and they made 4 lines, then used p-line>join. We both ended up with the same p-line.

Now, in an object oriented environment, I'm left wondering how we bridge the gap with the fact that the "how" might matter now. Objects have information, behavioral tendencies, scheduling criteria.... Objects have implications.

So, when a particular element is in need of modeling, what repercussions lie in wait for a team of three, where one person elects for an out of place family, one person elects for an in place family, and one person elects for a combination of wall sweep and line based component, with some drafted lines in elevation?

I'm discovering that it is imperative that the work be fairly close to uniform, for reasons of efficiency as well as performance. If all three members on my imaginary team are modeling in different fashions, then I've bestowed ANOTHER task on them come revision time: Autopsy. Assuming Wall-Sweep-with-line-based-and-detail-lines guy is on vacation when the design changes, what happens when out-of-place-family guy goes to change it and is dissatisfied with the methodology?

How much time will be spent deconstructing and analyzing (to figure out) and then redoing the same work? How many times are the families getting duplicated, copied, edited, that aren't adding value to the end result?

Ive been thinking about this one for awhile, for a variety of reasons:

"Office standard" families, and families in projects/ or project specific families.
Generic content families, vs families that have been modeled from actual Product Cut Sheets.
"Wall Types and wall types naming conventions"

These are a few areas that I've seen some redundancy tendencies, just in the general work flow. Ive got some ideas on it, hopefully i can get some images and some thoughts up later tonight...

TBC... ...

This is the first example that comes to find, but (at the risk of being long winded) there is something worth mentioning: There are plenty of ways of achieving the goal. While i contend here and forward that there SHOULD be a uniform way (for a teams benefit), I'm not saying my way is best. Ive conferred with a lot of great modelers, and a lot disagree with how and what I've done. But, for this discussion, these examples will suit fine.

Its a simple building, with some Lights, some EIFS reveals, some Quoins, and some Columns. How do we model it though? Here are the issues i see redundancy in:

The reveals: I tend to make them as a Wall Hosted family, for a few reasons. Maybe they're all horizontal at first, and then are wall sweeps. The client changes spacing, and we adjust. Again. Another adjust. Then he turns them in about a radius, as pictured. Now i have to make a family anyway. Its a toughie, but for the situations like this facade, where there is a Canopy, a raised Band, and the reveals, i try to make them all as one family, for ease of editing. I know a lot of people hate hosted families, but i love them, and use them everywhere. What ill do though, is nest a non hosted family, IN the hosted family. Ive found it makes constraining easier, and gives me a safety net if (for whatever reason) i need a non hosted variant later.

The methodology here, is what i think becomes an issue. Before i showed my colleagues on my team how i made the Reveals, there was an uncertainty when they had to be edited. Surely, someone else found a way: Making the entire wall (solids and voids) as in-place elements. Now, they wouldn't schedule as walls, and they weren't hatched in section. But therein lies the issue: given the opportunity, 5 people may find 5 solutions. How do we combat this? I don't suggest i have an answer, but rather... I'm aspiring to find one...


Well, were Object Based, right? Is that ALWAYS a good thing? One issue I've been struggling with, is certifying the integrity of such objects, as they pertain to our Model. Certainly, with items like Wall lamps, the measurements of the geometry may not be pressing, save for a mounting height. In this case, the client wanted to see them in a rendering. that's neither here nor there. BUT, its another reason i love Nesting families. From the manufacturer, the lamp has several mounting possibilities... Wall mounted, floor mounted... I like the nesting, because i can get a count of how many I've used.
Here's another one pertaining to this. Have any of you run in to this as well? The columns in the first image... They are GFRC column enclosures spec'd out from a cut sheet. We have them in various sizes, but when i made them originally (my fault), i simply called them "GFRC -24inch" for the family name. So no one had any idea if it was a generic placeholder (for schematic design), or if it was an actual Spec'd piece from a specific manufacturer. later in the project, someone else needed a 24" GFRC in a different model (spinoff project on same campus) and they went to remodel it from the cutsheet... Because they weren't sure that mine was off the cutsheet to begin with.
While it seems like a communication nightmare, i suspect this happens a good bit on large projects with large teams, and large numbers of families. Do any of you use a naming convention to keep track of such a thing? I'm proposing one currently, for our use. I haven't got the nomenclature firmed up yet, but something like this:
To signify: GEN = Generic Content, Schematic Design, No integrity in actual tolerances.
SPC = Manufacturer and model selected, item modeled for Docs (dimensions verified)
CON = Modeled elements that aren't items (like EIFS reveals made in to families...)
Its a toughie. Especially considering the the amount of "I" in your BIM, you may never need an SPC level family. But, when Project Managers come to ask if we can verify that Steel sizes fit in the GFRC's, I'm of the opinion it should be in there.
So i wonder, if the methods to the madness need to all be laid out on the conference room table before the mice hit the pads. It makes for interesting coffee maker conversation with 6 people modeling, that's for sure? Thoughts? Fill me in, i KNOW some of you run in to it too... :)