DEHOSTING

Via Project Soane I have come into contact with a young gentleman called Karam Baki who began using Revit as a teenager. He is an architecture student, based in Jordan, and you can get a feel for the breadth and energy of his enthusiasms at this link.

Karam's Gallery

I was particularly impressed with his model of Gerrit Reitveld's Schroder House, a building that has fascinated me for about 50 years now. I did start to model it on 2011, but didn't get very far.

Karam appears to have captured it in the most exquisite detail. I would love to talk about this topic at length, but that will have to be another day.  Here is Karam's version

I did write a short piece about the house in 1991 as a History assignment when I was a "mature student" in Joburg, returning to Architecture after a 16 year detour through bricklaying and education. Here is my analysis of the site (hand drawn though I had started to use AutoCAD by then). Mrs Schroder was a young widow, living on the edges of middle class society, both literally and metaphorically. She an Reitveld collaborated to create a very unusual house for a single parent.  It turned it's back to the conventional world, looking out over open fields and catching the sun through open corners.

A second, hand-drawn diagram describes the planning: a dense, cellular ground floor, with an open-plan, flexible living space above.  As I remember, she rented out the guest room at the back to a lodger for extra income, which is why it is isolated from the rest of the house with its own entrance.

I couldn't resist including the concluding paragraph of my assignment here, which conveys the significance I attached to this project at that time when I was coming in from the wilderness to rejoin the profession, somewhat reluctantly after an extended period of teenage rebellion.

But back to Karam. He has developed a method for switching the hosting style of Revit families which is well worth a look. I first became aware of this via a post by Luke Johnson. It's based on a  hack that's been around for many years which allows you to create loadable families that belong to system categories.

What Revit Wants

You start by creating an in-place family. Let's say you choose to make it a ceiling. If you make a group within that family, that group will appear in the Project Browser (under Groups). Now you can save a group out to an external file, and normally this would be a project. This is the basis of the "binding" workflow that allows you to convert links to groups and vice versa.

But, if you save the group while in edit mode, it becomes an RFA file, with the same category as the in-place family from which it originated. Voila! A most ingenious trick with unknown and potentially dangerous consequences.
Karam has created 4 such families and nested them into a generic model template.

Now if you load a ceiling hosted family, it will attach itself to the ceiling object. Delete the other 3 system elements, adjust the origin and save. You now have an un-hosted version of your original hosted family. You can watch Karam's video for further clarification.

Kconvert Video

It's very useful if you want a window to lie in the plane of a sloping wall or roof, for example.  The down side is that you have to link through all the parameters (something that Karam does at lightning speed in his video) and of course you get an extra layer of nesting, plus the fact that this is an unsupported hack. 

Actually you get two extra layers of nesting if you want it to be face based.  The saved "Kconvert" with the wall-hosted object trapped inside will come in perpendicular to whatever face you place it on.  Haven't quite figured out the logic of this, but Karam recommends nesting this into a face-based template and adding a void extrusion to cut your hole.  More linking of parameters, and it will insert itself into almost anything.  Quite neat.

Give it a go and see what you think. It may come in handy if you have a number of families that you really don't want to remake from scratch.  Let's say they are wall-hosted windows that you want to convert to roof lights.

Just in passing, my own approach to flexible hosting is to make families as un-hosted elements in the first place, then nest these into whichever template you need. There are two solutions to the parameter linking chore. You can make your nested component a shared family, or you can develop a system of standardized parameters and fixed naming of nested elements.

This is the basis of my modular door families which I  presented as a lab in Porto and will also be sharing at BiLT Asia in Singapore.

Returning to Karam's method, I wondered if this would help me to unhost the Duravit families I reviewed recently. You might not want these to be wall hosted. Let's say you want to mount them on timber panels for example. Or maybe you want to nest them into a family that incorporates a concealed system, boxed out with a tile facing and a marble shelf.

Unfortunately the Duravit families have dozens of text parameters, which would be very laborious to link. My first thought was to make the nested component shared, but that resulted in some rather odd behaviour. The nested component becomes invisible when shared. I guess the logic is that it is actually a wall-hosted element, but you have made it's host invisible. If you disable the visibility of an element from within family editor, you are basically excluding it from the project. It won't schedule for example. If you delete a wall, you will also delete any hosted elements. So Revit is refusing to recognize a wall-hosted element that has no host.

Now both Luke and Karam mention another hack for switching hosting behaviour. This uses the Copy-Monitor feature, and was described by Dave Baldaccino way back in 2014

http://do-u-revit.blogspot.ae/2014/03/creating-non-hosted-families-from.html

This turned out to be a very simple way of converting my  Duravit content because I already have a collection file. Simply link this into a blank project and run copy-monitor in batch mode for the plumbing category only. This creates a new collection file where all the wall-hostel elements have become face-based.

Now for the magic part. Dave mentioned in his post that if you delete the extrusion in a face-based family, it becomes a normal unhosted element. You can see this immediately in the properties dialogue which sprouts two new parameters. (tick boxes for workplane based and always vertical)

This set me off on a little adventure, cleaning up one row of my collection to make them "how I would have done it ". There are several steps.

 1. Delete the extrusion
 2.  Adjust the origin
 3. Standardise layer names
 4. Shorten family names

For the families that are already un-hosted I only needed steps 3 & 4. Similarly for the face based"vanity basins" which have a void in them to cut a hole into whatever surface they are placed on. I saw no reason to make a second version of these without the extrusion.

Just for fun, I took one of the unhosted families and nested it into a wall based template, making the nested element shared so that you get all the parameters. Seems to me that's how they should all be made. Then you can have wall hosted and free-standing versions in the same project that schedule correctly as being the same item. You could even make a third, floor hosted version if you really wanted. Perhaps you might need to place several of them on areas of raised flooring, split level bathrooms if you like.

Since I developed my modular door families I have started to see other applications for the same principles. Windows, obviously, but also classical columns where you might want to mix and match shafts and capitals, switch between different templates (architectural v structural, one level v two level) That's another post I think. Probably several. There will be another soon about classical columns, but also I think I should develop a modular approach to plumbing families.
Let's just set the scene with a little teaser.

Aaron Maller has weighed in with his firmly held belief that all symbolics are bad. Not sure if he extends this as far as door swings, that may be the one exception that puts his rule "to the test". (the original meaning of proves)

I agree with him that native geometry should be used for plans and elevations wherever possible. Don't spray masking regions and symbolic lines all over the place for no good reason. The geometry will always give you more predictable results. You won't see the front when it should be the back for example.

Using the geometry will work for relatively simple geometry and sharp edges. It won't look so good with smooth, rounded forms and complex curves. These are common shapes plumbing fixtures and soft furniture, resulting in lines of variable thickness that fade away to nothing in places. Your client on the other hand may be expecting crisp, even lineweights.

Another advantage of symbolics is the level of control you get for different scales. You can express a narrow groove as a single line at medium scale, and as two lines at fine. In the geometry, that groove is probably not a separate element. You can't control it's graphics independently for different scales. The whole thing is either on or off.

I doubt that I have convinced Aaron yet and I'm open to learning how to further reduce the need for symbolics, but here's  a diagram of my idea for modular plumbing families.

You separate out the geometry and the symbolics as two nested families. That way it's easy to switch off the symbolics if you prefer. For the geometry you can have different versions that you swap out depending on need and preference. Heavyweight v Lightweight, Mesh v Solid, CAD import v Native Revit, fixed v parametric.  The resultant plumbing family can stand on its own, or you could choose to nest it into a hosted template.  This hosting family would be a kind of ghost object, not counted in schedules.

I intend to develop this further in a future post. The idea is to make families more flexible, easy to change the hosting behaviour, easy to switch between lightweight and heavyweight versions, respond to individual preferences & project requirements.

So thankyou Karam, and all the other guys who contributed to this thought process which has progressed my understanding of hosted families considerably and occupied me productively, playing with Revit for a couple of days.  What joy!

I will sign off with a compilation of pictures from my only visit to Jordan, which was in 2011.  I really enjoyed the city of Amman, although my stay was far too brief.  It has a sense of history and culture that is harder to find here in Dubai.

STANDARDISED IDEALS

This is an older, dormant post from last year. I am posting it now as a follow-on to last week's discussion of Duravit families.  It's about the largest sanitary ware group in the UK who have made a huge commitment to BIM. Brands include Ideal Standard, Armitage Shanks & Twyford.  This post is mostly about Ideal Standard.

There are three distributions available, one through the NBS, one through BIMobject and one through bimstore.  The differences are minor but interesting. All the objects cite the manufacturer as Author.  The NBS versions also carry an NBS Certification number.  The bimstore versions carry a "distributed by" label.

They are all sourced from the same geometry, most of which is not native Revit.  The exceptions are the accessories (eg flush button & seat)  I am guessing that the curved geometry was created using Inventor, but it could be from Rhino or some other software.  Whatever the case, it came into Revit as a CAD import.  The main difference between the two versions is that bimstore have exploded the import to create freeform geometry. 

This makes the file slightly heavier, but removes some unsightly seams.  This makes for much cleaner elevation views, which can be very important on projects with an Interior Design component.

It would also make it possible to apply material parameters, but this opportunity has not been taken up.  In both versions, the material for the pan and cistern is baked in to the family.  Rather oddly, it is named "Snow".  I thought this might have been a manufacturer's euphemism, but the catalogues actually list the colour as "white (01)" 

That's the only colour option that is available so baking it in seems reasonable.  Except that the seat and the flush button have been given material parameters in some cases, and the material naming conventions are quite varied.  It's not obvious to me why you would need so many different material names for what is basically the same white glazed porcelain in different fittings from the same manufacturer.

Both versions have a detail item placed in floor plan view, which is also based on a CAD import.  This makes for crisp floor plans, but if you want to use over-rides it can be tricky.  Changing the colour of the category (Plumbing Fixtures) has no effect.  You have to go to "imports in families" and choose the subcategory "0"  If you want to control the lineweight or colour for plumbing fittings, you don't expect to go detail items or "imports in families" to do it.  Even worse, making changes in these other locations might effect objects in completely different subcategories.

The other point to note is that there is no masking region in the detail item, so tile patterns will show through.  That may be what you want, but it's not the way that I like it.  Also, because the symbolic work is in a nested detail item, graphics control gets complicated.  You have to look in 3 places to check on lineweights and colours.  Furthermore, in elevation views we see the solid geometry (not drafting) This results in uneven line quality, as well as visible seams.

Ideal Standard are quite right to boast "Ready When You Are".  They have released a very extensive range of products as Revit families and a lot of care and skill has gone into the preparation.  But of course it's not perfect, and I make these comments in the belief that a third party review is always helpful.

While I'm on this topic I should mention that the National BIM Library website is improving every time I visit it.  It's now very easy to see which families you have downloaded before, and whether or not there is an update available.  Selecting multiple objects to download as a single zipped package is also well implemented.  They are obviously in for the long haul, and committed to the idea of careful review and improvement based on user comments. 



The WC objects are packaged up so that the whole object reads as a WC pan, with cistern and seat as shared, nested families.  So you can schedule these separately.

I don't really understand why these families have been made as "Face Based"  Nor why the symbolic lines are nested as "Detail Items"

I would prefer to have a family that sits at floor level, rather than having to search for the correct "nominal height" then check that each instance in the project is correct.  I know there can be problems with wall-hosted families when copy-monitoring between disciplines.  I would be inclined to make all my plumbing families free-standing.  After all, you can always make it shared, then nest it into a blank face-based (or wall-hosted) template if you really want to.

Some of the families have visibility switches to allow for different combinations: optional configurations. Full pedestal v Half pedestal for example.

One of the big differences between these families and the Duravit collection is that these are based on solid geometry, rather than the surface meshes employed by Duravit.  Strangely, I have previously downloaded solid geometry from the Duravit website (SAT files) and used it to build families of my own.  Solid geometry tends to be heavier, especially if you round off all the edges.  Possibly this is why the Ideal Standard families contain sharp edges.  Even so, the average file size is higher than for Duravit.  Of course you get smoother curves, no faceting at all.  But perversely there are more unsightly seams.  So it's an interesting comparison but I think I'm inclined to go for the mesh.

I did some simple tests with 1500 instances of a WC family, timing the process of selecting them all with a window, and moving them by a few metres with two picks of the mouse.  The Ideal Standard families and Duravit families gave very similar results: about 35 seconds to select, and another 35 to move.  Setting the view to coarse scale had very little effect, despite the fact that the Duravit families display only a simple cuboid.  Also the results were almost the same, whether in plan view or default 3d.  The third test was made with a simple generic WC family.  It contains native Revit geometry: extrusions softened by void sweeps.  I made it two or three years ago and am very proud of it, but have never tested it's performance systematically before.  The results were dramatic.  About 1 second to select, 2 seconds to move.
 
These tests reinforce my suspicions.  Coarse scale representations are very useful in making drawings legible different scales, but much less effective in improving performance.  I don't see much point in the use of boxes to represent a WC at coarse scale.  Simple, generic, placeholder families however, do seem to be very effective.  In other words, the families we have been examining for Duravit and Ideal Standard are all very well, but in a large hotel or hospital project with hundreds of instances, it may be better to use a simple placeholder, with appropriate embedded data. 

Of course the geometrically accurate families would be really useful for Interior Design studies, detailed development of typical room layouts, and of course for any project where large numbers of fittings are not required.

But a word of caution.  Are these tests really meaningful?  Out of interest, I placed 20 instances of the Duravit family into a blank family template, loaded this into a project and copied it out 70 times.  When grouped like this 1400 instances respond almost as rapidly as my simple generic placeholder.  So maybe the tests say more about the behaviour of very large selection sets than the usefulness of these detailed families.

Finally I did a close study of one particular fitting, comparing the three versions in some detail.  Undoubtedly they are all based on the same geometry.  NBS and BIMobject simply organised their product data slightly differently, whereas bimstore chose to eliminate seams by exploding the CAD imports.

The naming conventions for the parent families vary somewhat, but the nested components retain their original names, which seem to match the NBS convention.  I added suffixes so that they would not overwrite each other. This could cause some confusion if you mixed families from different sources. The shared nested components could have the same name but different geometry (exploded in the case of bimstore)  Could be a toilet seat or a pedestal, any component that is common to several different products.  Seems to me it would be good to have a three letter code in the name of all families indicating the source.  This would protect against cross-contamination of shared nested components.  

When it comes to naming of materials and render appearances, once again there are long elaborate conventions.  Seems to me if you have a 3 letter code for the manufacturer (ISI) you don't need to follow up with the full name.  As you can see the names end up far too long to fit in the default dialogue boxes.  Then, just for a laugh, most of the white porcelain is just called "snow".  Wouldn't it make sense to have a target length for names, 32 characters perhaps?

Taking the bimstore families as an example, I have drawn out a full nesting diagram.  It's surprisingly complex.  I'm not sure why it was necessary for have separate detail items for the sub-components, basically duplicating the information in the parent family which has a detail item for the entire assembly.  Personally I wouldn't use detail items at all, nor would I use 2d CAD imports.  I would rather have a plumbing family with 2d symbolics inside, nested into the parent just as the detail item is.  Keep everything under the Plumbing Fixtures category to simplify graphics control.

The "fine print" in this diagram shows a set of jpegs contained in the bimstore package, including the suffix "bragbox".  I take this to mean they are proud of the better appearance resulting from exploding the CAD imports.

Final comment?  Everyone involved might reflect on the complications arising from three different organisations distributing the same content with minor variations.  I'm not blaming anyone, just saying that we need to acknowledge the learning curve still facing us all in the effort to create truly consistent content.

Oh, and the file sizes.  Solid geometry seems to result in almost double the file size, when compared to mesh.  Exploded geometry doubles the size again.  I'm voting for mesh. 

TOILET TANTRUMS

The need for better quality sanitary ware families has been a recurring theme on this blog.
For example, early last year I reviewed recently released families for Roca

ROCA POST

Back in 2014 I spent quite a lot of time trying to demonstrate the quality of Duravit content that might be made available to those who want to design stylish modern bathrooms using Revit.

DURAVIT POST

Well the good news is that last month BIMobject published more than a hundred Duravit families.  I was keen to take a closer look, so I downloaded most of them and carried out an analysis that I will share here.

First of all I want to give due credit to BIMobject for making this possible.  I have a pathological aversion to terms like "game-changing" but the truth is that they have had a huge impact on the world of BIM content.  Their major contribution in my view has been to bring so many major manufacturers to the party.  BIM is a journey, and without the manufacturers we will never reach our goal.  I can hardly imagine how much determination and persistence it took.  Certainly it's not the kind of thing that I'm good at. 

But what I can do is to review and comment from the point of view of an experienced Revit user and practising architect.  So what follows should be taken as constructive criticism of a job well done, but a "work in progress", which can surely benefit from end-user input on a regular basis.

I have placed the families I downloaded into a collection file and arranged them according to product family.  The first thing to say is that these are all based on CAD imports.  I know that many of you detest the thought, but quite frankly I don't see any other way to successfully represent the compound curves that so many plumbing fittings exhibit.  You only have to look at some of the native geometry used in some product ranges with their sharp edges and unsightly seams.  Yes you can get fairly close using conceptual massing, but who wants all their plumbing families to be adaptive components? 

So CAD imports have their down side, but now that we have learned to supress the polygon mesh edges, they do a pretty good job.  BUT you have to apply materials via object styles, which means that consisten naming of layers is important.

In most of these families, a porcelain material has been applied to the appropriate layer,  but in some the geometry is on layer 0, which resulted in no material being applied.  I have highlighted this by applying an orange material to layer 0 in the collection file.  This is easy enough to fix, but it turns out to be a little more complicated.  When I open the original families, there IS a material applied to layer 0.  The problem occurred because my collection file already had a layer 0 under "Imports in Families" (but with no material assignment).  So of course the project settings take precedence over the settings in the family being imported.

Another look at Object Styles reveals a deeper problem. Almost all the families use different layer names.  To correct this you have to open them one by one, and to decide on a standard naming convention.  I like to use "_Porcelian", "_Chrome", "_Plastic" etc.  If this is done consistenly, and the families are placed in a collection file, you can rename those layers for all the families at a stroke, from the master collection.

This brings me to another small quible.  I had to download these families one-by-one, and it takes about 9 clicks for each one, to download them and return to the source page. (select, download, download, save as, save, cancel, close, back, remove)   The best way seems to be to favourite a number of families to the "BIM Board" then download them from here, and remove them one-by-one as you download them.  I wish there was a button to download your current BIM board as a zipped package.  The NBS library has this facility, and it works well.  They also have a little symbol that shows you at a glance which families you have already downloaded.  BIMobject stores this information, which you can see as a list under your profile, but it's much more user-friendly to see it displayed on the product images.

You may not often want to download a hundred families as I did in this case, but sanitary ware for a hotel would usually mean a dozen or so items.  If you add accessories, it could easily be 30 or 40.  You really don't want to be downloading these one-by-one.

The families all have masking regions and symbolic lines in the 3 major orthographic views, which is an improvement on the last collection I reviewed.  Again, I know that some people argue against this, but if you need internal elevations details to normal Interior Design standards it's essential.
 

Coarse, medium, and fine detail levels are represented in a logical manner.  I personally don't favour the use of cuboids at coarse scale, but it is common practice so I'll let that pass this time around.

Next quibble.  Many of the families are hosted: face-based or wall-hosted.  They've done this with a nested component, which is good practice in my view, but the components are Generic Model category.  This means that any graphic settings you apply will not behave as expected.  You might be puzzled as to why some toilets have a heavier pen weight than others for example. It's easy to fix: open up the nested component, change the category to Plumbing Fixtures (Family Category & Parameters), load it back in.  Hopefully this will be fixed on the next release. 

Having made my collection, I ran a schedule.  This immediately showed up another small issue.  These families have not all been made using the same shared parameters file.  This has resulted in 3 sets of parameters with the same names, but different GUIDs.  It means that you can't get these items to line up in a single column.  This is unfortunate because the families come embedded with lots of useful data.  Also I couldn't easily tag these files because I didn't have the Shared Parameters file.  I could go through the process of making one, but this is quite laborious and doesn't solve the issue of merging the triplicate sets.  I'm sure BIMobject have the software skills to create an app that will process these families as a batch to correct this "triplication".

Another tiny grumble.  Do we really need 5 different render appearances to represent white porcelain?  I think it's just carelessness in naming actually, someone typed a space where someone else didn't.  It's a very common problem actually.  Very difficult to control with multiple users working long hours under pressure.  But once again it's easy to correct this from a central collection file.  Oh yes, and the white plastic shows up as grey in shaded views. 

Before I close, I want to give another plug for collection files.  They are so useful for giving an overview of the product range, for easily adjusting naming standards, for picking up errors and inconsistencies, for copy-pasting a group of objects into your project in a single action.  It's probably too much to ask for manufacturers to package up their products in this way (although one or two do) but I do like to dream sometimes :)

So all in all, this is a great set of content, that could be even better with a just a little more attention to detail.  Hopefully this can be picked up in the next round of revisions.  So at the risk of repeating myself, I think BIMobject have their priorities right:

1. get the manufacturers on board,
2. build up a substantial library of content with a strong user base,
3. gradually improve standards and quality based on industry feedback. 

They've come an awfully long way over the past 5 years or so.  Imagine how far they can go in the next five. 

So thankyou Stefan, and please take these comments in the spirit intended: one of appreciation and positive encouragement. Oh, and by the way, here's a shot of me and Stefan sitting side-by-side at BCS in Porto last October.  The guy with the mike is Aaron Maller of course, and Stefan has an emoji over his face to indicate the passionate nature of the discussions taking place ... not my emoji by the way, I snipped this from someone else's tweet.