Inuagural European Revit Technology Conference September 2013

Having recently returned from the inuagural European Revit Technology Conference I thought I'd give a quick report on how it all went.  Having been to all the RTC events this year, and all but one RTC ever, it was interesting to compare this event with others.

The Venue

Firstly, the venue was amazing - a mixture of old and new in the historic city of Delft in the Netherlands.  Delft looks like a miniature version of Amsterdam but without the swarms of tourists - very old Dutch gabled buildings lining canals.

• The welcome function was in the Lambert van Meerten Museum, the setting of one of Vermeer's famous paintings.  We were welcomed by a representative of the City of Delft who demonstrated an extraordinary aerodynamic umbrella that was invented in Delft.
• The main venue was the Waalse Kerk - a beautiful old church.  There we enjoyed the spectacle of Wesley Benn speaking from the pulpit (sorry he isn't in the pic below).

 

• The breakout / exhibition space was adjacent to this in a very elegant high-tech glass enclosed courtyard - they really know how to mix old and new buildings well in Europe (I've seen a lot of this sort of stuff in Belgium and the Netherlands).

 

•  The second presentation venue was the Meisjeshuis, just down the canal - well, it was a few minutes walk away beside the canal.  Once a nurses home and then a girls orphanage, it has now been converted to a conference venue.

The walk back to the main venue was a bit scary on two counts:

• The alarming lean of the tower on the old chuch - looking as if it would topple over onto the Waalse Kerk any minute;

 

• If you were too busy looking at the tower you could be knocked into a canal by one of the multitude of bicycles hurtling along the streets.  Talking of which, how do those cars park so close to the edge without falling into the canals.

• Mind you, if your car goes into the canal there many bikes to choose from - they even have double-decker parking at the railway station.

The Conference

Very sensibly the inaugural conference for Europe was kept small - this made it feel more intimate, like the earlier RTC events.  There were not so many session to choose from, thus making decisions was not as agonising - only 3 instead of 6 or 7 concurrent sessions.  Even so, I still missed one or two things I'd liked to have attended.  The two day length seemed so much shorter than other RTCs - it was over so quickly.  Hopefully it will expand to 3 days next year, now that it has proved to be such a success in Europe.

Speakers were very international - from Europe, North America and Australasia.  Attendees were from all over Europe, but there were large contingents from Norway, Denmark (one company sent 7 people!), the UK and of course the locals (The Netherlands).

The Day Families Became Self-Aware
One of the highlights for me was the session presented by Matt Jezyk  - "The Day Families Became Self-Aware" - an intriguing look at what might happen to Revit families in the future.  In this session Matt started off talking about how useful it would be if families were able to react to their Revit environment - for example, a door that is hosted in a fire-rated wall might need to enable its own fire-rating and change its panel thickness and materials etc.  Currently this is a very manual process for the user having to swap out the door type  (although we do now have reporting parameters that allow us to make the door respond to wall thickness).   Matt then talked about the whole process of API and Dynamo/Python scripting where it is possible to make Revit do all kinds of things, being driven by external code.  However, scripts and API have to be initiated by the user - they cannot react to stimuli or changes in the Revit model itself, so we are still reliant on the user again.  This is all stuff that we know about or are starting to learn of.

Then the exciting stuff started - Matt proposed a type of scripting that could automatically run itself as a response to when a change is made in Revit.  He showed us a prototype of Revit families that contained Dynamo or Python scripts - these families could be placed into Revit models as normal.  When placed the family would run the script and change the component according to where and how it had been placed, for example a door hosted into a wall could check its fire-rating and adjust itself to suit.  Not only that, but if the wall was to subsequently change, the hosted door would re-check the fire-rating and respond again.  So, no user intervention or checking is required.  Wow!  My reaction to that was the same level of excitement I had when I first saw Revit automatically change a drawing reference when a sheet was renumbered:  I want it, and I want it now!!!

Needless to say, this was only a proof of concept, so there is no guarantee that it will ever be implemented in Revit.  Of course it takes quite some time for something like this to reach the market, supposing they do go ahead with it - lots of testing and checking needs to happen.  However, the buzz that was generated in the conference after that was quite noticable.  I was only sorry I was not able to attend Kelly Cone or Martijn de Riet's concurrent sessions - but this was unmissable stuff.

Fractal Fun with Revit Repeaters and Adaptive Components

Photo by Håvard Vasshaug from twitter

My own presentation went well - incorporating some improvements since last time. 
It started off showing some fun stuff with Fractal theory and example patterns in Revit:

Fractal patterns - source Wikipedia

Koch Snowflake - source Wikipedia

Fractal Triangles created in Revit

Fractal Trees created in Revit

After the fun I demonstrated a few practical examples of how to use nested repeater patterns in Revit, including a picket fence that follows the contours of a site toposurface.

Adaptive fence component with nested repeaters - follows contours

Following this was a less practical but still useful example of how to nest repeater patterns inside curtain panel pattern components in order to force Revit to trim the edges of repeater patterns (which it normally will not do):

 

Then came the demo of creating a Revit model of the roof of Santiago Calatrava's Gare do Oriente in Lisbon.  This consited of multiple repeater patterns nested three levels deep, which allowed the creation of very a flexible parametric model with minimal use of maths

Repeater one - one-eigth segment of column with variable number of struts

Repeaters two and three - segment rotated/mirrored around its centre

Repeater four - column assemly in two way array over station platforms

Roof assembly at Revit-Dusk

All of this was done as a live demo in Revit, albeit with some partially prepared sample files in case it didn't work under the glare of an audience.

Photo by Martin Romby - from Twitter

 Roll on RTC Europe in Dublin in August 2014.

Revit 2013 Stair Path Arrows

Go to Revit Stair & Railings Index Page

Here is another extract from my RTC presentation handout on the new Revit 2013 stair tools. I don't see any good help notes available out there on the topic of Stair Path Arrows, so I thought this might help clear up some confusion about the new method of showing stair arrows that was introduced in v2013:

Stair Path Arrows

The old Stair arrows were an integral part of the stair, and they certainly had their problems. The new stair arrows are actually done as separate annotation objects – and these come with a whole new set of problems. Each stair arrow is placed on a stair on a per view basis, meaning that the arrow is no longer part of the stair, but behaves more like a graphical tag – this means that you will no longer suffer from that old problem of stair arrows or labels from floors below showing through floor slabs. There are a number of issues to consider when managing the new stair path arrows:

• Stair path types
• Placing stair path arrows
• Default stair path types
• Moving stair arrows
• Duplicating stair path arrows

Stair Path Types

There are two different system families for stair paths, and each of these can have multiple types that you can duplicate and change:

• Automatic Up/Down Direction 

This will show an Up arrow and label on stairs going up from the current level, and a Down arrow for the top level of a stair;  the middle levels of multi-storey stairs show one up and one down arrow.  In many countries this type is never used, as it can cause confusion.  I have seen drawings where the text is lower case "up" and "dn";  rotate by 180 degrees and these are interchangeable - so if the drawing is read from the wrong direction the meaning of the letters is reversed (dangerous)!!

• Fixed Up  Direction

This shows an Up arrow and label on all levels of a stair.  This is the standard method of annotating stair paths in many countries (including UK and Australia), but it may not be set as the default in the project template file.

Stair Path Properties

Each stair path has both instance and type properties, which will give you considerable control over how they appear on different views and at different scales.  Refer to Stair Paths at different scales for details on the individual properties.

 

Changing stair arrow types

• When you create a stair it adds stair path arrow annotation to all relevant existing plan views that the stair shows in;
• It will place the default path type for that project, which may be the Automatic Up/Down Direction Standard arrow (depending on how it was set in the original template, or if changed since then);
• If this does not suit you, then you need to select the path arrow and change it to your preferred type (using the Type Selector);
• BUT it will only change it on the view that you selected it on – all other views will still have the project default type (that includes views of other  levels of the same stair);
• You could right-click and “Select all Instances in Project” and change them to the correct type, but this is not efficient as you’d need to do it every time you create a stair;
• A better solution is to change the default:

Placing a Stair Path Arrow

If your stair does not have a path arrow in a particular view, then you need to place one:

• From the Annotate tab select Stair Path (on the far right of the ribbon, grouped as a symbol, not a tag)
• Check / change its type, eg “Fixed Up Direction” (from the Type Selector) before placing it;
• Pick the stair

Setting the default stair path type

• Place a stair (if you don’t already have one in the project);
• Select the automatically generated stair path - if it is the correct one for your standards then you do not need to change the default.  However, if it is wrong, delete it;
• From the Annotate Tab select new stair path, but be sure to change its type, eg “Fixed Up Direction” (from the Type Selector) before placing it;
• From that point on, all newly placed stair paths in that project will be of that type, including automatically generated ones;
• It would be wise to modify your standard project template, using this technique.  Don’t forget to  delete the stair from your template project before saving it.
• NB. “Automatic Up/down” is a system family, so it cannot be deleted from a project.  You could always rename its type from “Standard” to “Do not use this type” in your project template file (or some such corporate standard threat).

Copying stair paths

• When you create new views Revit does not add the stair paths in those views – there appears to be no way to force this;
• Duplicate view does not copy stair path arrows (because they are annotation);
• “Duplicate with Detailing” a view does copy stair path annotation, but of course it copies all the rest of the annotation too.
• There is no middle way to duplicate a view and have it duplicate just the stair paths without any other annotation.  Theoretically you could Duplicate with Detailing, and then delete all the unwanted annotation from the view – but that is a workflow fraught with danger (not to be recommended, except for perfect users who have 100% understanding of the stair & annotation tools, and never have concentration lapses).
• You cannot use “Tag all Untagged” for stair paths – although stair paths behave somewhat like tags, they are not actually tags.
• You cannot copy and paste stair paths from one view to another (a bug);
• You have to add stair paths to each stair in a new view one by one – it is the only way!

[Edit] How about we ask Autodesk to fix this (after 5 years)?  Please use these links to go to the Revit Ideas wishlist pages and vote up requests to fix these:

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

Moving Stair Paths

Stair paths are placed along the path line shown during editing a stair – usually along the centreline of the stair.  There are two ways to move them:

• When you select a stair path, it shows two shape handle arrows.  These can be used to drag the paths off-centre.  If you drag it back, it will snap to the original path location.
  
• If you require a path that is different from the simple one that is automatically generated – say you want to offset only one part of the arrow, you may need to “Convert to Sketch”  part of the stair, so that you could edit the location of the path line.  However, this is an operation that should not be undertaken unless you really have no choice, because once the stair components are converted, it is irreversible, and you would lose all the automatic functionality of the component.  In the example below, a complicated process is required just to offset one part of the path arrow – in this case it might be better to just create a manual stair arrow.   First the top run has to be converted, then the sketch has to be edited to move the run line, then the process needs to be repeated for the landing.   However, in this example, the landing and run might need to be sketch edited anyway, in order to get the supports to be correctly trimmed around the narrower part of the landing – this cannot be achieved using the shape handles on the landing.

 

• Complex stair plans, such as 'T'-shapes will not create correct paths for both upper runs, so you will need to edit the landing sketch to get the path right

Mix ‘n’ Match Old and New Stair Annotation

In old stairs the path arrows and cut lines are an integral part of the stair, and their visibility and appearance can be somewhat controlled by instance and type properties.  New stair path arrows are purely annotation objects that can be placed per view.

The default settings for the new stair paths and cut lines make them look very similar to the old style ones (which could not be customised).  So you could have a mixture of old and new stairs in one project.  However, as soon as you start to change the look of either the new cut marks or stair path arrows then it will look very messy if you have a mixture of old and new stairs together.


Refer to Stair Paths at different scales for details on the individual properties.

Stair path arrows and View Types

Stair path arrows cannot be placed on Detail plan views


[Edit] How about we ask Autodesk to fix these two stair path arrow issues, since they have ignored my bug reports ?  Please use these links to go to the Revit Ideas wishlist pages and vote up requests to fix these:

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

Go to Revit Stair & Railings Index Page

Revit Multiple Point Repeaters

Multiple Point Repeaters on divided surfaces in Revit

In Revit 2013 it became possible to host adaptive component "Repeaters" onto divided surfaces, and paths.  The adaptive components can have one or more adaptive points - last time we looked at single point components.  It starts getting more interesting with two point adaptive components - they can be hosted on nodes on a single divided path or surface.  They can also be hosted on nodes on two separate divided paths or surfaces – in this situation their behaviour becomes more difficult to predict as the logic is more complex.

Following on from the last post on single point adapters, here we will look just at two point components on a single divided surface:

Single Surface

A two point adaptive component hosted on adjacent nodes on a surface will initially behave much the same as a single point component - in the images below, the original hosted component is shown on the left, and the resultant repeater shown on the right.

The exception to this being that it will not place repeats where it cannot find equivalent locations for both nodes – so it may omit half a row/column.  In this example the repeater is stretched across two non-adjacent nodes, so that when it gets to the last column, it can only place the first adaptive point on a node, but the second one would be off the surface – so it omits them:

We can also see what happens when two components are placed on a single surface and then both selected to turn into a repeater pattern - the results are similar to the single point adaptive component patterns - you get a linear pattern.

 

If you want to alternate the direction of patterns by row, it will not work if you just place two similar components adjacent to each other in the reverse direction – it will just create a repeater in exactly the same place as the originals – not across the whole surface.  We will try to figure out why later.

To achieve the full pattern you need to place two pairs of alternating components in a square pattern.  It will actually create four separate repeaters but it looks correct (one repeater highlighted to show it is not a single pattern, but one of four interlocking patterns):

 If you try a different approach of placing just two alternated components  staggered on the surface, you get some surprising results:

This seems pretty weird -  what it appears to be doing is only repeating the second of the two components (top right).  It repeats it in the same distance and increment as the distance between the end of the first and end of the second component (point 2, narrow end) - ie. one grid module up the screen;  but at the same time it takes the distance between the start of the first and start of the second component (point 1, large end), and stretches the component, which is one grid up and 4 to the right.  It would put another component above, but that would be two up and 8 to the right - in which case it has run out of nodes on the surface so it gives up.  It is easier to see this pattern in the next example where it has room to fit more in the pattern:

If we try putting alternating components in line before repeating, the results are rather weird again - but at least we can understand the logic, that it is repeating only the second component but stretching its start and end points by the same proportion as the distances between the start and ends of the originals.

 

 It is a little clearer when the repeated component is smaller so that they don't overlap:

The next one has got me stumped - I just don't get it.  I guess it is following the same logic but its too weird that it flips the direction as well!

The good news is that once you begin to understand how these repeater patterns work, you can make some crazy diminishing patterns really easily.  This one didn't require any formulas (aside from creating the original adaptive component) - it just needs careful placement of the components before repeating them.  It would also be easier to understand the patterns with a larger surface where it does not run out of nodes so quickly:

Next time we might look at 3 or more point adaptive components;  or hosting them on multiple paths/surfaces . . . . Two-Point Repeaters on Multiple Hosts

Revit Repeaters Index Page