Thursday, 17 October 2013

Navisworks 4D IFC

At the BIMDayOut event earlier this year (great event, hope it runs again next year) I presented some 4D IFC workflows from Grasshopper to Constructivity (still the only other software I know of reading and writing IFC4).  It was really encouraging to be able to show a virtual construction sequence in Constructivity but I found the software had issues with large scale geometry and strict requirements for the way data is defined.

What I've been working on now is an IFC import enhancement for Navisworks Manage 2014.

At this point in time, you can't create products in Navisworks from the API, but if you import the IFC using the native importer (IFC2x3 only), then you can run my IFC enhancer (plugin can be downloaded from ) which can generate the timeliner tasks and identify the ifc products by their unique identifiers.

Grasshopper Definition  IFC file

I hope to improve further the sequencing calculations and add cost data.  If you have requests or suggestions, let me know.  I will also consider developing a similar utility for VICO or other software if the demand is there.

Thursday, 10 October 2013


We were lucky to return back to London recently for my brother's wedding.  Being August and summer, it was a great time for a wedding but not the ideal time to try and meet lots of existing and potential users of the Geometry Gym tools.  I did manage a few meetings and Simply Rhino organized 4 computer lab sessions for those interested to not only view but try hands on application of the tools (This worked quite well and is something I'll look to repeat if I'm visiting other cities).

I was asked a few times about model exchange Grasshopper to AECOsim and it's something I've made a start on testing.  As per all BIM software, they do have IFC coordination import/export, but I've made a start on using the ISM as a basis of generating structural model data from IFC (grasshopper generated or not) into AECOsim and various other software interacting with ISM.

Here's some prototype models.  Curved members are coming quite well into AECOsim.
I tried my klein building slabs and they preview well in ISM viewer, but causes some errors when importing the ISM into AECOsim (Bentley will hopefully advise soon).

If you're interested in testing this work flow, please get in touch.  Initially this will be structural based but I am keen to enable other disciplines and data if demand is there (ISM has provided a fast means of getting started with a strong overlap of IFC structural data).   Of course Bentley have Generative Components as a very similar tool to Grasshopper, but freedom to exchange models across platforms can enable very powerful work flows.

Wednesday, 9 October 2013

Parametric IFC

There's been a few private and public discussions about Parametric IFC and IFC for Content.  As a prelude refer to and perhaps we need a twitter hash tag?
Manufacturers and suppliers are caught in a difficult situation at the moment about generating BIM data and leveraging the best value (and success) in doing so.

There is obviously a cost in preparation and there is little choice at the moment but to either generate pick which BIM software that native content can be created for or generate IFC as neutral data.  Budget, time and expertise constraints make it highly unlikely anyone will author native content for all BIM software (and is a lot of duplicated effort).  Current BIM software capability with IFC is presently leads to a lot of frustration and poor performance, but I don't think it has to be that way and will try to convey that with this blog post.

Let's start with the cistern family that Martijn refers too.  You can download this as an IFC file or Revit Family from
Martijn comments that the IFC file has 2640 lines of IFC to define it (actually the version I just downloaded has 2118).  The authors at National BIM Library have used the faceted brep  shape representation to define the geometry which is pretty typical of IFC files to date.  The geometry is effectively meshed into planar faces.  When you do this, you loose the parametric and intelligent aspects of the geometry (ie, if I want to now make the flush pipe change diameter, it's a near impossible task to relocate all the vertex accurately into the new positions.  Perhaps some manufacturers/suppliers prefer this as it means the content is "protected" but it does come at a cost.

I haven't sought permission to "edit" this file (if someone has a problem, let me know), but I substituted the geometry for extruded area solids and swept disk solids which retain parametric geometry.  You can download this IFC file here.  By replacing the shape representations with more intelligent and accurate shape representations I reduced the file to 357 lines of IFC of which a lot are property values.  If you've had bloated IFC files gigabytes in size, a lot of this can be attributed to meshed hand rails and the like (Please request to your BIM  software developers to implement and utilize swept disk solids).  I actually did simply the shape of the cistern a little, not because IFC isn't capable, but because certification requirements of IFC software do not require the implementation of IfcExtrudedAreaSolidTapered which would more accurately and efficiently the tapered cistern.  This would have added about 30 more lines to the IFC file (and I can post if requested).

Now, here's where using IFC gets frustrating.  We have this more intelligent and accurate IFC file, and it doesn't work very well in trying to use it.  I tried all the IFC software I have to hand, Revit, Archicad, Tekla Bimsight, DDS Viewer, Solibri, Constructivity and all of them displayed non or only the cistern part of the geometry.  I put this file through the Building Smart verification tool which indicates only inherited errors (that didn't prevent the original file being used).  The fact none opened the file suggests it might be a problem with the file and I will be most grateful to anyone that can identify this (maybe it's my curve parameterization, I'm aware that my IFC is not yet perfect).  You can of course test the file with my rhino3d importer.

Now if you wanted to change the geometric diameter of the pipe, you could open the ifc file in a text editor like Notepad, and set line
#3674= IFCSWEPTDISKSOLID(#3675,15.0,$,0.0,94.0000000000002);
to something like
#3674= IFCSWEPTDISKSOLID(#3675,40.0,$,0.0,94.0000000000002);

Download the revised file here.  In one quick step I changed the 2nd field for radius from 15mm (30mm diam) to 40mm (80mm diameter).

Now, what we really want to do is drive content as we can in Revit (and I understand, GDL in Archicad) from parameters.

An IFC pipe segment (or type) can have a  property value stored in the common property set for "Nominal Diameter"  What would be nice is to change this value (akin to changing a parameter on the family in Revit) and have the geometry and any calculated values update to this change.
IFC as presently defined does not have this capability, but there is a very interesting proposed extension for IFC to do just that.  I don't know any software that has implemented it (really users are going to have to demand it) and I thought I'd implement file exporting to demonstrate it.

Download the IFC file here.

So if you read the IFC, you see I've bound the property single value to the circle hollow profile def radius, with a formula to adjust by a factor of 0.5 (to adjust from diameter to radius).  It would be possible to define formula relationships and the like (akin to Revit and to my knowledge GDL) and have them converted from the IFC file into the native equivalents.  (Grasshopper definition if you want to test, the components are hidden from the menu at this stage).

So, if the industry wants to generate more intelligent model content, and use it in a wider variety of software and contexts, it would seem a good idea to get on and implement (and improve) this extension.  Note also this extension can provide provision for constraint relationships.

To quickly address the comment from Martijn about "IFC is meant for Projects), this is perception rather than technical intention (Refer definition of IfcProject here). IFC4 does improve this situation, where a project can declare "types" without populating an instance of this in space.

I state all the time, IFC isn't perfect.  But it is capable of a lot more than implementation demonstrates at this point in time.  And before we can really work on improving it, we really need to be able to test and utilize what it is already capable of to identify improvements and shortfalls.  I look forward to discussing further.