Weird Callout Behaviour in Revit

A few months back I wrote about some of the weird rules for Revit Callouts when you use the 'Reference Other View' option.

There are some strange and frustrating restrictions, which mean you need to plan carefully about what view types/families to use for callouts, and in fact for any views.

There are also some weird restrictions in how Callouts work when you don't use 'Reference Other View' - I refer to those as "Real Callouts".  I am going to record those here.

Stop and Think - Which Parent View?

Before placing any "Real Callouts",  stop and think about which view you want to place the callout on - you should already have a good plan for how your drawing set referencing is going to work.

The reason for this is that once you place a Real Callout on a view, it does two things:

• It creates a new view that is automatically cropped to the extents of the callout that you just created.
• It places the callout element on your view - typically a dashed line rectangle with a circular reference bubble.

It is  really important to know that once you place a Real Callout on a particular view, it can never be moved to another parent view.

The only workarounds are:

• Start from scratch - delete the callout + view, which means losing all your annotation and any other reference callouts to that view.
• Hide the callout on the parent view, and make a Reference Callout on another parent view.  This means that the old parent view can never be deleted - you would lose the callout view (refer to Deleting Callouts below). 
  This is a last resort workaround that I would not recommend.

Callout View Families

Detail Views vs Plan Views

The first issue to watch out for when creating Real Callouts is which view type you select (or don't select if you just accept the default).  For plan callouts you have two family options (and then choices of any view types that you have created):

• Detail Views
• Floor Plan Views

The really important thing to know here is that once you have made a decision between Detail or Floor Plan family, you can never change your mind - the families are not interchangeable.

View types are changeable - so you can change a callout from one plan view type to another plan view (but not to a Detail view).

Once you have chosen a callout view family/type, there are many weird and inconsistent rules about which view families can be referenced to and from callouts - refer to weird rules for Revit Callouts for 'Reference Other View'

For those and other reasons, I normally try to avoid using Detail views at all in Revit - see more reasons below, and refer to Weird Stair Path Stuff.

Detail Views vs Section Views

When creating Section view Callouts you also have two family options (and then choices of any view types that you have created):

• Detail Views
• Section Views

Unlike plan details, section details can be changed to normal section views - this is inconsistent, although it is welcome not to have that restriction.

 

Weird Detail View Behaviour

Detail views behave quite differently to other view types:

• Plan and Section views are typically grouped together in the project browser - it does not distinguish between them.  This can be confusing when searching for views.

• Detail views can be rotated in section (or elevation) from a vertical (section) orientation to a plan orientation.  If you know what you are doing you can use this to your advantage - but is not advised for inexperienced users.  It will most likely cause much confusion.

• When creating Real Callouts from a Detail view, they can only be another detail view.

• Stairs and railings are displayed as cut 3D models (wherever the view cutting plane is), rather than the Revit conventional 2D representation on other plan views - refer to True 3D Stair View in RCP.

• Symbols nested into families (such as electical fittings - switches, power outlets) are not visible in Detail views.

• Section and Plan Detail Callouts have the ability to set the depth of view the same as the parent view or independently - however, the controls are by 'Far Clip Offset' for both section and plan, not by view range.

Plan Detail Views

Plan Detail views have special rules (different to Section Details):

• Plan Detail Views don't allow Stair Path Arrows -  refer to Weird Stair Path Stuff.

For Plan Detail views, the callouts are generally only visible in the views they are placed on, with one exception:

• There is a ‘Show In’ property that can override this behaviour

• Plan callout views are normally set to Show In ‘Parent View Only’ 

• If this is changed to ‘Intersecting Views’ then the callout can potentially be visible in other plans within the same view range (thus behaving more like section detail callouts) - be warned, this will confuse the heck out of most Revit users.

• Be aware that ‘Intersecting Views’ detail plan callouts can also be visible in sections – they may appear as a line or with a reference head depending on the properties of the plan view

Section Detail Views

Section Detail callout views are potentially visible in section views other than their parent view.  They behave as if they have a hard-coded 'Show in Intersecting Views' property.  They might be visible under the following conditions:

• The callout view crop boundary is wholly within the crop boundary of the other section view
• The callout view section line is within the Clipping Distance of the other section view
• There are no other scale-related, category visibility or filters hiding them. 

Duplicating Views

• If you copy and paste a real callout, it actually creates a new view (and new callout).  In most cases this is not especially useful, as you are more likely to want the same reference to the original callout view - in which case it would need to be a 'Reference Other View' callout.

• If you copy a parent view by ‘Duplicate with Detailing’ it creates a new view for each callout – each would have a different reference on the duplicatd parent view. 

Deleting Views

• If you delete a parent view (plan or section), it will automatically delete any callouts placed on that view, and the callout views - although it does prompt you with a warning that it will delete those views.
• There is no way around this because once a callout is placed on a particular view, it cannot be moved to another parent view.
• This is a major drawback to using callouts in Revit.

Next Time . . .

In addition to the issues above, there is a limitation on not being able to have a callout rectangle that is slightly larger than the crop region of the callout view - thus making your drawings messy and hard to read.  Refer to Callout crop boundary mismatch

In the next blog post on this subject I will suggest an alternative working method that avoids some of these pitfalls and inconsistencies.

If you can remember all these rules and exceptions, congratulations!  Try remembering them again in a few months time.

To Pin or Unpin? that is the Revit Question

Following on from several recent posts about 'Pinning' elements in Revit, there are a few more subtleties to mention.  There are also some exceptions to the general rule of not being able to edit pinned elements.

Refer to these other posts on Revit Pins:

• The Revit Pin Icon
• Selecting Pinned Elements in Revit
• Revit Chain-Pins

Modifying Pinned Elements

A pinned element cannot be moved or rotated, but it can be copied

• If you try to move a selection that has any user-pinned elements, Revit will attempt to move them all (graphically showing the move) then warn you that they cannot be moved – so it puts them back and nothing happens.  This is a time-waster, so it is better to check for pin icons before moving large selections - and use the selection filter to check for hosted subcategories. 
• NB. It is not sensible to just click on the unpin icon on the ribbon before moving the selection - if you had any curtain walls or handrails, it would also unpin all the chain-pinned (type-driven hosted) curtain grids, panels, mullions and handrail supports - thus destroying the integrity of the model.

A pinned element cannot normally be deleted;

• If you try to delete a selection that has any pinned elements, Revit will behave quite differently to trying to move them:  If some elements in your selection are pinned, and some not, it will delete the unpinned elements and warn you about not deleting the pinned ones
• Revit will warn you about what is happening, but it is sensible to stop and think about what it has just done - and your next steps:  The undeleted elements are no longer selected, so it may be tricky to reselect the same ones?

Modifying Unpinned Elements

Once an element has been unpinned, you might think that it could be freely edited - but of course that is not true of 'Chain-Pinned' or type-driven hosted elements such as curtain panels, grids & panels.  there are some tricky rules and exceptions here:

Deleting Chain-Pinned Elements

• Unpinned type-driven Curtain Wall Mullions can be deleted;
• Unpinned type-driven Curtain Wall Grids cannot be deleted (but segments can be 'removed', laboriously, one by one);
• Unpinned type-driven Curtain Panels cannot be deleted - but you can change them to an 'Empty System Panel' (if you haven't purged the last type from your project, that is;  if you have purged it, you can't just create a new type of empty system panel, you have to copy one from elsewhere);
• Unpinned Railing Handrail supports can be deleted

Moving Chain-Pinned Elements

Chain-Pinned elements can only be moved within the constraints of their relationship to the parent element.  For example:

• Unpinned type-driven Curtain Wall Grids can be moved in one direction only;
• Unpinned type-driven Curtain Wall Mullions and Panels cannot be moved except by changing their properties, such as Offset;
• Unpinned Railing Handrail supports can be moved along the handrail - but there are some extreme weird behaviours when you try to do this.

Editing Chain-Pinned Elements

 The only Chain-Pinned elements that can be edited after unpinning are curtain panels – using the ‘Edit In-Place’ functionality.  In fact this allows you to do some crazy stuff with panels, which is quite surprising given all the other restrictions that prevent you from creating buildable elements!

Editing Pinned Elements

You would think that you cannot edit any pinned elements, but you would be wrong!

Floors (and other sketch based elements)

Pinned floors cannot be directly edited – the Edit icon is greyed out

Pinned floors can be modified (without editing the boundary) – by moving associated walls, depending on how the floor edges were defined:

• If the floor edge is defined by ‘Pick Wall’, the floor edge will move with the wall, even when the floor is pinned

• If the floor edge was done using ‘Pick Line’ or just drawing a line on/near the wall, when the wall is moved, the floor edge may still move with the wall, even if the sketch line was not locked to the wall.  The rules are not clear on this.

• This happens even if the floor sketch lines themselves are pinned when editing the floor. 

•  If a floor is moved, any pinned sketch boundary lines will just move with the whole floor - rendering the pin command inside a sketch pretty useless.

• Other pinned sketch-based components such as roofs, ceilings etc behave like floors.

This means that Wall Associations are stronger than pins in Revit.

Moves With Nearby Walls

An element that has been pinned, and has its property 'Moves With Nearby Elements' ticked will completely ignore the pin and move when a nearby wall moves

Wall associations win again!

Groups

Pinned Groups can be edited (without unpinning) - this is not the same behaviour as floor sketches.  However, it is not a bad thing in itself, as it means you can pin all groups all the time.

• Pinned elements inside a group will be moved or deleted when the parent group is moved or deleted, without so much as a 'By your leave'.

Properties

Instance & Type properties of pinned elements are generally editable - this means that such things as Base level or offset could be changed, thus rendering the 'Pin' less effective than you thought.

Modifying Pinned Datums

When a datum element (grid, level or reference plane) is pinned, you cannot change its 3D extents - not surprisingly.

• However, you can change its 2D extents in each view - which is a jolly good thing, because you can pin them, and leave them pinned!

Section Line

When a section line is pinned, you cannot change either its 3D or 2D extents.  In fact it does not display the extents or depth of view in plan when you select it.  This is an immensely frustrating and dangerous inconsistency in Revit.  It really ought to behave just like datums so that you could change its 2D extents, and at least see its depth of view - it is ironic that you can change the depth of view of a pinned section using the properties dialog box.

As soon as you unpin the section, you can adjust 2D, 3D extents and depth of view graphically in plan.  The big danger here is that you might forget to repin the section line, and some other fool may then move or delete your section line (along with all its carefully lined up 2D annotation).

For this reason it is wise to use the pin icon on the section line itself to unpin it - that way it retains the unpinned icon as a reminder to repin it immediately afterwards [If you use the ribbon unpin icon, it does not retain the unpinned icon on the section line itself]

Please go to the Revit Ideas forum and vote for 'Allow us to change 2D extents of pinned sections'

I am sure there are plenty of other examples of pinned elements in Revit that can be edited when you do not expect to be able to do so (or vice versa).

Global Parameters Enhancement Wishlist - Revit Ideas

All my recent research work on Global Parameters has created a list of enhancement requests.  Although a lot of new global parameter features were released with Revit 2017, we only had one enhancement and one bug fix in v2018:

• Associate global parameters to Radius and Diameter dimensions (2018)
• Global parameters vs Equals dimension conflict removed (bugfix 2018)

Here is my list of enhancement requests, plus a few other ideas from other people already on the wishlist - please vote for them if you'd like these to be fixed:



Enable global parameters to associate to Array Numbers

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

Enable global parameters to associate to Floor ‘Height Offset from Level’ system property

Allow association of global parameters to material properties of system families 

Allow access to Global parameter of linked model

Allow the use of Shared Parameters in Global Parameters

While we are on the subject of shared parameters, I really really wish we could use them in Key Schedules so please vote that up too.

Ability to "Paint" using a Global [material] Parameter

Please note that requests to enable us to associate global parameters to ALL system parameters will probably not get far because each and every one has to be programmed separately, so it is better to create a wishlist item for each parameter that you want access to (frustrating, I know).

Revit Stair and Railing Enhancement Requests

Do you think that the Revit Stair and Railing tools are good enough for typical Revit modelling?
No?  I thought so.

Well, Autodesk seem to think that they have fixed stairs and railings in v2018.  Well, yes, the new multistorey stair tool is a great improvement on the old system, and it has certainly improved how it handles railings.  But there is an awful long way still to go, particularly with railings.

Autodesk are now taking user input to the Revit Ideas website very seriously - yes they are listening to our requests on that site, and the number of votes really makes a difference.

Here is what we need to do:   vote for all those stair and railing issues that urgently need attention.

I have looked through the list of ideas on the website.  Since it is quite hard to navigate through all those duplicate ideas and requests for things that already exist (where people just need a bit more training), I will try to make it easier for you by creating a few links to ideas that I think need to be voted up.  I was going to wait until I had comprehensively reviewed all the wishlist items, and gone through all my own requests and comments on this blog in the past, then added some more wishlist items - but I think it is too important to wait.  I will add to this list in due course.

Please add your votes to any ideas that you support:

Stairs

Stair annotation:

• Allow rename or delete of stair path system family; Fix stair path arrows so that we can quickly add a path to multiple views
• fix the broken Copy & Paste function for stair path arrows.
• Tag All Untagged - Stair Path Arrows
   
• Make Stair Number Text Have Type Properties
   

Stairs & Views:

• "Show hidden linework" function should work on component stairs (actually it used to work on the old sketch stairs, but is broken on component stairs).  This is doubly important now that the old stair by sketch command has been removed from v2018.
• Ability for stairs below to obey view range (or cut mark on stairs going down?)

Stair modelling

• Component stair end in landing option
• Automatically cut a hole in floor above when creating a stair?  Too dangerous? Or a good idea?
• Stairs - More Functionality - this one is a repost of the original request that gathered much support but was labelled as 'Implemented' by Autodesk when multistorey stairs were imporoved in v2018.  The author does not consider any of its content to be implemented - (core & finish layers to stairs, more parameters, control over end conditions etc)
• Allow stairs to join structural elements such as beams
• Allow stairs and ramps to join walls and floors (same deal as above but it has lots of votes already)
• Allow Boolean Cut Void operations on stair components - so we can create irregular shaped stairs & landings without converting them to sketches

• Explode a v2018 Multistorey Stair back to separate stairs per level

Railings

Railings Generally

• Railing Overhaul - Resolution of Limitations - This is a comprehensive request to fix many things about railings from Chris Price (Mr Spot), who is an expert on Revit railings

Railing view properties

• Make railing terminations visible in plan view
• Allow railings to be visible in a Reflected Ceiling Plan - 
• Schedule Railing posts and balusters

 Railing Modelling

•  Please make Railings more user friendly - 
•  Railing baluster spacing 'Shrink Pattern to Fit' option
• Unchained Railings - allow a break in the railing sketch 
• Give us Control of Railing Offset from Path Default Property

• Fix Railing Toprail/Handrail Inside Corner Transition

• Start and End Indents on Handrail Support Spacing
• Horizontal rails to have start and end indent/offset (to match start/end baluster space)

• Rationalise Railing Materials so we don't need to duplicate numerous linked families for one material change

If there is something that you want to see added, please create your own stair or railing 'Revit Idea' on the Autodesk site - specific detailed requests, please (one item per request).   If I can understand them clearly, and they have not already been implemented in v2018, I'll add them to this list.  Please do not create any more general requests to improve railings - just vote for the 'Railing Overhaul' one from Chris Price, listed above.
More to be added soon . . . .