BIM History - Rucaps User Group Newsletter

Although this blog is mostly about my trials and tribulations with Revit, my experience with BIM software started many years before Revit was even dreamed of.  There have been many forerunners to the current crop of BIM programs, and I had the privilege of working with two of them, which I would like to talk about lest they become forgotten in the mists of BIM history.  

The term BIM is an acronym for Building Information Modeling - that means creating a 3D geometric model that has non-geometric data attached to it.  Of course any BIM program needs to have meaningful ways of representing and extracting information, such as drawings, visualisations, schedules etc.

I also worked with quite a few 3D modeling programs (Computervision, Caddsman, Sketchup, Mac Perspective, MicroStation etc) - but they lacked meaningful "information" as part of the model.  I did try to use "Triforma" (The BIM version of MicroStation), but gave up on that and resorted to using MicroStation as a documentation system (which it was very good at) with a bit of 3D modeling thrown in.

Caddsman Architect was a really great Australian 3D modeling/documentation program, but it did not integrate well with other systems, and with so few other users out there, training was an ongoing burden. 

My first experience with BIM, back in 1981, was using "SCRIBE", which was a 3D modeling and thermal analysis program written by Cedric Green at Sheffield University - more about that in another post.  That was followed by a couple of years of manual drafting with pen and/or pencil, followed by a stint of 3D modeling with Computervision at DP Architects in Singapore.

In 1985 I started work using RUCAPS at HKPA Architects in London - this really was a precusor to modern BIM programs.  Although it technically worked in 2.5D we were able to create 3D views, 2D drawings and details;  it also had the capability to attach rudimentary information - and it did allow basic scheduling of components and quantities (after a fashion).  Although some might dispute the use of the word "Information" for RUCAPS, I maintain that it did happen.  Of course it was superseded by such products as Sonata.  All of this is documented elsewhere - on Wikipedia and various articles here and there.

RUN - RUCAPS User Group Newsletter

One of the good things I found about RUCAPS was the strength of the User Group, particularly in the UK and Australia - they had regular meetings and a newsletter that evolved into an international magazine.  I became involved in the user group and with running the newsletter (RUN) - first as a technical editor, and later as overall editor.

The earliest edition I have found reference to was RUN 3 in November 1984 - so I'm guessing the first edition was early 1984.  My involvement started with writing many articles, particularly from 1987 (RUN 11) onwards.  When I joined as technical editor, the overall editor was Andrew Postlethwaite (of Shepherd Robson Architects); the overall coordinator and marketing consultant was Jo Hunting (of t² Ltd) - she made it all happen.

RUCAPS was initially written by John Davison and John Watts, then taken on by GMW Architects who later formed a separate company GMW Computers to sell and develop the software.  GMWC later became t² Solutions.  RUN 13 featured a ten year anniversary article by John Davison - by then Managing Director of t²:

A DECADE OF RUCAPS

ln 1972 when GMW Portnership visited the Liverpool Centre for Computer Aided Building Design to see 'Neanderthal' RUCAPS, a 1 Megobyte disk drive, stood 5 feet high by 4 feet deep by 2 feet wide. lt needed its own three phase electricol supply. could never be switched off ond never worked continuously for more thon a couple of weeks; but in those days you didn't let little things like that deter you!

By the time thot RUCAPS was first sold in 1977 you could fit 2.4 Megobytes of cartridge disc into a cabinet 9 inches high by 3 feet deep by 2 feet wide. These discs were highly reliable despite the fact that the whole cabinet shook when you tried a complex zoom.

At that time none of us were aware that we had seen the beginning of a technological revolution whlch would continue to gather momentum, just os I suppose Cro-Magnon man would not have expected his offspring to land on the moon.

By taking a last look bock at the past ten years of RUCAPS perhops we can find some a useful pointers to the next ten yeors of development.

The first RUCAPS systems were single user systems which ran on the most popular mini-computer of its day - a Digital PDPI I /34. This machine, like most powerful mini-computers of its time, was a l6-bit
computer. The discs, as I have said, were 2.4 Megabyte removable cartridge - the top one containing the RUCAPS software and the bottom one containing your project data. The screen which was also
monufoctured by Digital was an 11 inch refreshed vector disploy which did not have any memory of its own instead it used the computer's memory to store its on screen display data. This created a strong conflict for computer memory when you realise that the maximum capacity of the PDPI 1/34 was
only 64 Kilobytes in total. (For those of you who are too young to remember what Kilobytes are, then 64 kilobytes is one sixteenth of 1 Megabyte.) Every imaginoble trick to save memory had to be
employed but still the moximum number of components displayable on the VT-11 was just 50.

Todoy we might consider such a system for a small house extension, but remember that in 1977 these systems were used to produce production drawings on 400 bed hospitals, large factories and the University of Riyadh. Without SKETCH, DRWCAT, LAYOUT, COMGEN, AUTOPROD or IMAGER
and many more. the four users displayed ingenuity and tenacity where today we demand function and ease of use. But, of course, it is thanks to the successes of these pioneering users that RUCAPS has been able to develop to use modern intelligent screens and powerfuI multi-user computers.

Today, when we are constantly being made aware that we live in a time of rapid technological development, it is hard to comprehend that this was not always obvious to us, But before we begin to be
complacent, sitting in front of our Concept ond Designer workstations, who among us today can conceive of a workstation (ten yeors hence) with 80 times the capacity, or who can imogine what sort of building we will be designing on a RUCAPS system with 20 times the program at our disposal? A
fascinating thought I hope, with which to enter the second decade of RUCAPS development.

DR JOHN DAVISON
 

RUN 13 - Reading Town Hall RUCAPS drawings by Andy Payne of Architects Design Partnership

 

 

RUN 14 was sponsored by T Three - leading RUCAPS implementation consultants

RUN 15 (mid 1988) saw the introduction of Sonata, which was written by Jonathan Ingram and Murray Pearson (ex-t²).  It was then bought by t² Solutions, initially to run alongside RUCAPS - but ultimately all resources were put into the development of Sonata.  This edition included the first of many articles about Sonata:

More to follow on subsequent issues of RUN in part 2

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.

Revit Conceptual Massing Environment - Index

Over the years I have struggled with the Conceptual Massing Environment (CME) in Revit.  It is not easy to use, and is not at all well integrated with the rest of Revit.  However, I have learnt a huge amount about how to get it to do what you want (or not!).  I have tried to document some of the tips and tricks on this blog and during various conference presentations that I have given at RTC & BILT .

Here is a summary / index of all the relevant posts on this blog:

Conceptual Massing Environment

Rival Revit Environments - Traditional vs Conceptual Massing Environment (CME)

 

Creating Traditional Forms using Conceptual Massing

Part 1 - Extrusion 
             Extrusion Offset Properties
Part 2 - Blend
Part 3 - Revolve
Part 4 - Sweep
Part 5 - Swept Blend
Part 6 - Loft

 

Part 7 - Hybrid Swept Blend / Loft

• Creating Tightly Curved Swept Blends
• Creating Sinuous Curve Swept Blends - Part 1
• Creating Sinuous Curve Swept Blends - Part 2

•  Unable to Create Form Element

• Swept Blend using Adaptive profile
• Hollow Section Sweep with Adaptive Profiles

• Divided Path & Node Visibility

Revit Nurby Forms at BILTANZ

Adaptive Components

Adaptive Components

Adaptive components are a subset of the Conceptual Massing Environment:

•     A Dozen Reasons Not to Use Adaptive Components
•     Reasons to Use Adaptive Components
• Swept Blend using Profile in Adaptive Component
• Egress Path using Adaptive Components (Life Safety Plan)
• Egress Path (Update) and Shape Handle Points
• Mona Lisa's Eyes Follow The Revit Camera
• Adaptive Component Origins
• Zero Length Lines are Possible in Adaptive Components

Repeaters

Repeaters are a kind of array, in the CME world . . .

Modelling Santiago Calatrava's Gare do Oriente (Lisbon) using Repeaters:

Step 2  Putting roof panels on top of the rig . . .
Step 3  Creating the structural elements and placing on the rig
Step 4  Adding Struts to the structure

Step 5  Assembling the Array of Structural Columns

Revit Ideas - Vote to Improve the Conceptual Massing Environment in Revit:

Some of the problems could be alleviated by the following capabilities - please vote for them on the Autodesk Revit Ideas wish-list if you agree:

• Control profile order during form creation

• Nominate Path during form creation

• Massing Tools - Give Them Some Love

Creating Lofts in Revit Mass - CME Part 6

Here is part 6 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, Blends, Revolves, Sweeps and Swept Blends in the CME.  Hang on - part 6 of 5?  Oh that's right, there is no way to create 'Loft' forms in the traditional Revit environment:

Part 6:  Lofts

It is possible to create a 'Loft' in the Conceptual Massing Environment - it is a little different to a Swept Blend, and has its own rules (and problems).  A loft is a 3D form made by linking a series of planar profiles to create a surface(s), which can be flat, faceted, curved or double-curved (NURBS).  I consider a loft to have a minimum of 3 profiles, as 2 would just be a 'Blend'.  The profiles are linked along a notional path - the difference between this and a Swept Blend is that the latter uses a specific path element, and a loft does not.  Revit will figure out its own path (or not, as the case may be!).

As soon as the edges are not aligned and you have 3 or more profiles, you will get curved surfaces – Revit creates its own spline edges.

The greater the displacement between profiles, the more dramatic the curves

The profiles do not have to be parallel to each other, but as soon as they are at different angles it becomes less predictable as to whether Revit will create the form as you desired. In the example below, the profiles were hosted on reference planes, which can be rotated, but only before the ‘Create Form’ process

Revit may not create the form at all, and you might get this error message:

If the error mentions 'Self-intersecting geometry', it may be due to Revit getting the profile order wrong such that it tries to create a form that doubles back or crosses over itself - something that Revit does not like one little bit.  When you select the profiles in the first place, it makes no difference which order you select them - you have absolutely no control over the order that Revit uses in the Create Form function.  It is not clear how Revit decides on the order - it may be proximity to each other?  However, I don't think it is that simple.

The second part of the error message talks about the 'Reorder Profiles' button - this is not usually visibly apparent.  There is a blank space for it in the bottom left corner of the dialog box.  Wouldn't it be nice if Revit tried to Create Form again with a different profile order;  better still if it asked you to nominate the order!

About once in every few hundred times you get this dialog box, there will actually be a 'Reorder Profiles' button.  Be very careful about clicking on it.  The first time I tried that, Revit crashed out and closed without saving anything.  Thus it is wise to save all files before attempting this.

If you do click on the button, it won't help!  If it doesn't crash, it will just fail again.  It would seem that one of the programmers was aware of this form non-creation ability of Revit, and they tried to add a solution.  However, it seems like this functionality was removed from Revit before it was released to the unsuspecting public.  Sadly one instance of the many variations to the dialog box still has the button there to tantalise us.

If you would like Autodesk to fix this, please go to the Revit Ideas wishlist and vote for this enhancement request:

Control profile order during form creation


This description of Loft creation shows a very simple example - it can get quite complex.  There are many tips and tricks as to how to make Loft form creation easier and more predictable in Revit.  More to follow later . . . .

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.