Stair Section Detail Level in Revit

Here is yet another problem with Revit Stairs that really needs to be fixed by Autodesk:  

The view 'Detail Level' display in section is not consistent between walls, floors and stairs (not to mention ramps!):

View Detail Level

When a view is set to Medium or Fine detail level, sections of most categories display the correct materials:

When the View detail level is set to 'Coarse', the cut hatching display of some elements is overridden by the Type properties 'Coarse Scale Fill Pattern'

This capability is available only for certain categories - meaning that the display of stairs is pretty hopeless at Coarse scale

 

Workarounds

What to do about this?  There are several possible ways to resolve this lack in Revit, but none is very good!

Visibility Graphics

You can over-ride the cut pattern of stairs - but this requires several steps (excuse the pun) on top of just changing one View Detail Level setting:

Due to the fiddly nature of changing this in the view (similar settings may need to be applied to other categories), you would certainly need to include this as part of a View Template - so it could be applied or removed at the flick of a switch.

Filters

You could also try using a View Filter, as it could potentially be applied to multiple categories

This has an advantage in that it is more "discoverable" than searching through all the category overrides - unless you have a gazillion filters applied!

Another advantage in Revit 2021 is the ability to "Enable" or "Disable" the filter without losing the override settings - a very useful new enhancement for Filters.

Downsides

The View Detail Level is very easy to switch on/off - and it affects all categories that have the built-in Coarse Scale override capability.  If you set the view back to Medium, the 'by category' cut pattern overrides get left behind - so you would need another operation to remove those (hence the need to use View Templates).

Another problem with the Visibility Graphics workarounds is what happens when you choose anything other than black solid fill as your hatching override:

If you make it grey . . .

 

The Stairs will show the joint lines between different materials - you may or may not want this, but it is clearly different behaviour to the Coarse Detail Level control that hides the material join lines and treats it as one material, for a nice clean look.

Of course, this is not helped by the inability to join walls/floors to Stairs !!  You still get the joint lines between those.  Refer to Stair Joint Lines

The Worst Workaround

Filled Regions are extremely useful for patching up Revit's inadequacies, but they are not popular with BIM & Model Managers because they cause so many other problems as soon as a model changes.

Filled Regions allow you to make the hatching look exactly how you want, because they allow some of their edges to be "Invisible Lines" - thus they can appear to join with adjacent "real' cut hatching.

Filled regions are placed per view, so if you have multiple sections cutting through the same or similar parts of the model you may end up with many filled regions.

One possible method to manage that problem is to include them in 'Detail Groups' - but they are also problematic to manage, not to mention a major shortcoming of really slowing down your Revit model if you have too many of them.

Conclusion

Whichever workaround you use the most important thing to do is to follow company standard procedures - and be consistent.  Agree with your workmates on which dodgy workaround to use, and stick to it.  This will make it so much easier to come back to make changes when the model is updated.

Levels By Scope Box Hidden in Section Elevation

Lost your Levels in Revit?

Here is some weird Revit behaviour that you may need to know about Scope Boxes and Level/Grid visibility - to help you find invisible Levels:

Example: Multistorey Building with podium and  two towers 

A common situation in Revit occurs when you have two sets of levels, that do not align - perhaps you have a building with two towers that have different floor to floor heights.

NB. In this example:

• All levels are displayed with 3D extents (so it ignores the effects of 2D view cropping of levels). 
• Same behaviour applies to grids as levels, but only levels are shown here.

Level Visibility

• From one direction the levels look good in elevation or section

South Elevation - Levels

•  Looking from the side, the levels might overlap each other (depending on the view extents) - a mess where you can see both sets of tower levels mixed together.

Side Elevation - all levels visible

• To make the side elevations and cross-sections look better, you need to adjust the view extents -

• Typically you should set 'Far Clipping' to 'Clip without line' and set the offset so that it extends into the levels that you want to see, but not the distant ones

South Elevation - Far Clipping through levels

Section - Far Clipping through levels

•  If the clipping is too short you won't see the levels

South Elevation - Far Clipping too short

Section - Far Clipping too short

• If the far clipping is too long, and extends through both sets of levels, they will both be displayed (usually - see Weird Stuff below)
• If Far Clipping is set to 'No Clip', you will see all the levels

No Clip

Far Clipping Options

South Elevation - No Far Clipping

Section - No Far Clipping

• Interestingly, when you set a section or elevation to 'No Far Clip', you can actually see levels behind the view.  In the example below, the section line is between the towers.

South Elevation - Section between towers; No Far Clipping

Section between towers - No Far Clipping

Where Are My Levels?

If some (or all) of your Revit building levels are not showing up in a section or elevation view, you can use the above 'No Clip' behaviour to your advantage:

• Check all the usual visibility settings, such as Category On; no filters; Not hidden in view etc.

• Set the view extents to 'No Clip'
• Set the view to 'No Cropping', so that you can see the 3D extents of all levels

If the levels are still not visible, it may be due this next quirk of Revit behaviour:

Weird Scope Box Properties

• If any of the levels (or grids) have a scope box applied to them, not only will the scope box crop their extents, it will also prevent levels from showing in a section or elevation unless the cutting plane of the section/elevation actually intersects the level.
• This means that 'No Far Clipping' has no effect on visibility

To resolve this:

• you have to set the Scope Box properties back to 'None'

• The level extents will not change, but they will no longer be controlled or locked by a scope box.
  
• You have to make a decision about which is the worst of two evils!

You may also want to check the 3D extents of levels in a 3D view by turning the Level category on in Visibility Graphics.  Refer to 3D Levels

Another Scope Box Quirk

 Scope Box visibility behaves differently to Levels and Grids:

• A scope box will always be visible in a section or elevation view only when the view cutting plane actually intersects the scope box.
• You cannot make distant scope boxes visible by changing the section/elevation Far Clipping property to 'No Clip' - unlike Levels, it makes no difference.

More info about Scope Boxes: 

• Scope Boxes Greyed out
• Changing the Height of Radial Grids
• Quick Fix Wonky Rotated Plan Views

Internal Origin Visible in All Views in Revit 2020.2

For anyone thinking of upgrading to Revit 2020.2, here is some advice to avoid a bit of pain in the upgrade process:



Autodesk have introduced a new feature in the point release Revit 2020 SP2 that should really require a database change (but does not do so):

Expose internal point of origin

This is a marker that indicates the true origin of the project (internal coordinates 0,0,0), which may be different to the 'Project Base Point' if that has been moved.

It is indicated by a 2 or 3 axis  X,Y,Z symbol in red, green and blue

• The symbol cannot be selected;
• It will cause you problems during 'Zoom to Fit' if it is outside your building;
• It also shows up outside your view crop boundary - more Zoom issues and irritation;

 

• It can be hidden/shown in Visibility Graphics, as a subcategory of Site.

This is a useful feature, as we sometimes need to find out where that point is - however, it will initially add confusion to anyone who does not already understand the coordinate system in Revit (as there will now be a third origin point to deal with).  

The real problem with it is 'Visibility' and in the upgrade process that you make to get to 2020.2:

Upgrade Process

• If you upgrade from Revit 2018 (or 2019) directly to 2020.2, the internal origin will be OFF by default in all views (which is good).

• If you upgrade the project to 2020 or 2020.1 then subsequently open it in v2020.2, the internal origin will be ON in all views - this is a total pain. Even though it won't plot, it is annoying. 
• Even worse - it will be visible in all newly created views, including 3D Iso and perspectives.

The reasons for this:

• The upgrade process from 2018/2019 to 2020 (or 2020.1) does not know about the new feature so it does nothing to prepare for it.  
• There is no upgrade process from 2020.1 to 2020.2, so the software cannot do anything to the files and view settings. 
• The upgrade process from 2018/2019 to 2020.2 does have a component built in that hides the new subcategory in all views.

Autodesk really should have put this new feature in a major annual release, and not in a point release, as it will create a lot of extra work for users.

Advice

So, my advice is to go straight from v2018 or v2019 to 2020.2 - then you won't have an issue.
i.e. make sure you have SP2 installed on all 2020 computers before upgrading any projects to any version of 2020.

Interestingly, I created a new project in 2020.2 from the Autodesk supplied 2020 (Aus) project template and the internal project base points are OFF in all views.  I was not expecting that to happen as the template was pre-2020.2.  There must be something in the software that deals with this issue when creating new projects?

Too Late

If it is too late, and you already have some projects in 2020 or 2020.1, then you need to turn off the subcategory in all those views . . . . .

• It is not so bad in View Templates, but its annoying
• Individual views is a total pain - see below for automation
• Create view templates that will hide the subcategory in all NEW views (especially 3D);  edit the Type properties of any 3D view and set the view template to be applied as a one off to all new 3D views.

Automation

One option is to track down some code to hide the new subcategory in all views - either Dynamo or an API.

There is also an issue with the paper clip being removed from the Project Base Point symbol. 
For more information on this, refer to Revit OpEd Blog

Steve Stafford of Op Ed has also tracked down various Dynamo options for turning off the internal origin:

NB. I have not tested any of these Dynamo scripts, but others have (with comments):
OpEd Dynamo Graph
OpEd Dynamo Redux
Follow Up with a later Dynamo script

Autodesk really ought to fix this properly, but it seems that it is not possible for them to put anything into a point release, as that does not actually upgrade the project files.  And if it did, what would happen when you opened an upgraded file in 2020 or 2020.1?

[Edit.  John Pierson of Parallax Team has very generously given us a free tool for hiding all those pesky internal origin symbols in a project in 2020.2.  Its on the Autodesk App Store:
Internal Origin Hide-ifier

Thanks John for picking up after  Adsk's dog! ]

Scope Box View Property Greyed Out in Revit

Here is a little software trick to catch out the unwary Revit user:

There are some situations where the Scope Box property of a view is greyed out - so you cannot assign a Scope Box to the view.

The answer may be to do with the Crop Boundary - and it may not be obvious, especially if the crop boundary is hidden.

To track this down:

• Make the Crop Boundary visible
• It may or may not be apparent that the  Crop Boundary has been edited

•  Or it may not be obvious - if only a minor edit is done to the boundary

• Select the crop boundary

 

•  If it has been cropped, the Ribbon will show the 'Reset Crop' icon available

• Another way to check if it has been cropped is to look for the shape-handles on the crop boundary - extra dots indicate segments in a boundary

• Click on 'Reset Crop' - the edits to the boundary will be removed (along with the extra shape-handles)

• The Scope Box property will now be available for use.

•  The 'Reset Crop' icon will now be greyed out - indicating the crop is no longer edited.

This behaviour is quite logical once you know what is going on - but it can be confusing when you first encounter it.  Of course you do not want people to accidentally remove a Crop Boundary just by applying Scope Boxes - without realising what they have done.

Architectural Ceiling Plan Hidden Categories in Revit

A while back, someone asked me why some model elements remained visible when they turned off ALL Model categories in Visibility Graphics.

The list of categories that show on the Visibility/Graphic dialog box varies depending on the Discipline filters applied to the dialog box. If you are preparing a set of architectural reflected ceiling plans, you may want to show lights, sprinklers, security etc. However, not all relevant categories are shown if you only have ‘architecture’ ticked.

Watch out for hidden categories in this situation. Each user may have different discipline filters applied on their computer (it is per user in Revit, not per view).

This means that some MEP categories may not be shown in the Visibility/Graphic list – therefore the user will not be able to show/hide or override those categories.

If the user has only the Architecture discipline showing, then clicks on ‘All’, it does not include the hidden MEP categories, including:

• Data devices
• Fire Alarm devices
• Nurse Call Devices
• Security Devices
• Sprinklers
• Telephone Devices

I have encountered situations where frustrated users have turned off all categories, and wondered why the sprinklers remain on.  For this reason I recommend that architects should consider using only  the following categories for Ceiling and Electrical fixtures in their libraries - for architectural Revit models:

• Electrical fixtures
• Lighting Fixtures
• Mechanical Equipment
• Specialty Equipment 

Architecture Discipline Only

However, for multi-disciplinary Revit models you probably need to stick with the correct categories - obviously MEP engineers should use the correct categories for their models, because they have specific behaviour that is important to them.  In the case of separate, linked MEP models, the services engineers may be modelling their own fixtures, and using the architectral model just for coordinating ceiling fixture locations.

All Disciplines

For architects working in multi-disciplinary models, where you do need to use the correct categories for all fixtures, then you need to educate your staff about changing the filter list to show all relevant disciplines. 

What a pity that we don't have all the categories that we need - Signage for example (amongst many others missing).  However we do have at least one redundant category: Roads - we'd like to be able to use it but we have no tools to model roads with.

Glazed Doors in Window and Door Schedules in Revit

I started out writing this blog post about the behaviour of subcategories in nested families.  On closer investigation, the weird behaviour I intended documenting was not as I had thought - still a bit strange but not quite worthy of a post all to itself.  So I have changed tack and turned it into a discussion about how to get a glazed door family to appear in both door and window schedules.  Many experienced Revit users should already know this, but for those who do not, read on.

Schedules and Categories

Typically door and window schedules are created separately as single category schedules. Multi-category schedules have too many limitations to make them work efficiently for this task. A door or a window is usually either one of those categories, and therefore it can only appear in one of the schedules.  What if you have a window assembly that contains a glazed door? or a sliding glass door, which you want to show in the window schedule (because it is glazing), but also in the door schedule (because it hosts door hardware)?  This common requirement seems problematic in Revit, but there is a way around it . . .

Workaround:

Shared Nested Family

When a nested family is 'Shared', it behaves differently to the parent family in terms of subcategories.
For example, you might have a window parent family, that contains just a frame (or a fixed glass side panel).  Inside this could be a nested sliding door family.  Providing the door family is set to 'Shared', then it can have its subcategories independently controlled (by View Visibility) in the project;  it can also be individually selected, tagged and scheduled (as a door); the parent family can be tagged and scheduled as a window.

Nested Door Family Category Settings

Nested Door Family Subcategory

Parent Window Family

Parent Family Category

Parent Family Subcategories

Nested Door Family in Parent Family

Tagging and Schedules

Standard door and window families are normally tagged separately according to category

Once placed in a project, the combined door/window family can be tagged for either category:

Tag the whole family for the window category tag

Tab select the nested door family to tag it

Scheduling

• The combined window/door family will appear in a window schedule. 
• The Nested door family will appear in a door schedule

Category Visibility

This example shows a single swing door nested family in a window family (with fixed window panels either side).  In the project, both door and window categories/subcategories affect the sub-element display:

All Categories On

Door Panel Subcategory Off

Window Category Off - Door Category On

Non-shared Nested Family Categories

When a normal 'non-shared' family of one category is nested inside another family of a different category, it behaves as if it is part of the parent family in terms of categories.

Unshared Family Settings

In the parent family (in Family Editor), the nested family still shows its category when selected

Non-Shared Nested Door Family in Window Parent Family

When loaded into a project the whole window can be selected, but not the nested door family. 

Window family with non-shared nested door - in project

Changing the visibility of the Door category does not affect the nested door.

Door Category Off, Window Category Visible

Hiding the Window category, (while the door category is visible) hides the whole family, including the nested door

Door Category Visible, Window Category Off

This behaviour is as expected.

Weird Revit Behaviour:

Non-Shared Nested Families

However, if the nested families have elements of a specific subcategory (of the Nested family category - door) the element's visibility is still controlled by that nested family subcategory.  This does not really make sense if the nested family is not shared.

Door Panel Subcategory Off

This can be very confusing, as you have no way of knowing what category the nested family is, without editing the parent family.  As far as the user is concerned, the family is a window - since you cannot select the nested door in the project, the user will not be aware that it even has a nested family, let alone that a subcategory that has nothing to do with windows will still affect it.