Preventing Levels and Internal Origins appearing in new 3D Views

How many times have you seen a Revit 3D view obliterated by Scope Boxes?
Well, now we have Levels visible in 3D (2019) and Internal Origins in 3D (2020.2), which can also be visible by default.

There is a simple solution to prevent this happening:

Default 3D View

Typically, when you create a new 3D view, it has almost all categories visible, including Scope Boxes, Levels, Room Separation lines, Base Points and now Internal Origins. These can be very annoying in 3D views - particularly the Origins in perspectives.

Here is a procedure to prevent this:

• Go to a default 3D view 
• In Visibility Graphics, turn off the visibility for Room Separation lines in model categories

 

•  Turn off all three Origin sub-categories (Internal Origins visible in 3D from v2020.2)

• Turn off the Scope Boxes and Levels category (Levels are visible in 3D from v2019); 

• [Optional] turn off other datum and view control categories like grids, reference lines, sections, elevations (in case they become visible in 3D views in the future)
• Create a new View Template from the 3D view – called ‘3D Default – do not delete’- [NB. “do not delete” part of the name is to prevent accidental changes later]

• Untick all the ‘Include’ boxes except for V/G Overrides Model & Annotation

• Click OK to close and save the View Template
• Go to the Type properties of the 3D view

• Set the ‘View Template applied to new views’ property as your new 3D Default view template 
• Untick the ‘New views are dependent on template’ property – this means it just turns off those categories, without permanently applying a view template;

• You will subsequently be able to change other category visibilities;

• All new 3D views and perspective views will have those categories turned off by default (scope boxes, Levels, Origins,  Room Separation lines etc).

This should obviously be set up in your project template as well as all current projects.

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! ]

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

Adaptive Component Origins in Revit

Have you ever wondered how Revit manages the "Origin" (X,Y,Z = 0,0,0) of an adaptive component?
It is somewhat different from the way it handles origins and insertion points of traditional Revit families.  So here is an analysis of the differences between the two.

Traditional Family Insertion Points

A traditional Revit family typically has three reference planes that intersect at the origin point - representing the X, Y and Z axes.  To start with, the origin is the same as the insertion point when the component is placed in a model.  For this discussion we will only think about the X and Y axes in plan because the vertical insertion point (in Z axis) is locked to the level (in the family) and does not change (unless you use the Offset property - see below).
At some point those X and Y reference planes might be moved within the family.  This may or may not affect the insertion point, depending on the reference plane properties:

• If the reference planes are moved, and they are set to "Defines Origin" then the insertion point will move to the intersection of the two reference planes

• Alternatively, one or two other reference planes might be set to "Defines Origin" - if they are in the X or Y axis, they will take over the origin property from the Centre reference planes (and the centre reference planes will have that property unchecked);  if the other reference plans are not orthogonal then Revit will ignore that setting, and use the centre reference planes or the original origin point.
• If no reference planes in the family are set to "Defines Origin" then the insertion point will remain at the original X=0, Y=0 origin
• If only one of the reference planes is set to "Defines Origin" then the insertion point will be at the intersection of the "Defines Origin" reference plane and the original perpendicular axis.
• If the insertion point of a family is changed and then reloaded into a project  where some have previously been placed, it will overwrite the family definition in the project and will move the geometry in any placed components of that family (by the same amount that the insertion point moved).

For this reason it is good practise to make sure the two reference planes that define the insertion point are not moved from the origin once you have decided where it needs to be (keep them pinned).  Geometry should be moved relative to the origin if need be.

Hot Tip:  If you lose track of the true origin, just create an Autocad file with a cross intersecting at X=0, Y=0.  Save the dwg and import it in to your family at "Origin to Origin"; trace over the cross with reference planes or lines; delete the dwg; purge the dwg (since you can't link dwgs into a family, you need to import, then purge).

Offset.
Most traditional unhosted Revit families have an "Offset" system parameter that is automatically created when you load the family into a project (this contols the Z offset from the placement level or workplane).  Recently we found some old plumbing families (baths) that did not have the Offset parameter - we believe that this is because they were created from very old family templates that pre-date the addition of this offset capability, from the dim distant Revit past.  Hosted and face-based families usually have an "Elevation" system parameter (rather than Offset), which works like Offset but only in the project vertical axis, whereas the Offset parameter works in the local z axis of the family, which may not be vertical in the project.

Adaptive Family Insertion Points

Adaptive components behave in a different way.:

• Although they have a true origin with two reference planes intersecting there, the insertion point can be overridden by adaptive points.
• If there is no adaptive point in the family then it behaves almost like a traditional family, except that the "Defines Origin" parameters appear to make no difference - the origin and insertion point remains at 0,0 regardless of whether any reference planes have that property checked
• If there is an adaptive Placement Point in the family, then Revit uses that as the insertion point of the family;  however it still remembers the true origin

 

• If the only adaptive points in the family are Shape Handle points, then Revit uses the traditional origin as the insertion point (not the adaptive point)

• If a placement adaptive point is deleted (in the family) or changed to a shape handle point, Revit does not move the geometry when the family is reloaded into a project.  This is because Revit knows and remembers where the origin is even though it uses adaptive placement points for insertion - this is logical but can get confusing.

If a placement adaptive point is moved (in the family) then reloaded into a project it might move geometry of previously placed components - it depends if the geometry is hosted on the adaptive point or not.   In this example the hexagon is hosted on the adaptive point;  the circles are just placed on the level workplane, close to the origin point.

Geometry in the family

Geometry in the model

• Any geometry hosted on the adaptive point remains where it was in the model when the family is reloaded; 
• Any geometry placed in the  family but not hosted on an adaptive point will move relative to the 0,0 origin point - so if the adaptive point is moved/flexed in the family it will end up a different distance from the point in the family;  when reloaded, the unhosted geometry will move in the project so that it retains that distance, while the hosted geometry remains put at the insertion point

 

• Once you are in the project environment, and you move the adaptive point, something different again happens:  all the geometry in the family moves together! (this can be hellishly confusing).

Offset. 
Adaptive components do not have an Offset system parameter.  Instead they have an "Elevation" parameter, which does not appear to do anything - neither unhosted elements nor elements hosted on adaptive points will move when this Elevation value is altered.

Adaptive Component Reference Planes

Most adaptive component demos that I have seen show the placement of adaptive points in random locations in the family.  Why?  Probably just because you can.
I am more careful - I always put adaptive point #1 at the origin (intersection of the two reference planes that exist in the family template).  I do it for a reason, even though it takes a few extra steps - I have to go to a plan view because points won't snap to ref plane intersections in 3D.  If there is a second adaptive point I will snap it to the X axis for the same reason:  . . . .

• Let us assume that you place an adaptive point in a random location;
• Make it adaptive
• Then place some geometry associated with the point (set the work plane to its horizontal plane first)

•  You could place a dimension just to check how far it is from the origin

• Load the adaptive family into a project and place one (it uses the adaptive point for insertion)
• Try placing a dimension to roughly the same distance from the adaptive point as it was in the family - the hidden reference plane in the family will highlight and allow you to snap to it

•  Once you place the dimension, the highlighted reference plane disappears

• You could do the same with the other axis reference plane
• Revit will attempt to snap to those reference planes and their intersections during many other commands that involve snapping - even to remote objects.

Its not very helpful is it?  In fact it is downright annoying when you have lots of adaptive components placed.

• Imagine what happens when you have two adaptive points placed in the family at random, with some geometry between them?  

• The hidden reference planes are now at crazy angles in the project and cause all kinds of random snapping locations

Hot Tip:  In v2013 the developers gave us a solution to this issue by enabling the  properties of those reference planes to be set to "Not a Reference" [that did not work in v2012, I think]

Good Practise: 

1. Chances are that you will forget to change this setting some time, so it is a good idea to get into the habit of putting adaptive point #1 at the true origin, and point #2 on the X axis so that these reference planes will be orthogonal to the geometry.
2. Whenever you flex the family by moving the adaptive points, remember to put them back to where they were, so that you don't get strange behaviour where unhosted elements in the family might move in the model when you reload the family into the project.

For more differences between traditional and adaptive families refer to Rival Revit Environments