Category Archives: Standards

Standards: Process vs. Outcome

07 Wednesday Aug 2013

Posted by in Standards, Thoughts

≈ 1 Comment

One of my (many) projects these days is wrangling our long-standing CAD standards and much-newer BIM standards into a single, unified “Graphics Standards Manual”. As I try to get a grip on this spaghetti bowl of topics, I’ve started to divide them into two categories: process and outcome. You could also call it screen vs. plot. Or, in complete sentences: “How does it act?” vs. “How does it look?”

Today, these two halves of a model or drawing are about equal. I suspect, as we continue to move closer to IPD, the “process” side will begin to prevail. Today, however, I’m more likely to see a QC comment complaining about the symbol representing a kicker than about the fact that it’s a faked-in detail component when it should have been modeled.

This philosophical division also helps categorize standards topics into “CAD”, “BIM”, and “graphics”. The first two are process-based, such as project setup procedures for each system. The last is outcome-based, such as our typical abbreviations and acronyms. Some topics span all three categories, like the information contained in a graphical column schedule. What that schedule looks like is part of Graphics, but getting it there is part of CAD/BIM.

I’m still working on the best way to organize all these discrete yet related topics. My ideal scenario would be a fully-linked searchable database or website. For now, we have OneNote. It’s pretty good, but harder to lock down against inadvertent editing than I would like.

As I keep writing things down, I’ll post the categorization here, but in the meantime, how do you handle unified standards for separate software solutions?

Sure, it looks good. But how’d you do it?

20 Wednesday Feb 2013

Posted by in Standards

≈ 1 Comment

Tags

, , ,

If you’ve been working in CAD or BIM for any length of time, you know there’s ALWAYS more than one way to accomplish whatever it is you’re trying to do. Sometimes it doesn’t matter which method you pick, such as dimensioning an object by selecting it or picking its endpoints (if you’ll excuse me the AutoCAD example). But sometimes it really does matter — especially to the next person who comes along and has to edit your model.

Let’s take beam copes. By default, using the “Apply Coping” tool, they look like this:

CopeDefault

But at our office, we want them to look like this:CopeCorrect

Okay, now it looks right, but…how’d I do that? Off the top of my head, I came up with no fewer than 5 possible methods:

  1. Hide the beam and redraw it with detail lines.
  2. Use a masking region.
  3. Use a detail component.
  4. Use the “opening by face” tool.
  5. Use a void family.

Any of these methods will end up with an image that looks like the one above. But which one is best?

#1 will get you in trouble around here. We don’t hide real objects unless it’s absolutely necessary. If we did hide objects, how would we know when things have changed?

#2 is a little better, but it’s still tedious. You end up fussing with real lines vs. invisible ones, and you’ll probably end up with more shape handles than you really want to deal with.

#3 is the most efficient, if you have a good family set up and don’t need to show the effect of the coping in your 3D model. I’m usually fine with 2D-only coping, unless we’re going to cut a 3D section where showing the coping is important.

#4 and #5 both affect the actual 3D object, which can be handy if you need to show the coping in more than one view. Openings by face are quicker to create than voids, but they only affect one beam at a time. If a void is long enough, though, it could cut through a whole line of framing (after you used “cut geometry” on each beam). I’ve used both of these options; it really does seem to depend on the situation.

So there are pros and cons to each method for showing coped beams in sections. It’s just one scenario where the are multiple ways of creating the same look with vastly different effects on the model.

What do you think? Any options I missed?

(And for the record, in this example I used Opening By Face. But that was only because I’d already applied coping to create the first image…otherwise I’d probably have used a detail component and saved myself a step or two.)

Keeping up with standards

04 Monday Feb 2013

Posted by in Standards

≈ 2 Comments

Tags

, , ,

There’s an old joke in CAD Management circles that the wonderful thing about standards is that there are so many to choose from. (We laugh because it’s true.) For our firm, most of the time these are client-driven standards, which in turn are probably owner-driven. In these cases, we grumble, sigh, and then build templates to automate compliance as much as possible.

But what about internal standards? And, more specifically, what happens when they change?

I’m thinking about Revit families here — other kinds of standards will have to wait for another day.

To answer this problem, I went back to thinking about how we handled it in AutoCAD when a symbol changed or was added. Adding was easy. (“Here’s a new block.”) When we changed something, though, we had to think through how it would affect our projects in-progress. Was it worth updating them with the new block? (Maybe.) Was it worth updating our typical details? (Yes*.)

Taking this into Revit, I think the basics of the process are the same, but the challenge is multiplied due to the vast numbers of families and the various ways of accessing them.

But here’s how I think it can work:

  • If you need to update a family, go ahead and rename it. Don’t try to keep two versions hanging around. (At least not in the active folders. Backups are fine, of course.)
  • If needed, update your template so that new projects will use the new family. (This part’s kind of a no-brainer.)
  • Projects in-progress will continue to use the old family if it’s already been loaded. If you inadvertently load in the the new version, you should probably say “no” when asked, “Do you want to overwrite this family?”
  • If you need the new version in an existing project (and be honest, it’s probably why you updated the family in the first place), rename the existing family as zzOLD-family (or with your prefix/suffix of choice) and then load in the new family.

I’m in favor of the prefix method here because then all the zzOLD families will drop to the bottom of your project browser, where your users won’t be tempted to grab them when creating new instances. It’s also a pretty good visual clue if they do happen to select a superseded family.

Admittedly I haven’t put this into practice officially yet, but I think I’d like to. Am I missing anything?

(Back to the asterisk from above — updating typical details can be a huge chore. It needs to be done, though; otherwise you end up with old symbols perpetuating themselves through new projects. Maybe set aside a day a month for maintenance? I’ll have to think about that.)