Sunday, February 19, 2017


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. 


I've been getting a lot of spam so had to tighten up comments permissions. Sorry for any inconvenience. I do like to hear from real people