Placing a Tag Outside its Host

Seven times out of ten, you place a tag and you want it to be near that item that you are tagging, be it a door, room, window, whatever.  The tag wants to be near the host, otherwise, what’s the point?  You might as well be placing tags by tossing them in the air and letting them land wherever, like as much confetti.

Two times out of ten, you tag something and there just isn’t enough room for that tag to live there.  So, you enable a leader from that tag.  Excellent.  A nice clean arrow indicating precisely to what item that tag is referring.

Then comes the oddball.  That one time out ten (probably even more rare) that you want a live tag to pull info, AND you don’t want it near the object you’re tagging, AND you don’t want a leader.  The out-of-the-box tags in Revit don’t want you to feel like you can accomdate this.  As soon as you move a tag too far from an item, Revit tells you that you MUST activate leaders and have that connection back to the object in question.

We ran into this situation… and I won’t keep you in suspense, we found a way around it.

Our firm standards for interior elevations indicate that we show the room number JUST BELOW the actual elevation.  We wanted to keep the tag “live” so it was pulling the number from the room, in case the room number changed.  “Dumb” tags are SO un-Revit.  But, every time we dropped the tag down, it asked to turn on the leader, which we didn’t want to do.  How to fix? 

The question really was, how does Revit know if a tag is inside or near the item that’s being tagged anyway?  Opening up the tag itself gave us our first clue.  The only thing in there is lines, text and… some reference planes.  Quickly checking the reference planes indicated that these planes were of the “origin defining” type.  You probably see where I’m going with this.

Turns out, Revit doesn’t care at all where the “graphics” of the tag is at all.  The origin point of the tag is how Revit determines if a tag is inside or near an object.

Solution?  Create a new type that had the graphics droppped down below the origin.  As long as that invisible origin was inside the room, the tag was below the elevation, and it didn’t need a leader line.

This can obviously be applied to any tag type, with even more clever placement being defined by parameters and types.  It doesn’t happen often, but it’s nice to know that you can keep the “automagic” updating and not lose out to the last 10%.

Issues With Ceilings and DGNs

This is really bad.  As in the real definition of “bad”.  Try this out…

Create a room with a ceiling (or not even the room) in Revit.

Export the RCP view to a Microstation file.

Open the file in Microstation.

Notice the difference?  And I’m not talking about the black background or other colors.

Yeah.  The GRID IS WRONG.  I’m certainly not the first online to post about this, but it is so annoying and frankly so amazingly dangerous that I wanted to put something up.  I haven’t tested with other model patterns, but I bet they would be screwed up as well.

I have categorize this as a “Gripe” but I feel like I need to make an entirely new category for it.  This is beyond insane.  As designers trying to work with consultants, the basic foundation is that the lines we see will be in the same place when we export that file.  I can deal with fonts, I can manage colors, I can tolerate layers.  But wrong lines?  That opens me up to liability issues. 

That’s actionable.

That’s so bad.

And it needs to be fixed now.

Ceilings Need a Facelift

I’ve had it up to here (about 8′ above finish floor – HA!) with ceilings.

There are a couple things in Revit that feel like they need an overhaul, and I would like to nominate ceilings and their related functions.

First off – The structure of the ceilings for ACT.  Why a hatch?  Why can the grid not be some kind of smart element.  “That’s too much modeling overhead,” I hear someone in the backrow say.  Well, here is my response to that: first, sometimes it’s just nice to see the grids in section.  Revit Structure allows floors to add metal decks (why not roofs – ahem), and that’s pretty cool.  Seems like some of that modeling love could stretch over to ceilings on the Revit Architecture side.

Second, and this is my big grief, we sometimes find ourselves needing to do a demo ceiling plan.  Don’t ask, but sometimes we need it.  So we have had to create a new ceiling type for demo ACT ceilings.  On top of that, we have had to make a new hatch style(s) with dashed lines indicating a demo’ed grid.  It has to be a model hatch, so it will be 2×2 or 2×4, so the demo lines show different at different scale.  I hate that.  My architects have to demo a ceiling AND THEN CHANGE THE CEILING TYPE, which is something we told them never to do.

My other beef with the ceilings has to do with their interactions with room objects.  So, there’s a toggle on a ceiling instance for room bounding, right?  And it controls the height of the room when you calculate volume.  But only when you calculate volume, which they tell you not to do too often.  Why can’t the room just look for the ceiling on placement?  Why does the room have no parameter showing me its height, even when I do turn on calculate volume?  It only shows UNBOUNDED HEIGHT, which is the height I originally gave it.  Our RCP tag has room number and ceiling height.  So, it’s two tags… a room tag with number and a ceiling tag with height.  That’s stupid.  My room should be able to see how tall it is based on the ceiling height and register that.

I was hoping that 2010 might address some of these concerns, but the NDA for the Revit Beta keeps me from telling you anything about it.  So, hypothetically, I couldn’t say “No, it doesn’t look like ceilings have gotten any attention at all,” or something like that.

Small beef?  Yeah.  Silly?  Maybe.  But every time I have to explain it to someone, it takes the “I” out of BIM.