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

How Do You Solve a Problem Like Ma Railings?

Have you ever encountered a problem with out-of-control railings in Revit?  OK, so maybe the structure shown above is not a haywire railing, and was meant to be like that, but most Revit users have struggled with trying to model railings as they should be.

How Do You Solve a Problem Like Ma Railings (in Revit)?  *

* with apologies to Richard Rodgers for misappropriating his song title (How Do You Solve a Problem Like Maria? from the Sound of Music, By Rodgers and Hammerstein) - not to be confused with Richard Rogers (no d), the architect who designed many famous buildings, such as the Pompidou Centre in Paris (with Renzo Piano) and the Lloyds Building in London.

Richard Rogers surely did not struggle with trying to model railings in Revit, as those buildings were designed long before the advent of such software.  These days we certainly do struggle with the software - Revit has been around for almost 20 years and it still it does not enable us to model Railings the way we want them (except for the most simple handrail).  There are many problems with the railing tool in Revit, some of which have been documented on this blog - see the list below.  Over the years, we have benefitted from several minor improvements to the railing tool - for which we are very grateful.  However, there is one fundamental problem that has not been resolved - and that is the inability to control the location of individual balusters.

Baluster Placement - a Fundamental Flaw

The railing sample file shows some relatively complex looking examples - but these are just straight runs on the level.  As soon as you try to use them on stairs, things start going wrong with the baluster placement.

This example is done using two alternating balusters - one is just a post, while the other is glass with fixings.  The glass baluster is very good at adjusting the angle of its top and base (if you create the family properly). 

 

When it comes to spacing, it is pretty hopeless:  you get gaps whenever there is a break in the pattern.

Standard railing with glass balusters

There are some limited controls within the baluster placement type properties, but no single combination of settings will ever work on the whole stair railing.

Spreading the pattern to fit does resolve some issues, sometimes. . . .

Changing the 'Break-Pattern' property to 'Never' can have some weird results

Reverting the pattern to 'Centred' does not fix it either - you may end up with panels across a change in angle, where the panel is not trimmed properly.

Workarounds

There are a number of ways that people get around these problems, but none of them is satisfactory:

1.  You can try using 'Handrail Supports' to represent balusters, but that has at least two problems:

• Handrail supports do not respond to changes in angle of the stair, so you need to build that in as a user control that has to be manually set every time
• Handrail supports can be unpinned and then moved (or changed to another type), but the moving process is very tricky - see Moving Handrail Supports
  It is also possible to very easily lose the positions by accidentally resetting the railing.

2.  Model the glass as a continuous rail element, use balusters and/or handrail supports to represent the fixings and vertical joints in the glass.  More on that another time.

3.  Model the railing 'in-place'.  This is a really bad idea as it screws up the subcategories, visibility etc;  And worse still, it does not update when the stair changes

4.  Just model a Top Rail / Handrail (with no balusters), which shows up in plan.  Document the railing in 2D as drafting views or as detail elements on stair sections.  This is a terrible solution (very un-Revit-like), but it can save huge amounts of modelling time - so it is done quite commonly in the industry.  Of course, it can lead to errors on site . . . .

Railing Fixes

If we had the ability to control the baluster placement in much the same way that curtain walls operate, it would help resolve this fundamental flaw in the railing tool;  this would require the ability to include variable width panels too.  Of course there need to be many other minor fixes in addition to that. 

On the Autodesk Revit Roadmap, Railings were flagged as 'fixed', a couple of years ago, on the basis of a number of minor enhancements.  Clearly it is nowhere near being fixed - see this request on 'Revit Ideas'  Railing Overhaul - Resolution of Limitations - from Chris Price (Mr Spot).

Weird Railing Stuff Blogs

Over the last few years I have posted many blog articles on the many weird quirks of using Revit to model Railings.  Some articles just document the inconsistencies and strange behaviour - just so you know what is going on; other articles offer some workarounds and ground-rules that might help you along:

• (Old style) Multi-storey Railings - Method 1:  Virtual upper levels - "Multistory Top Level"
• (Old style) Multi-storey Railings - Method 2:  Modelled upper levels  - "Railings with Warnings"
• Railings - Top Rail Properties
• Weird Railing Stuff - part 1 - Top Rail Transitions
  
• Weird Railing Stuff - part 2 - Railing Extents  
• Weird Railing Stuff - part 3 - Railing Sketch Offsets & Transitions
• Weird Railing Stuff - part 4 - Rail Termination Visibility
• Weird Railing Stuff - part 5 - Rail Extension Length
• Weird Railing Stuff - part 6 - Subcategory Over-rides 
• Handrail Supports:
• Weird Railing Stuff - part 7 - Support Spacing
• Weird Railing Stuff - part 7a - Support Spacing Postscript
• Weird Railing Stuff - part 8 - Moving Handrail Supports  
• Weird Railing Stuff - part 9 - Handrail Supports on Multistorey Stairs (Revit v2018+)
  
• Railing Properties:
• Weird Railing Stuff - part 10 - Split Railings
• Weird Railing Stuff - part 11 - Rail  Heights
• Weird Railing Stuff - part 12 - Top vs Handrail Terminology
• Weird Railing Stuff - part 13 - Handrail Support Family Types
• Weird Railing Stuff - part 14 - Railing Baluster Height Top Offset
• Weird Railing Stuff - part 15 - Railing  Lateral Offsets
• Weird Railing Stuff - part 16 - Rail Hand Clearance Property

Revit Railing Enhancement Requests

Autodesk  have a 'Revit Ideas' website that allows you to vote for enhancement requests.  I have compiled a list of stair/railing related ideas - please, all of you vote for some of these requests - if you don't vote, Autodesk will continue to consider them as fixed.

Revit Ideas Wishlist Voting

Autodesk created the 'Revit Ideas Wishlist' a while back - yes I know it is flawed and has a lot of rubbish on it.  However, I know that the Revit Product Managers do actually look at it and monitor the votes.  It is not the only thing that decides what goes into future Revit upgrades but it contributes to the discussion - so I like to support it, in particular the sensible ideas that are posted on it.

I do believe that we should mainly be voting for things to be done to the core software that cannot be done by API, Dynamo or Add-ins - as those things can be done quickly by others (or yourselves).

Here are some of the better ones that I think should be voted up (including some that I have posted):

Please go to the Revit Ideas forum and vote for any of these ideas that you agree with:

Model Stability (& Pins)

Allow us to change 2D extents of pinned sections - just like we can for grids and levels.  Then we could leave those sections pinned all the time and not risk losing attached annotation.

Persistent Pins - pins that reinstate themselves after you have modified the element once

Parameters

#1 wish regarding parameters is to allow Shared Parameters in Key Schedules  - this would unlock so much potential in Revit, and the API just can't get in there to solve it.

There are several outstanding Global parameter requirements:

The first is oh so simple, but would be a huge deal for us:
Enable global parameters to associate to Floor ‘Height Offset from Level’ system property

Enable global parameters to associate to Array Numbers

Enable creation of an Area Reporting Parameter for use in Global Parameters

For more detail  refer to Global Parameter wishes

Stairs & Railings

There are so many things that need to be fixed on stairs and railings, that I have created a list of requests just for Stairs and Railings.

There are a couple of basic ones that just need to be done to improve stair arrows - not much more than bug fixes:

• fix the broken Copy & Paste function for stair path arrows.
• Tag All Untagged - Stair Path Arrows

 

Families

Are you intensely irritated by the default setting for face-based family placement being 'Place on Vertical Face'?  I think that 99+% of users would like it to be changed (not to mention BIM managers who have to deal with confused users not understanding why they can't place ceiling fittings).
Vote her to  make the default 'Place on Face'

 

Form Creation

Creating forms in the Conceptual Massing Environment is fraught with problems - some of them could be alleviated by the following two capabilities:

Control profile order during form creation

Select Path during form creation

There are oh so many more things that need to be fixed in Revit - but since Autodesk concentrate on such a few, we need to target which ones would genuinely benefit the most people.  And we shouldn't ask Autodesk to spend time on things that can be done by some other means (API, Dynamo etc).

Have a look at the latest updates to the Autodesk Revit development roadmap to see what is planned or has been recently delivered.

New in Revit 2019 - Levels in 3D Views

One of the new features in Revit 2019 is the ability to see Levels in 3D views.

Personally I don't like this enhancement!  Yes, I know that occasionally someone might have valid reasons to see a level in 3D, but I don't think it is worth the pain it will inevitably cause around the world over the next few years!
I can foresee levels being accidentally moved, copied and having their model extents inadvertently changed on a regular basis.

Reasons why I don't like it:

Cropping View Extents vs Model Extents

• The grip handles for levels in a 3D view are typically model grip handles (a circle), not view grip handles (a dot).  It is not possible to adjust just the 2D view extents when levels are  uncropped in the view - so any changes you make to the levels will affect the model extents and therefore many other views. 

• When I say 'uncropped levels' in a 3D view, I don't mean uncropped by the 'View Crop Region' because that has no particular relevance to levels in 3D - they just get partially hidden like all other elements at the crop boundary.  This is quite different behaviour to a section or elevation view where they would independently extend beyond the view crop boundary.  This behaviour in 3D is not unexpected or unwelcome as rotating a 3D view could cause havoc if they did extend past view crop regions.

There are ways to crop levels in 3D views, and to adjust view extents, but its a whole lot more complex than doing so in a section/elevation view:

Section Box

• If you apply a section box to a 3D view then it will also crop levels, in a similar way as it does in a section/elevation view.  But not the same!
• The levels will automatically be cropped to the section box, plus a default extension past the crop - much the same as a 2D view.  

• But that means their view extents can be made smaller or bigger, depending on the size of the section box - if the section box is bigger than the original level model extents, they will be bigger in the view (sometimes dramatically bigger).  Yikes, that doesn't happen in section views!

• There is an exception to this rule, and that is when the levels are controlled by a Scope Box - see next method.

Scope Box

• When a level has a 'Scope Box' applied to it then all the above rules go out the window, and the Scope Box takes precedence, and it completely ignores a section box.

 

• This can be good if you want the levels to be cropped to something small while the section box is large
• Or it can be bad if you have a very small section box

This can be interesting to manage if you have two sets of levels in one model (eg. for different towers):

• Starting without any cropping or scope boxes it looks OK in 3D

 

 

 

 

 

Two sets of split-levels; no section box, no scope boxes

• Add a section box and all hell breaks loose:

Add Section box - view extents overlap for all levels

•  Once you apply Scope Box properties to the levels it gets it back under control

Add Scope Box control to levels

•  Until you make the section box really small - yuk!

Not so good with a small section box

• I guess you'd have to then use a crop region on the view and start hiding the levels you don't want to see, to solve that one.

2D vs 3D Grip Handles

When a level is uncropped by either method described above, the grip-handles on a level in 3D only show model extents (circle grip)

• Once the level is cropped (either by a scope box or a section box), the grip-handles become view specific (blue dot) - this is the only way I can see to get this to happen in 3D views.

• Unlike a section or elevation view, you cannot toggle the grip handles between 2D and 3D (whether the levels are cropped or not)

• When the grip-handles are view related, they do give you the option of aligning and locking the ends of multiple levels, so that you can adjust several at once - that is a good thing.

• You cannot lock a series of aligned levels and drag their model extents all at once in a 3D view - Unlike a section or elevation view,where you can lock them. 
• Yes, I know that most of the time you would not want people to be able to change the model extents of a level in 3D at all, let alone multiple levels;  however, a 'Model manager' may want to fix up levels in 3D since it is sometimes really tricky in section when they don't show up.  

• Unlike a section or elevation view, when you drag the grip handles in 3D, the level extents do not snap to line up with other levels.  That is really irritating.
  
• It will be a waste of time trying to align model extents of multiple levels in a 3D view by dragging the grip-handles (reasons above), as they will never perfectly align with each other.  OK, so use Scope Boxes instead!

•  When a level is pinned (and cropped in a 3D view), you can still adjust its view extents without unpinning it - thank goodness.

 

• Levels can be accidentally selected in a 3D view and then deleted, moved, copied etc  - previously this could only be done in a section or elevation view, where levels were much more obvious (hence less likely to be accidentally selected).  Now there are many more chances for people to mess up your model!

During beta testing I lobbied really hard to stop this feature being released in its current form (if at all), because of the reasons above.  I lost that battle, but a few good things did come out of the discussion - they gave us a new safety check feature:

• We now have a new warning dialog box when you delete a level - it warns you that associated views and elements will be deleted.  This is a very welcome side-effect of the 3D Levels.

View Visibility

• When you upgrade an old project to 2019, Levels will not be visible by default in existing 3D views - you would need to go to Visibility Graphics to specifically turn them on.
• However, in new projects they will be visible by default in 3D views. Apparently Autodesk were keen for this new 'enhancement' should be more discoverable!
• It appears that for new 3D views in upgraded projects, they will also be visible by default.   Aaargh.
• Thankfully that does not apply to perspective views, where
  Incidentally there is a way to set up your projects so that new 3D views will have levels hidden, using a default 3D template - more on that in another blog post.

Conclusion

Over the last few years Autodesk have been slowly but surely giving us more ways to lock down our models and make them more secure.  And now they have opened another can of worms - largely as a response to significant user demand (on the Revit Ideas Wishlist, amongst other places).  

Ah well, that's the danger of listening to popular votes (open wishlists) instead of the experts!

So where does that leave us?  There are several things you can do to minimise the risk:

1. Don't upgrade to 2019 until Autodesk fixes the issues described above (2019.1?   .2?   2020?) - but you'd miss out on the other goodies such as view control / multiple monitor support etc!
   
2. Make sure that all levels are pinned all the time.  ALL THE TIME.   Make sure that your users understand the selection locks so they can prevent selection of pinned elements.
   
3. Use Scope Boxes to manage the model extents of your levels. This would be good practise anyway in most cases, as it gives you better control and locks them down somewhat.
    
4. Teach your users how to manage these issues and make sure they really understand the difference between view and model extents of levels (and grids, and sections), and between scope boxes vs section boxes.
    
5. Set up a default 3D view template that has levels (and scope boxes) hidden, and set it to apply to all new 3D views.

Weird Revit Railing Stuff - Part 2 - Railing Extents

Go to Revit Stair & Railings Index Page

We often create railings that consist of only the handrail, be it the old style rail or new (v2013) Top Rail or Handrail.  The reasons for this are varied:

• Often we are only interested in seeing a railing in plan
• Everyone knows that balusters in Revit railings are um, tricky, to say the least!
• Balusters, fixings, transitions etc are incredibly difficult to get right in Revit railings so many people just do those in 2d in a section view.  Yes, very "un-Revit", but pragmatic

 

In Revit pre v2013, with the old style railings, this did not cause any problems aside from the usual ones of controlling railing locations.  However, from v2013 onwards, you can get all kinds of weird stuff happening, particularly with railing extents  . . . .

Top Rail Railing Extents

With the new style of v2013 railings you can still use the old method of horizontal rails, described in my earlier post on Top Rails in Revit Railings.  If you do this, there would be no issues with railing extents.
If your railing has only a Top Rail, but no balusters, no supports, no old style rails, then it will cause problems.

No rail structure, no balusters

In this situation, the actual railing containing the Top Rail may have large extents:  In v2013 the extents will always include the 0,0,0 origin point in your project; in more recent versions the origin may vary, and may depend on whether the stair has been moved from its original location.

This problem shows up in two situations: groups and selection by click and drag.

Groups

If you create a group that contains a railing with only Top Rails, the overall extents of the group will include the extents of the railing, and hence your project origin point (in v2013).  This could result in a group with very large extents, causing all kinds of confusion.

In Revit Sundial (test version of Revit 2015 subscription enhancements, yet to be released), the code has been changed a little so that the extents do not include 0,0,0 but instead seem to include the previous location of a stair/railing that has moved.  Each time you move the stair/railing, the extents remember the previous location.  How weird is that?  Not sure when this was changed.

Selection

If you select a stair and railing by dragging across them from left to right (to include them wholly), it would normally include the stair, its sub-components, the railing and its sub-components (inc. top rails).  NB. check this in the filter selection

However, if your railing has only Top Rails, but no other sub-components, the extents of the railing would most likely be bigger so that the railings are not selected.  This is very confusing because the Top Rails are selected, which visually looks like railings are also selected - check the selection filter to see that they are not.

If Top Rails are selected, they will most likely display pins;  you will also notice that the Create Group command is greyed out - this is because Revit will not allow you to create a group that contains Top Rail sub-components, but not the parent railings.

In this situation you would need to manually add in the railings to your selection.  You might be tempted to select by dragging from right to left, which would capture the railings because it crosses their extents - but any good Revit user knows that this is seriously bad practise because it could also include hidden elements (That is the number one Autocad habit that new Revit users must unlearn!).  Once the parent railings have been added in to the selection set, the Create Group command becomes available.

Good news:  In Revit Sundial, the list of railing sub-categories has been tidied up so they are listed together by adding a "Railing:" prefix (like the stairs).  Its only a little thing, but it makes life easier - thanks Factory.

Top Rail Properties in Revit Railings
Weird Railing Stuff:
Part 1 - Top Rail Transitions
Part 3 - Railing Sketch Offsets & Transitions

Go to Revit Stair & Railings Index Page