Wednesday, December 31, 2008

Elevation Tag Not Visible

Another quirkiness in Revit.

Here is a simple project, with a cropped view. Two of the elevation tags are missing.

image

When I uncrop the view, the elevation tag show up like:

image

The elevation tags themselves are within the crop boundary. When I select the triangle of the elevation tag, Revit shows the elevation cut line and extent that are lying outside the crop boundary like:

image

Ironically, this happens irrespective of the annotation crop boundary, for eg.:

image

Also, if the Elevation cut plane extends beyond the annotation crop, but the no problem – Revit still shows it.

image

The Lesson:

The elevation tag will show as long as its cut plane cuts through the view crop boundary. (this is the same as other views) The cutline itself is not affected by the annotation crop boundary. (But the elevation tag is affected by the annotation crop boundary)

One has to move the elevation cut plane so that it passes through the view boundary to make the elevation tag visible.

Wednesday, December 24, 2008

Copy Paste Ceilings

Revit allows you to copy and paste ceilings onto a different floor. If both the floors are identical, Revit even maintains the associativity of the hatch boundaries with the walls.

Here is the First floor RCP:

image

In the second floor, the highlighted wall is moved.

image

When the ceilings get copied and pasted, their boundaries dont get altered. However, any ceiling boundary that is aligned with the edge of a wall is associated with it. Moving these walls automatically redefine the ceilings:

image

Moving the wall that is not aligned with the ceiling boundary, does not change the ceiling boundary.

image

However, if the ceiling is edited and the lonely boundary is moved to the edge of the wall, image

the boundary becomes associated again. (we dont even have to lock the boundary!)

image

This is a great improvement in RAC 2009 from the previous versions, where some ceilings would just get deleted even if we flip the wall!

Tuesday, December 9, 2008

click and drag

If you click and drag some objects in Revit, Revit moves the object. This is the default behavior. However if you uncheck the 'Press + Drag' option in the option bar,

image

Revit expects you to select an object first and then move it with a click + drag. This is useful at times when some objects may be moved a little bit by accident by unsteady hands!

Even though this looks like a temporary option, changing this option gets saved in Revit.ini file and sets it for all projects, and for all users in that machine. The follwing lines are added in REVIT.INI

[Selection]
AllowPressAndDrag=0

May be this option should be made a temporary - session only - option and a separate option added in the Settings menu > Options dialog box.

Friday, November 7, 2008

deleting views deletes details along

In continuation to yesterday's blog,

If a view is deleted, Revit gives a warned like this sometimes:

image

Revit basically lists all the callout views that were created in this deleted view. For eg. when you create a callout view in a view called 'xyz', Revit assigns the view 'xyz' as the callout view's parent. And when the parent view gets deleted, the callout view is also get deleted.

image

If you dont want this to happen, you can change the Parent View parameter to none in the callout view's property.

image

Changing this value automatically changes the Far clip settings to 'independent' and the 'Show in' parameter to 'intersecting views'

image

Now deleting the parent view will not delete these callouts.

(just to irritate you, now, if you changed the value of the 'show in' parameter to "none" then the callout tag wont be visible in any views...!)

That brings us back to the best practices: It is always good to create callouts from the Primary view or in just one dedicated view, which you might never have to delete.

Thursday, November 6, 2008

Dependent Views and callout tags

I wrote sometime back about dependent views.

Here is another quirk.

It was my understanding that all the annotation objects are synced among all the dependent views and its Primary view. (This rule does not apply to "Element Hide".) The idea was that you could add annotation in any view, and as long as the annotation crop does not crop it, the annotation will be visible in other views.

When we create a new callout view from one of the dependent views, the callout tag is not visible in other dependent views and in the primary view. That's a bummer.

However, if you change the value of the "Show In" parameter in the view property to "Intersecting views" from "Parent View only" like

image

then the callout tag shows up in other views.

Ironically, this works only for the callout view type 'Detail'. If the callout view type is 'Floor Plan', this 'show in' parameter is not available. You cannot convert a Floor Plan view type to a Detail type too.

Any other view type created, like elevation, sections, etc. are visible in all relevant views. They don't have this affliction.

Also, if you create any view type (including callouts) in the Primary view, those will be visible in all relevant views. Looks like the best practice is to create any necessary view in the primary view only.