Poor Interior Designers

I don’t mean the title of this post sarcastically, I do mean it in relation to good old Revit.

I recently had the pleasure to sit down with our Interior Designers group for an Autodesk webinar titled “Revit Architecture and Interior Design”.  Well, it was a pleasure to sit with them, not so much the presentation.

It wasn’t the presenter, it was completely the material, or lack thereof.  We have been working hard to fully integrate our designers with the rest of the project team on our Revit models.  Unfortunately, it is only halfway (quarterway?) there.  We wanted to see the tools for easy floor pattern design!  We wanted to see the commitment from manufacturer’s to get consistent and proper families into Revit!  We wanted to see better integration of room object finish information and the actual model!

We didn’t see these things.  They don’t exist yet.

We saw rendering (nice!), Autodesk Seek (spotty) and integration with Inventor (what?!)

I have a feeling that the Interior Designer is not on the marketshare target for Autodesk yet.  The in house solutions we are putting together are piecemeal at best.  We get frustrated that they cannot fully take advantage of the parametric engine that is Revit’s bread and butter.  We cross our fingers that this will be remedied in future releases.

Warning – Floor May Be Closer Than It Appears

So, I stumbled across an odd one today.  Apparently, floors don’t like to follow the rules when it comes to view ranges.

Let’s say you have a floor at Level 1, offset 0′-0″.  Your view range bottom is set at the same height.  I always assumed that since the range was touching the floor, that’s why I saw it.

Boy, was I wrong.

It turns out that you have to get your view range at least 4′ above the floor for it not to appear in a view.

What the what?!  It’s like there is an invisible cube that is 4′ tall sitting on top of a floor.

I did a quick Google and found one reference to it on another blog.  That write-up states that it is “confusing” and “poorly documented”.  I used some different words, but not any that I will type here, in case my mom is reading this.  Hi, mom!

Looks like this “feature” made its way through to 2010 also, at least in my beta it did.

In my opinion this is insane and an amazingly poor idea that needs to be removed ASAP.  When someone sets their view range, they expect that view range to actually work (gasp – crazy idea).  Not work for some items, but not work except for an arbitrary distance with other items.  Dumb dumb dumb.

So watch out for your floors.  They may show up where you don’t expect them to.

Mansard Roof Madness

We have found ourselves needing to create far more mansard roofs in our Revit model than I think is healthy.  The economic downturn has led a lot of our clients to go down the addition and renovation road more than we are used to.  So we find ourselves in the “happy” position of having to model a lot of existing work of questionable architectural value.

But I am not here to argue the validity of aesthetics from decades ago!  I am confident that sometime in the nearish future some future blogger will be looking back at our work and make the same slightly disgusted face.

We tried really hard to use the built in roof tool in Revit to get a mansard roof, but the extent of the slope is just too extreme in most cases.  We now utilize the create roof by face.

We create a mass that consists of a blend sweep, which very easily lets you create the shape of the roof overall.  Then we create roof by face.  This is done face by face.  So, don’t select all the faces then try to finish.  Sometimes Revit gets mad at this and tells you “no”.  But you can definitely go in and change each face one at a time, then join the geometry when you’re done.

The biggest hurdle is learning the massing tools, but once this is overcome, this is a very easy and effective way of getting these roofs done.

Referencing Sheet and View Issues

So, you’ve added some sections and slapped them on a sheet.  Cool.  Good old Revit gets the detail number and referring sheet populated automatically.  It’s one of those magical things that computers should have been doing for years.

If you have a client that requires the good old 3 part bubble, then you find yourself with having to show the detail number, the sheet it’s on and the referring sheet in the bubble.  Some callouts, being datum elements (section cuts, elevations, levels) can actually show up on more than one sheet.  When you put a view on a sheet, how does Revit determine the “referencing sheet” and “referencing detail”?

Simply put, it looks through your sheets.  The first sheet it finds that has the callout mark is the referencing sheet.  And that’s what gets put into your three part bubble.

Now, let’s suppose… you have an A2.1 sheet that is going to have your floor plan on, but you haven’t put it there yet.  You also have an A9.1 reflected ceiling plan sheet and you haveput a view on.  I have a wall section that I am placing on an A5.1 sheet.  So I drag the view on there, and since the callout shows the “referencing sheet” info, it fills that in with A9.1.  Well, that’s not the view I wanted.  I wanted A2.1.  What is one to do?

Well, sometimes you just drag the view onto the sheet.  Drag the plan onto A2.1 and magically the referencing sheet of the section on A5.1 updates.  POOF!  Your work is done and Revit read your mind!

Sadly, sometimes that doesn’t work, especially if the sheet that you drag the desired plan onto is after the already placed sheet.  Then what do you do?

You jump through some hoops.  But let’s try to understand what appearsto be Revit’s behaviors for the hoops.

• When you place a view on a sheet, Revit looks through your sheets to see what the referencing sheet should be.  It also does this when you adjust the scope of your view.
• Revit will only call a view/sheet  referencing if the callout is actively in a view, i.e. not hidden.

OK, nice simple (theoretical) rules.  I say theoretical, because I have no possible way of knowing that the code works this way.  This is all based on observation.  The following are the hoops:

Find all the views that have a callout to the section (or elevation or whatever that you need to change the bubble)

Hide in view the callout in each view EXCEPT for the one that you want to be the referencing sheet

Activate the section (or elevation or whatever) and change the crop region ever so slightly.  Just drag it a little teeny bit.  You’ll see the bubble update as Revit finds the only view on which you have the callout not hidden

Go back to the views from Hoop 2 and unhide the callouts.  Oddly, this will NOT update the section (or elevation or whatever)

This will keep the referencing sheet set, unless you change the crop region for that view, then you have to repeat.  And if you need to show multiple referencing sheets, pull out some text as the monstrous last 10% rears its ugly head one more time.

Ideally, the referencing sheet parameter would be a drop-down, and you could select what view/sheet you want, and possibly even build tags that can generate from a list of multiple views/sheets.  I’m certainly not the first to hope for such a feature, and I wager I won’t be the last.

Commitees Suck for Deploying Software

I know the drill.  Hey look!  New software!  Let’s set up a committee!  Let’s get everyone’s input!  Let’s hold hands and sing folk songs and this software will magically deploy itself when butterflies flit around and run the installation files on everyone’s PC.

No no no.

As architects, we like design charettes.  We like to get together and hash out unique solutions to design issues.  That’s great.  You can come up with excellent resolutions to some big problems.  And quite often, that’s close to the most social some of us ever get.

That shared workforces mentality can spill over into other facets of our business.  Let me tell you, deploying software isn’t designing a building.

Aside from the charette mentality, to maintain good relationships in a firm, we like to make sure everyone feels like their opinion has been heard and counts.

Deploying software isn’t like ordering pizza, either.

I’ve been through a couple major software deployments now, and each time, the committee gets used less and less.  Why?

Because committees suck for deploying software.

Now, I’m not talking the lone wolf here.  I don’t endorse the idea that one person should be making all these decisions.  Sometimes that works, with Revit, it won’t.  But a committee is the wrong approach.  Get three people, each more opinionated than the next.  That’s your core group of decision makers for a Revit migration.

Why is a smaller group better?

Standards changes– I said in an earlier post that I was using our Revit deployment as a jumping off point for enforcing our standards fresh.  That does not mean that we used Revit as a reason to rewrite our entire standards book.  On the contrary, we used our old standards as a jumping off point.  We were going to be making enough changes with just the software without having to change everything.  Often, our hand would be forced to look at and change the standard because of how Revit functions (leaders at the end of text, I’m looking at you).  Usually the smaller team would be quickly in agreement.  A large committee would require way too much time on conversation and evaluation of the issue.

Education – Some issues are new and hard to understand.  It’s far easier to train three people on a complicated issue to make a good decision than it is to educate a roomful.

Passionate ideas – sometimes an individual in the smaller group would be VERY passionate about an issue.  The others would give way, understanding that their pet issue might come up soon and there would be some mutual back scratching.  With a larger group, there is a lot more heel digging in, just to dig in heels and feel like you have to be forceful on each issue so you’re heard.

You might be right – in some situations, you’re just right.  It doesn’t matter what others say, you know you’re right.  Convincing only two people is a lot easier than a roomful.

You might be wrong – in some situations, you’re just wrong.  You think you’re right, but you’re not.  It’s much easier to get shown the error of your ways by a small personal group than by a large room of people.

Camaraderie– a small group makes it easier to feel like a team.  By the nature of being in your group you will get each other’s back, because it’s just the three of you.  The larger groups can easily break down into smaller factions and then you just have group A arguing with group B, sometimes outside of the meeting and that is just plain bad.

Try to avoid the committee for your Revit deployment.  Find one or two competent and appropriate individuals to work through this important task with.  It will go much faster with a smaller group.

And, if someone complains, you change it.  But in my experience, the amount of complaints and changes to newly deployed software has no correlation to the size of your deployment team.

Sketchup Users – The Steep Learning Curve

Change is hard.  I totally understand that.

Sketchup is easy to start using.  Check.

Revit isn’t easy to master.  I get that, too.

Now that we have the baseline set, we can start.

In a previous post, I talked about how evil Sketchup is to the documentation process, and ultimately a disconnect that it creates can impact the design process as well.  As we are moving past our pilot projects, we are introducing the concept of BIM and Revit to the population of the firm at large.  Some of the folks are 100% on board with the concept.  They know there are going to be hiccups and a rough time learning the software, but they are ready to get their hands dirty and come along for the ride.

Now (and here’s where things took me for a loop) on the other side, I have the Sketchup lovers.  They are not ready to move along.  The extreme cases find folks who find multiple excuses to convince themselves that modelling in Revit is bad and completely subpar compared to Sketchup.  Don’t worry about the built-in rendering engine in Revit.  Ignore the fact that you have started your documentation.  Pay no attention to your engineers who can start their analysis based on the Revit model.  You can’t do any of these with vanilla Sketchup.  You can start tacking on add-ons, but they are iffy, thrown together and sometimes expensive.  On the other hand, this is precisely what Revit is made for.

I mentioned that the Sketchup hold-outs threw me for a loop.  I had convinced myself that the 20 year ACAD experts would be my biggest fight.  That hasn’t been the case at all.  In most situations, while they lament losing some key features and functions, they have been on board and are quite excited about making the change.  As one of them put it, “This is what computers should have been doing for the last 10 years.”

So, what to do about our Sketchup folks?

Right now, there isn’t much I’m doing.  I am putting my time and energy into the people who “get it”.  I am whole-heartedly convinced that once the learning curve is crossed, the models created in Revit will be superior in so many ways to the ones in Sketchup.  And the projects will be better coordinated.  And the rainbows and unicorns will return to the golden fields and it will rain chocolate!

Seriously, there isn’t much I can do.  I can’t twist these people’s arms.  That would accomplish nothing.  I am getting the people who are along for the ride better training and support.  We are working hard to prove all these theories.  And then I am hoping peer pressure will do the job of converting the die hards for me.  They need to be willing to take the time to learn the tools, and I cannot push people into willingness.

If that doesn’t work, I get out my BIM Stick.

Why I Hate Sketchup

One of our biggest fights with our Revit deployment has got to be with the die hard Sketchup users.

I absolutely understand that Sketchup is easy and doing Revit properly is… not as easy. I get that, I totally do. And the really good Sketchup users, when they finish a model, everyone oohs and ahhs, because it looks so good and it’s so amazing. Then why is Sketchup a bad thing?

If you are reading this, you know part of the answer already.

Sketchup is 100% outside of the documentation process for most firms. Sketchup Master has spent all this time creating this elaborate beautiful model in Sketchup. Now let’s waste some time rebuilding the entire thing in Revit so we can actually put out a set of construction document, which is ultimately what we do. I find it interesting how, on a macro level, this issue with Sketchup reflects exactly the same issue that BIM as a whole process is trying to work past. In the “rainbows and unicorns” world of BIM, the passing of the model from designer to contractor to owner is an attempt to not lose valuable knowledge and information that has been put into that model through the process. The Sketchup to Revit shift is the exact same loss of information. It is a waste of time that is unnecessary.

I would submit another reason Skethchup is bad, bordering on evil. It is imaginary. Now, before you start yelling, I know you can make Revit do some pretty amazingly fake things. Things that completely defy the laws of physics and gravity. But if you use the tool correctly, Revit has checks in there to try to help you along the way and not design something that defies the laws of time and space. Sketchup is nothing but fantasy design. Hopefully the designer has enough experience and knowledge to be able to avoid the pitfalls of building a completely imaginary model, but this isn’t always the case. Sketchup makes it very easy to design something that simply cannot be built. And the owner loves it and it’s gonna be on the cover of some grand architectural review magazine! Except that it’s entirely fiction, and when you Revit guy starts duplicating the model in Revit (which is a waste of time – see above) he or she finds this discrepancy with reality and has to spend more time discussing a solution with the Sketchup designer to find a solution.

Sketchup has a place. That place is the first five minutes of predesign, schematic design or whatever you might want to call it. That’s it. The word “sketch” is in the name for a reason.

This is one of my big soapbox items. I could rant for much longer, but frankly this blog post has gotten too long. I will post again soon where I discuss what I have found with some Sketchup snobs users and how we are trying to deal with them.

Walls Have Tops Too

We have settled on never ever ever leaving the top constraint for walls to be “unconnected”.  Even if they are short, like partitions for cubicles or something, we still connect them to the level they are on and then offset them to the proper height.  Why would I be such a wall top constraint fascist?

Engineers.

Isn’t it always that way?

Seriously, they need the tops of the walls to be constrained to something.  For most of the walls.  So, it’s just plain good habit to get into to always pay attention to the tops of the walls.  Or the top of everything for that matter.  Remember, this isn’t CADD anymore.

“Model it right and your documents will follow.”  I think I read that on a fortune cookie once.

DWF Creation and More NDA Fun!

One of my biggest beefs with the current 3d export of DWFs is that you can only export a single view.  The ideal DWF exporting from Revit would allow you to create “channels” of different 3d views to export into a single DWF file.  You send the DWF to the not-so-Revit-capable folks on your team and they switch from “channel” to “channel” to look over the latest design issues.  Currently, in 2009 (the version, not the year), that is not possible.

I have mentioned already that I am under a nice NDA embargo for the 2010 beta – maybe, I haven’t read the stupid thing entirely because I cannot find a copy of it.  Well, I didn’t mention it outright, but come on…  This isn’t CSI here.  Anyway, I am not at liberty to discuss, since yes, features change blah blah blah, but man wouldn’t it be awesome if in 2010 (the version, not the year) you could export multiple 3d views into one DWF to allow “channels”?

Yes.  That would be awesome.  I do wonder if that might happen.  Hmmm…

It would be unfortunate if while creating those “channels” (or bookmarks, maybe) it would not create some way to maintain a “home” for the view.  So if, hypothetically, you switched to a bookmark view, rotated, but could not then somehow get back to the default view.  Wouldn’t that be a shame?

Yes.  That would be a shame.  In theory, I suppose, one could simply close and re-open the DWF, but that’s no fun.  The HOME button should, hypothetically, be tied to the initial bookmarked view.

It’s nice to have these hypothetical conversations, isn’t it?

I have not fully embraced DWFs in our firm, but I do believe that 2010 (again, version, not the year) might be when I make the switch.  I have always liked the file format, especially when compared to PDFs (which seem to HATE large format docs) but the software for DWF has not been up to snuff.  I think it might be there now.

Need For Better Documentation

So, there is a drop down under View Properties for DISCIPLINE.

Here it is!

I have NEVER been able to find proper and complete documentation about what gets turned on and off in your view when you change this.  We are learning by trial and error, but why oh why is there no list simply indicating what each of these shows.

Do a Google search on it and you’ll find people getting confused why their walls aren’t showing up, or why the hidden lines in ductwork suddenly goes away.

If aynone has a list, please point me to it.  Otherwise I’ll continue mentally documenting things that disappear when we notice them.