BILT Speaker

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

Saturday, 18 May 2024

BIM History - RUN Part 2 - RUCAPS and Sonata User Newsletter

Following on from my previous post on BIM History, here are some more covers from RUN - the RUCAPS Users Newsletter.

RUN 16 - Sept 1988

The Front and back covers featured drawing competition winners from 1987 - these demonstrated the ability to generate coordinated elevation views from the 2.5/3D model.  This may not seem like a big deal nowadays but this was done 37 years ago - over a decade before Revit was born.


 

 

RUN 17 - Winter 1988

This was no longer just a RUCAPS newsletter - but for users of all  software.  This issue was sponsored by "Real Image" who specialised in generating photo-realistic images from RUCAPS & Sonata models.


RUN 18 - Spring 1989

I was editor in chief of the magazine by this stage.

We decided to publish a Technical Supplement that contained all the RUCAPS technical articles from the previous 18 issues - updated.

The front and back covers again showed examples of coordinated elevations generated from the 3D model.  In those days we did not have tools to patch up the elevation & section views (like Filled Regions or the Linework tools in Revit) - so the models had to be pretty good for it to work.



RUN 23 - Spring 1990

RUCAPS was stuck on expensive DEC or Prime mini-computers (a misnomer!) - these had very limited interaction with any other computers or software.  Sonata was running on less expensive  hardware  - Unix workstations from Apollo and Silicon Graphics.  With the increasing use of Sonata the drawings and images were becoming more sophisticated. 

By this stage I was working in Australia - still on RUCAPS, so I continued to contribute to the RUN newsletter in the UK as an international user.



The RUCAPS and Sonata User Group in Australia was very active - we held national conferences and published an Australian newsletter . . .

Sunday, 14 April 2024

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




Wednesday, 24 November 2021

Revit Mirror Command is So Not BIM

 What is one of the first things that you teach people who are moving from Autocad to Revit?

"When making changes in Revit, DO NOT delete and replace elements - you should always modify the original elements even if it takes longer" 

Why is that?  Because you never know what data or hosted elements are attached to existing elements - so if you "Delete and Replace" you might lose the data or hosted elements.

  • What does the middle initial of BIM stand for?  "Information".
  • Without "Information" you are just working with a 3D Building Model

Revit Mirror Command

Revit is a BIM program, Right?

So you would imagine that it's fundamental command structure would work towards maintaining the BIM concept?

Unfortunately the "Mirror" Command in Revit doesn't follow the BIM rules.

It does not just mirror the selected element(s) - it copies and deletes original, even when Copy is unticked.

  • Select an element
  • Check it's Element ID

  • Mirror the element (with "Copy" unticked)
  • Check the Element ID of the mirrored element
  • Aargh, it is different

So what?  Well, it is just not BIM !


What does this Mean for your model?

Cut elements are no longer cut when mirrored

Joined elements are no longer joined when mirrored

etc

To test this:

  • Create a new family that has "Cut with Voids When Loaded" enabled:

  • Place a solid and void in the family (not intersecting each other)

  • Load the family into a project
  • Place a component where it intersects with another element (in this example, a wall of the same material)
  • Join the component and the other element (wall)
  • Cut the component and the other element (wall)
  • Mirror the component (No copy)
  • Component is no longer joined or cut

Compare to other Revit Commands

  • Undo the mirror command
  • Test the Move and Rotate commands (no copy)
  • Join and Cut are maintained


These commands are BIM compliant - original elements are manipulated

Hosted Elements are Deleted by Mirror Command

  • Add a dimension (or tag) to the component
  • Mirror (no copy) the component
  • If you are lucky you might get a warning about the impending loss of the hosted dimension


What to Do?  Is there a Workaround?

The first thing to do is to contact Autodesk and request that they fix this un-BIM-like behaviour

Despite this problem having existed for over 20 years, it will surely be fixed promptly for you if you ask nicely.

In the meantime . . . . .

There is another way to mirror components in Revit:

 

Control the Mirror Command

Families can have their own built-in mirror/flip controls.

In the family editor, place a "Control"




  • Reload the family
  • Select the component
  • Check its Element ID


  • Click on the Mirror control
  • The component will flip around its origin point
  • Check the Element ID
  • Woohoo - it is the same! 
  • And the Join and Cut are maintained

 

Flipping Hosts

Test the flipping control with a hosted element (dimension)

  •  It is not guaranteed to maintain the dimension, but you have a much better chance

Conclusion

Is this going to help you?

Maybe:

  • Obviously it only allows you to flip components one by one.
  • As the flip controls will mirror about the component origin, it may not end up exactly where you need it - but you can then move it

  • It will try to maintain any cutting and joining that you have done
  • It may warn you that joined elements no longer intersect - and you should have the option to unjoin or maintain the join (if the elements will later intersect again)
  • I have not tested the implications for Dynamo - I have no idea if it is possible to access the flip controls within Dynamo.

Revit Ideas Wishlist

There are already a couple of ideas relating to this on the Autodesk Revit Ideas Wishlist

Mirror Not Copy (for mechanical elements but applies to all)

MirrorElement Not Copy API


Monday, 17 May 2021

Revit Family Error Automatically Resolved

Some of you may not be aware but Autodesk sneaked in a new "Feature/Enhancement" in about version 2018 (I think?) - I do not remember any discussion or announcement about this in the testing/release process:

Warning:  "Family Error Automatically Resolved"

When you try to place or modify a component using parameter values that break the family (eg. cause impossible geometry), Revit will now try to "Fix" the family.

In reality, what is most likely going to happen is that you (the BIM or Content Manager) will be in a "Fix" or "Fixed Up" . . . . .

So, what is going on here?  


 When Revit tries to "Fix" the family, it seems that :

  • Revit makes the requested change to the values
  • Gives a warning to the user
    • As we know, most users ignore the warning and keep going
    • User clicks on OK or presses Enter

  • Revit omits the elements that it cannot create
    • Nested components are particularly prone to this
  • This results in a component that is missing some (sub)elements
 
  • The end user may not know what has happened
    • They may not knotice that something is mssing
    • They may not care!
  • If the user makes further changes to the values that still break the family, Revit gives another warning - this one requires no user intervention.

  • If the user changes the values to something that no longer breaks the family, it appears to reinstate the elements that it could not create.  
    • When I first encountered this, I was sure that once it happened, Revit would never reinstate the missing elements - but on re-testing this it appears to work ok.

 

Warning

  • It seems that when Revit "Fixes" a family for you, it does NOT retain a warning in the list
  • I think that is a serious failing with this feature, as the BIM Manager has no easy way to find or track the problem

Old Revit Versions

Prior to this "enhancement", Revit would just give a message saying that it could not create the family:


This meant that the user had to either choose values that did not break the family, or else get the Content Creator to fix the family so it did not happen.

 

Opinions

What do you think of this "Enhancement"?

  • As a BIM, Model or Content Manager I don't think I like it much because it means I often don't get told about the error - so it goes uncorrected.
    • It is not easy to find later on
  • As a Revit User, you might think it is great as you can get on with my work and not be interrupted by having to seek help from the Content Creator
    • It may or may not come back to bite you - chances are that it will become someone else's problem.  
    • If it goes unnoticed for a while the ramifications of the problem could become more significant.