BILT Speaker

BILT Speaker
RevitCat - Revit Consultant
Showing posts with label start. Show all posts
Showing posts with label start. Show all posts

Friday, 22 November 2019

Travel Path Update in Revit 2020.2

Hooray - with the release of 2020.2, we finally have something useable in the Revit 2020 Path of Travel feature!

The initial release in Revit 2020 Path of Travel and Follow Up and the improvements in 2020.1 actually gave us a feature that was unusable in almost every situation.

It still has a number of limitations but at last we can make use of it to some degree.  What makes the big difference is the ability to add "Waypoints" anywhere along the path of travel.



You may remember (from my earlier descriptions) that when you place a 'Path of Treavel' by clicking the start and end points, Revit calculates the path for you - and you had little control over that, apart from choosing which elements form obstructions (or not).  Hence, in the standard Autodesk sample file, the path calculation was not able to determine that a sofa at a lower level should still be an obstruction:
Path or travel in v2020

In 2020.2, the calculation seems to have been slightly rationalised to give a more sensible path through the corridor to the north, but it still goes over the sofa in the split-level living area.
Path of Travel in 2020.2

Add Waypoints

We now have the ability to add (or remove) 'Waypoints' - this allows us to nudge the path to a more sensible course around the sofa.

If you need to make your path of travel orthogonal (as required in some jurisdictions), it can be done by adding enough waypoints - rather laborious but at least it works.


This is a very welcome addition to this feature.  However, it is still taking longer than the Daleks to learn how to manage stairs and changes of level in the building.
There is still no way to control the minimum width of a gap between obstacles (about 430mm or 17")

Friday, 30 August 2019

Travel Path Update in Revit 2020.1

Following on from my posts about Revit 2020 on Path of Travel and Follow Up :

With the release of Revit 2020.1, we have been given four minor improvements to the new (2020) 'Path of Travel' feature in Revit.  Welcome as they are, these improvements do not address any of the fundamental shortcomings of the tool, which seems like a missed opportunity:
  1. Start and End Points of travel paths can be dragged.
  2. Reveal Obstacles toggle.
  3. To and From Room properties have been enabled (these were previously just blank instance properties in 2020).
  4. Two new Dynamo nodes for Travel Paths (presumably new API capabilities allow this?)

Start and End Points

If you select an existing 'Path of Travel' element (which behaves like a polyline detail line) it now displays a blue grip-handle dot at each end.
  • Select the grip-handle and drag it to a new location - while doing so, Revit displays a moving straight line directly between the cursor and the other end of the path.

  • Once you let go the grip-handle in its new location, Revit recalculates the path of travel

  • Associated properties, schedules and tags will also be updated.
This is a very welcome little change to behaviour - if you tried this with the original vesion (2020), it just moved the whole path of travel.  However, this is only a small usability enhancement.

The fundamental issues it does not deal with include:
  • Still no ability to choose, change or control where the actual path goes (apart from adding/removing obstacles).  In order to do this, we would need to be able to somehow nominate additional points along the path, which it must go through.
    [Edit. * NB. Revit 2020.2 improves on this]
  • No ability to make the path orthogonal (in Australia I have never needed that, but comments on my last blog post indicated a requirement for this in North America)
    [Edit. * NB. Revit 2020.2 improves on this]
  • No ability to deal with sloping floors, level changes (split level), stairs.
  • No ability to prevent the path going through a very narrow opening (430mm or 1' 5") - more on this in another blog post.

NB. Given that the default selection colour in Revit is dark blue, and the grip-handles are mid/dark blue, it is pretty hard to even notice this new feature.  I would recommend changing your options for selection (and pre-selection) colours to something other than blue. 

Incidentally, which *!@*&#$ at Autodesk thought it was a good idea to make the selection and pre-selection colours the same (both dark blue)!



Reveal Obstacles toggle


This is a useful new tool for figuring out why your path of travel is not behaving as expected.  Again, this does not address fundamental shortcomings - such as:
  • What do you need to do when Revit fails to generate (or update) a path at all.

This new feature has a few quirks in behaviour - as detailed in another blog post.


[Edit. Revit 2020.2 further improves on 2020.1]



Monday, 2 July 2018

Creating Revolves in Revit Mass - CME Part 3

This is part 3 of my series on  comparing the five traditional form creation tools with equivalent techniques in the Revit Conceptual Massing Environment.
Previously we analysed the creation of extrusion forms and Blends in the CME.  Now it is the turn of 'Revolves' (pun intended):



Part 3:  Revolves

Creating a Revolve in the Conceptual Massing Environment is relatively simple, but it does not give you the option to nominate the Axis of Rotation - you just have to draw a straight line and hope that Revit figures out which element you want to use as the axis:
  • Draw a straight line (for the axis of rotation) and a profile (closed or open) 

  • Select them both and ‘Create Form’ 
  • If the profile is closed it will just create the revolve (maybe!); 
  • If the profile is open, it will suggest two options: a revolve or a flat surface connecting the line and profile

  • A closed profile can allow a nested loop to create the form, but only if the profile is made from lines – not from a loaded family profile 
  • This is only one of two situations that I have found where you can include a loop within a loop during the 'Create Form' process in the Conceptual Massing Environment.

Once the Revolve has been created, the form will have properties for Start and End angle - these can be changed to reduce the form from a full 360 degree revolve.




YouTube

Below is a short YouTube description of the Create Revolve in CME process:


Sunday, 24 September 2017

Weird Railing Stuff - part 7 - Support Spacing

It amazes me that very few Reviteers make use of the 'Railing Support' capability that we have had in the software for over 5 years now.  In fact, a very large percentage of users don't even know they exist
Here are some possible reasons why that is the case:
  • If you upgrade a project with the old style railings in it, they are not converted to the new style railings, so you cannot use railing supports in them.  To achieve this, you have to copy a new railing type into your project, then swap the old family type to a new one to get access to the support functionality.
  • The metric project templates provided by Autodesk do not include any railings that use handrail supports (this includes the Australian and UK templates);  they do have some support families - but if you don't know how to use them, you'll never figure it out by playing around with the railing samples.
  • The sample files that you can download from the Autodesk Knowledge website include only the old method of using balusters to look like handrail supports - and that is the imperial unit sample file, which you would expect to be the most likely one to be updated when the software was changed (The metric version would have no chance, even if you could find it on the Autodesk labyrinth-site).  I wonder if anyone at Autodesk knows what QA means?  'Quality Assurance' is the correct answer, not 'Quick As (get this out the door)'.
  • The settings for adding supports are buried deep as type properties of a nested family.  The chances of finding this are slim - although that has improved recently with the ability to get to a handrail family properties directly from the railing type properties dialog box with one mouse click.
  • The methodology for setting up handrail supports is mind-bogglingly complicated and counter-intuitive - and it is all type-based properties hidden inside handrail families nested into the railing family.
  • Even when you have set up the supports in a handrail family, you have to remember to choose left or right (for the handrail) in the railing family, otherwise nothing shows up.

Handrail Support Spacing

Once you have figured out how to set up Handrail Supports in a railing,you will obviously want to control the spacing - first the initial spacing, and then changing the spacing.  There are at least two weird things you need to know about this - the first is how illogical and inconsistent the spacing properties are.  The second weird thing relates to moving the supports - to be dealt with later:

Spacing Properties

Do you think it is weird that baluster spacing and handrail/top rail extension length properties are measured in plan distance regardless of the slope of the railings, while support spacing is measured along the actual length of the handrail whether it is horizontal, sloping, vertical or going round a twirly flourish at the end?  Whichever one is correct, it is weirdly inconsistent.

How would you measure the support distances on this handrail?
In the Handrail type properties, you have the typical Revit options (plus a special one):
  • None
  • Fixed Distance
  • Align With Posts
  • Fixed Number
  • Maximum Spacing
  • Minimum Spacing
Unfortunately these are not consistent with each other, and none of them will give you the outcome that you desire (unless by a fluke the spacing just happens to work for your stair):

1.  'Fixed Number' does not put supports at the ends of the railing;  the spacing varies depending on the overall railing length, and the number that you put in - NB. the number is a type property of the handrail, which means that you most likely need a unique handrail type and a unique railing type for every single instance of the railing.
It seems that the supports always use centre justification for this - it is greyed out and you can't change it;  also, the greyed out value for spacing is just a remembered value from the previous settings, and is misleading here.  Revit does not report back to you what the actual support spacing is on each handrail instance.

If you have a free end handrail, you would typically want a support close to the end (but not exactly at the end).  You don't get a support anywhere near the end, unless you put in a ridiculous number of supports, like 50 in this example.
Fixed number does not put supports at the ends
If you have an extension to wall or floor, then this option makes sense, however, the spacing includes the length of the extension, measured along the handrail, including vertical length for a floor extension.  The example below, with a wall extension is the one and only situation where Revit gets the support locations close to what you might need, albeit that you need a separate type for each different number of supports.


2.  'Fixed Distance' only puts a support at the start or end of the handrail if the justification is set to Beginning or End;  the distance at the other end is pot-luck depending on the overall handrail length.  If the justification is 'Center', then the distance from the start and end again depends totally on the overall length of the handrail - so it is luck of the draw, but it will be the same at each end.
The calculated distance includes extensions.





 3.  'Maximum Spacing' always puts a support exactly at the start and end of the handrail; justification is not an option here - it is greyed out (and set to center).  Just imagine sending this drawing to a builder or fabricator - you'd be laughed off the site.

Revit does not take into account whether an extension with a wall or floor fixing is chosen - it still puts a support in place at the very end, just where it is fixed to the wall/floor.

4.  'Minimum Spacing' behaves just like the Maximum Spacing settings, although the actual spacing will be different.

5.  'Align with Posts' is an interesting option - I don't get why you would use it, unless your posts are non-supporting in themselves.  If you do use it, you have no option for supports between the posts, so what good is that?  I would have thought the option should be 'Align with Posts & Maximum Spacing Between' and suchlike.  Or 'Maximum Spacing Except at Posts' etc.

With all of these options, you have the opportunity to unpin a support and move or delete it; [Edit - thanks to Peter Schiettecatte for pointing this out:] but you can only add additional supports by unpinning an existing one and copying it along the handrail (a clever but not too obvious workflow).  However, once you have done this, it takes just one innocent (or stupid) click on the 'Reset Railings' button to lose all that hard-won support over-ride spacing.

The Solution

What we really need to solve some of these issues is to have consistency in how the spacing is applied (at ends); and the ability to set start and end indent properties for handrail support spacing.  These would operate rather like the equivalent properties on a 'Divided Path', although I guess they'd need to be type properties to be consistent with all the other handrail properties (Oh, how I wish most of those were instance properties in the actual railing)

If you think this is a good idea, please go to the official Revit Ideas website and vote up my idea on this.

 More on this subject