BILT

BILT
Speaker

Wednesday, 29 January 2014

Separating Model and Detail Lines in Revit

Have you ever wanted to select all the detail lines in a view in Revit, without selecting any model lines?  Or to select all (and only) the annotation on a view?

Easy, you might think - until you realise that Revit makes it quite hard to distinguish between some model and detail elements.  Lets try it:

1.  Filter

Select a whole bunch of elements and go to the Selection Filter.  Note that it is inconsistent in how it displays the categories/subcategories:
  • It does not distinguish between model or detail lines, but it does separate out line types
  • It lists "Detail Items" as one category, when in reality they could be filled regions, detail components, repeating details etc.
  • Stairs are listed, and stair components are itemised separately
  • Text Notes are listed but not separated by type (as lines are)
  • etc - the list goes on
It would be so helpful if it distinguished all those things properly and consistently.

2.  View Visibility

Since you cannot separate model/detail lines using the selection filter, you could try the Visibility/Graphics dialog box.  Then you discover some more Revit madness:
  • Some categories are wrongly assigned as model - eg. Detail Items, which are clearly annotation categories as they are view specific
  • Model and detail lines are again all grouped together under Lines in the model tab - wrong!  
  • Even worse, Lines include sub-categories for Area Boundaries and Room Separation lines, which should really be subsets of Areas and Rooms; and these line subcategories don't even behave the same way although they perform similar functions - Area lines are never visible in 3D, while Room separation lines are visible in 3D.
  • Just to add to the confusion, if you go to the Annotation Tab, you'll find a whole bunch of stuff that is certainly not view specific: 
  • Grids, Levels and Reference Planes should most assuredly have their own tab called "Datums"
  • Scope Boxes, Section Boxes, Callouts, Sections, Elevations are all to do with view definitions - and they can all potentially be seen in multiple views (some in 3D too).  What on earth are they all doing under the Annotation tab?  They need a separate tab - or maybe grouped with datums under "Setouts"?
  • Adaptive Points under the Annotation tab - just plain crazy!  And there are some other point types that you can't even control visibility of from this dialog box (eg. divide path/surface), which is endlessly frustrating.
  • For a new user, this stuff is confusing as hell.  Its a mess that is long overdue for a fix-up.
  • And it doesn't even remotely help us with this task.

3.  Select All Instances in View

Well, this just plain doesn't work for detail or model lines, so forget that idea.

4.  Isolate

If you select a detail line and try "Isolate Category" it does at least work - but again it does not distinguish between model and detail lines.  However, it does actually isolate by sub-category for lines (like the selection filter) - possibly useful, but it is yet another inconsistency.

5.  Properties

When you select a line and look at the properties, it is not immediately apparent whether it is a model or detail line.  But if you look carefully there is a discrete little checkbox under the Graphics Heading.  It would be very laborious checking each line by this method.
If you select a mixture of detail and model lines the checkbox is even more discrete - you need to look carefully to see the tick is gray not black

6.  Tooltip

Lets suppose you had a staircase on plan and you wanted to verify if it was a model stair or whether some naughty cad drafter had taken a shortcut by drawing linework.  You could just hover the cursor over the stair lines - it will pop up with a little tooltip.  In this example it tells you the viewname and that it is a detail line;  in the case of a model line or stair it would also give you the workset and category.  You might also be lucky enough to have your eye drawn to this stair by the dodgy looking door opening onto it!!  That should be enough to warn you that it is probably not modeled as a real stair.

7.  Worksets

If your project has worksets enabled then you may find this useful for separation of model and annotation categories.  Because model lines are assigned to a model workset you can hide or isolate them by workset;  Detail lines and all other true annotation always belong to the view workset.  View references (sections, callouts etc) have their own worksets.

You could try the nifty new(ish) Worksharing Display command on the View Control Bar - choose to display by Worksets:
All the model worksets will be displayed by colour;  annotation categories will remain unchanged.  However, the fifth colour (purple*) is too dark to easily distinguish between that and black or gray lines.
Go to the Worksharing Display settings, and change the purple colour to something slightly brighter
 Then it should be easier to visually check where the detail lines are
It might be easier to read if you hide the surface shading by making the view wireframe.

This still does not help you to actually select all those detail lines quickly, so here's one last thing to try:
First, reset the worksharing display to normal.  Then . . . 

8.  Workset Visibility

If you go back to the Visibility/Graphics dialog box, we can get it to do one last trick.  We could turn off all the model elements to leave the annotation visible.   However, you can't just use the neat looking "Show model categories" checkbox at the top left - because the software designers have left us with a chaotic jumble of categories under each tab.
But you can control it another way.  Go to the Worksets tab.
Select all the worksets listed (they are only model worksets, as you cannot select view worksets here)
 Then set their Visibility Settings to "Hide"
Click Ok and you will be left with only detail lines, detail items and text (ie. the dumb annotation).  Warning:  all hosted annotation will not be visible either as they will only display when their host model elements are visible (ie. clever annotation - tags, dimensions).
Now at last you can easily see and select all those dodgy detail lines

9.  Convert

There is a neat little utility that the software designers put into Revit a few years back - it lets you convert selected lines from detail to model and vice versa.
Warning:  If you don't know which type you selected, it just goes ahead and converts them without letting you know which direction.
If you selected a mixture of model and detail lines, it asks you which you want to convert
So now you can easily convert those dodgy stair detail lines into slightly less dodgy stair model lines - at least they will then show up on multiple views.
The next task will be to persuade the person who drew them the error of their ways.  I offer no advice here on that subject, except that there is one tool that could help you - if you have Worksharing Display ON, then the tooltips offer up a little more information.  Use it as you will!
It should be noted that if you need to recreate a new central file by "save as", then all the elements in the model up to that point will have your name listed under "Created by".

[Edit]  

10.  View Model Display

An anonymous commenter has rightly pointed out that I missed the most obvious method:  There is a view property 'Display Model' that allows you to hide the model elements (leaving the detail lines visible);  It also has a Halftone setting.
Part 2 - Click here to see a description of this technique
Part 3 - Using addins to separate elements in selections

Tuesday, 21 January 2014

Revit Stair Landings - Part 2: Modification

In the previous post I talked about creating stair landings in Revit.  Now its time to look at modifying landings, which is very different to the old sketch method (pre-v2013).

Stair landing components can be modified individually but they interact with run components in unexpected ways, so you need to learn the rules as it is not always intuitive. If stair landings have been created by the new sketch method or have been “converted”, then the interaction with runs is more limited.

To modify a landing component you generally need to be in edit stair mode. The exception to this is changing landing properties, which can be accessed by tab-selecting the landing without editing the stair.  There are various methods to modify a landing, each with their own benefits.  There are also some subtle differences between landings in v2013 and v2014 (and later), to be described further on:

 Align Tool

The Align tool will behave differently depending on what you select to align and what the relationship is between linked components.

  • if you align a landing edge, it will most likely move the landing, which in turn will move the associated runs, in effect moving the whole stair
 
  • If you align a run edge, it will move that run. If there is a linked landing, it will also move the edge of the landing, changing its size; it will not move the next run
 

  • NB. Align does not work on the centreline or edges of a curved stair

Move Tool

If you use the Move Tool on a landing (in plan), it will also move the connected run components; on a simple stair with one landing connected to two runs it will effectively move the whole stair;  on a more complex stair the end result depends on the other connections (see later)

Simple Stair



If you want to move just the landing but keep first/last riser locations, you have to use some reverse logic by moving the whole stair then adjust the risers back. 
  • You can use the Move command on the landing component, or select the two runs and move those – either way the effect is the same. 
  • You then have to drag the arrow shape handle at top or bottom of the stair to return the risers to their original location, and Revit will automatically add/remove risers from the connected run


Complex Stair (multiple landings)

If the stair has two or more landings, then the intermediate run will be connected to both landings.  The knock on effect of moving one landing would be to move the free run but not the intermediate run (which is attached to the other landing);  the end result is to change the landing shape or size:
In this example the landing is selected and moved to the right and it automatically changes from rectangular to L-shaped.  The free run at the base of the stair moves, but the intermediate run cannot move - so the landing has to change shape to remain attached.
The rule to understand here is that when a landing is moved in plan its height cannot change thus something else has to give (its shape and/or attached run locations).

Move Run to Adjust Landing Shape

Another "not so intuitive" workflow is to use the Move Tool on an attached run component to adjust the landing shape.  In this example the run is moved in order to add a stagger into the landing so that both runs no longer align.

 
Revit v2014 has additional shape handles on the landing, which allow alternative more intuitive workflows to achieve this (see below).

Move Landing in Section to change stair layout

Stair layouts can be changed in section or elevation too.  The landing height can be changed by moving it up or down to resolve headroom issues - it will snap to the nearest multiple of riser heights, so you don't need to calculate the exact amount to move it by in order to maintain equal risers.  Revit will move the run start/end points to suit.



Shape Handles

For general information on stair shape handles refer to my previous blog post on the topic.  However, that does not cover landing shape handles, which are a little more confusing. In addition, the original v2013 landing shape handle behaviour was changed for v2014.

The landing height can be adjusted by using the arrow shape handles on adjacent runs.  The number of risers on one run will be reduced, while the other is increased, thus changing the start and end locations of the stair without moving the landing in plan:

NB. Do not use the filled dot shape handle at the base of the stair, unless you really want to change the height of the start of the stair.

You can use a side arrow shape handle to make a landing width greater than that set by adjacent runs, but it will not let you make it less.
Once a landing is wider, that offset is sometimes maintained if an adjacent run width is changed - but not always.  It seems unpredictable.

Revit v2013

In v2013, landing shape handles are fairly limited in what can be achieved.  On a rectangular half landing (U-shaped stair) there are 4 shape-handles.  
If you want to stagger the runs where they meet the landing, it seems natural to select the landing and try to adjust it using the shape handle where the landing joins the runs. It won’t let you drag the handle towards the runs, only away from them. But this actually gives a different result - it cuts a notch and it moves the outside of the landing and to maintain its  depth (although it may be a desirable outcome in some situations).  To achieve a stagger in the landing we must move one of the stair runs towards the left (described previously).


Landing Width/Depth

Modifying adjacent run widths will affect the aligned landing width.  Landing sides will continue to align with runs unless you over-ride that using the landing side shape handles.
In v2013 it may also affect the depth too, but the rules are tricky:  changing a run width will only affect the landing below the run, not above it.

The rules seem random until you test it systematically as shown below:

Revit v2014 Shape-Handles

In v2014, landing shape handles have been improved, but at the same time the automatic control of landing depth has been broken - this is something you need to watch out for.  Additional shape-handles are available between each run and adjoining landing.  This allows you to put a stagger into a rectangular landing more intuitively by dragging the landing shape handle (rather than relying on moving a run).

 
The shape handle in the stair well works similar to v2013 in allowing you to put a recess cutout into the landing.  However, in v2014 it will not maintain the landing depth - but it does give a warning message that the "depth is less than run width".  This warning is triggered by Revit comparing the landing depth with the smallest actual width of either attached run, not the minimum run width set in the stair type properties (actual width can be made smaller than the minimum required).
Fortunately the landing depth can be corrected with temporary dimensions or the outer shape handle.  NB. the inside shape handle will not snap to any increments or give a temporary dimension, so you need to put in a reference plane to snap to before correcting the landing depth.

Landing Width/Depth

Modifying adjacent run widths in v2014 will only affect the landing width but not the depth.  This may be logical if you make one run wider, but if you make both/all runs wider you would want the landing depth to match - but it won't, so you have to manually alter all landings, meaning it is only too easy to get a landing depth that is smaller than the narrowest run. The outside line of the landing will only change if the outside shape-handle is explicitly moved.

Landing Properties

Landing heights can be changed in the properties dialog box - you need only type in an approximate value and Revit will correct it to the nearest multiple of riser heights.  This will not move the landing in plan, so the end result will be that adjacent runs will alter to accommodate the new landing height.
Landings do not have Width or Depth instance properties, so you can only adjust those dimensions by:
  • Change the adjacent run widths;
  • Move adjacent runs;
  • Use the shape handles; 
  • Temporary landing depth dimension (v2014 only)
  • Convert to sketch (not advisable).

Temporary Dimensions

  • Landings do not have any temporary dimensions when selected in v2013.
  • Landings do have landing depth temporary dimensions when selected in v2014.
  • Spot dimensions can be placed on landings in plan and section/elevation, but they cannot be used to adjust landing heights

Convert to Sketch

Automatic landings can be converted to sketch landings so that you can modify the plan shape to something that is not possible to create using automatic landing features.  Automatic landings can form a wide variety of shapes, but cannot:
  • Have rounded corners
  • Have notches cut out of outside corners (only in stairwell)
Convert to Sketch should be the last resort, and should be avoided where possible.  This is irreversible - the only way to make a landing revert to automatic behaviour is to delete and place a new one, which would remove any attached elements, modifications or annotation.
Once a landing is converted to a sketch:
  • It will never have shape handles;
  • It will never adjust in plan when adjacent runs are moved;  
  • it will cause error messages requiring landings and runs to unjoin if an attached run is forced to move away from the landing;
  • It will allow height adjustments

Tips and Tricks

  • If you want to change the landing width it is better to change the adjacent run widths to control it automatically (unless you don’t want them to align).
  • In Revit v2014 it allows the landing extent/depth to be smaller than the narrowest run width. To fix this you can use the shape handles on its outer edge or the temporary dimension.
  • in v2013, landings do not have handles where it meets a run, so you can’t use shape handles there - to stagger the risers for example; you have to MOVE a whole run to achieve that. 
  • Be careful with the Move command on landings because it will most likely affect adjacent runs, and may end up moving the whole stair.
  • If you have created a top landing, any changes to the adjoining run below it may not be able to flow through to the top landing (as it cannot change in plan) and it may give you a message about "stairs and landing cannot be joined".
  • The quickest way to change a stair layout might be to change a landing height property - this can be done without even editing the stair