In this final piece in this series about some of the main improvements to IFC and COBie workflow (there are more of course around openBIM) we will look at the enhancements that have been made to geometry export settings. (This piece is primarily focussed on IFC but in time I can see how these changes will also benefit COBie workflows, particularly with regard to the Assembly Worksheet). The new features might be missed by some users but these changes really are going to have a significant impact on the quality of the models we export to others.
To understand what impact these changes have we need to go back almost 3 years! Back in early 2012 we were working on a project for Bradford College with BAM Construction (see also our earlier blog piece Vision to reality: Bradford College case study). The project was started in 2010 and construction of the model was commenced in 2011 whilst developing the design with the client.
This was the developed model we had built in Graphisoft ARCHICAD 15 for the project by the time BAM were appointed:
Image: The native Bradford College model in Graphisoft ARCHICAD 15
For 5 years (since 2007) we had exchanged IFC models with other consultants without much issue and then we had a phone call from BAM to tell us our model was ‘white’ and was unusable. So we immediately went off to look at the IFC we sent them. We opened this in Solibri as this was a neutral viewer and this is what it looked like:
Image: Bradford College IFC model in Solibri Model Viewer
Its fair to say it wasn’t perfect but it was perhaps a bit of an ‘exaggeration’ to say it was unusable. So we went to see BAM to discuss why the model was unusable and what they really needed. It just so happened that Tekla were at the same meeting to discuss other BIM workflow issues. We got into conversation and BAM were still insistent that the model was ‘white’ and unusable. Tekla asked if they could open our IFC and quickly flashed up our model in Tekla BIMsight (their free IFC viewer):
Image: Bradford College IFC model in Tekla BIMsight
Again, the model was by no means perfect but it was not too dissimilar to the Solibri model. BAM however were using Navisworks 2013 and they put up on the meeting room screen the version they had received. This was the result:
Image: Bradford College IFC model in Navisworks 2013
Now I think it is fair to say that yes it was ‘white’ and yes it was pretty unusable!!! There was no denying that. Instantly it became clear though that this was not actually an IFC issue but one of translation and interpretation by the various software solutions. So we turned to social media for help. Almost immediately we got a response from Adam Ward (@Revitspace) from BIM.Technologies who suggested we try putting it through another piece of software called simplebim (produced by Datacubist). This had the ability to interpret the IFC file and push the colour data into the required fields for Navisworks to understand. So we went off and exported the model through Datacubist simplebim. This was the result:
Image: Bradford College IFC model in Navisworks 2013 having been taken through simplebim
This was instantly better (although glass was still an issue) and much closer to the results we had had with Solibri Model Viewer and Tekla BIMsight. This made the model at least usable even if it was still not perfect.
The issues were reported immediately to the Navisworks team for resolution. During the project, in early 2013, an updated version of Navisworks (2014) was released and this meant that we no longer needed to go via simplebim to provide our model. This simplified our workflow and gave BAM the model they could use for their needs. This gave us this:
Image: Bradford College IFC model in Navisworks 2014
Now many of those in the openBIM camp at this point would say well of course it didn’t work as Autodesk are the ‘evil empire’ and they don’t care about IFC. I think Autodesk’s response to the issue highlighted that they were willing to respond to issues if they know about them. This is the same for all the vendors. IFC has got a bad name for a number of reasons but fundamentally requests for IFC enhancements are no different to any other bug reports or feature requests and software development is ultimately shaped by its customers needs and requests.
What also became clear during these model exchanges was that not all the colour issues were being caused by the receiving applications. The model colour still wasn’t what it should be so this got me interested in finding out what would transfer. So I went off and created a simple test file with cubes with every out of the box Surface applied to each face. I then exported these to various software solutions. This confirmed that some software handled these differently but still didn’t explain why some colour was lost into some of the viewers.
Image: IFC test file using all ARCHICAD default surface colours to all faces of every slab material in the out-of-the-box ARCHICAD template
I went back to the ARCHICAD model and looked at the elements where colour transfer was an issue. I then came up with a theory which needed me to tweak my original test file. The theory was that the reference side (the top in this case) was determining the colour that other software was interpreting. So below is the ARCHICAD file with the top face changed to white and then re-exported to Solibri. What we found was the colour was lost.
Image: IFC test file created in ARCHICAD where top surface is changed to white (this is the reference plane)
Image: IFC test file using all ARCHICAD default surface colours to all faces except one and its appearance in Solibri Model Viewer
We had discovered what was controlling the colour and then having asked Graphisoft we got confirmation that IFC supports only one colour per body. This basically meant that a Wall in ARCHICAD would only transfer one colour, which would always be the reference side surface. As the internal face of our external walls was acting as the leading edge the exported wall would always be white rather than the Surface colour we had chosen.
Image: ARCHICAD 17 Composite Wall export
We therefore looked at how we could export the individual skins in order to ensure we could deliver the requirements of BAM and other major contractors. This resulted in a decision to model external walls as a series of skins. This had massive impact particularly when it came to modelling openings such as doors and windows. However as a business we have always endeavoured to deliver the requirements of our clients, and that includes contractors. This change was painful and not without its own issues.
So whilst there had been an issue identified with Autodesk Navisworks it was clear that the issue needed to be resolved at the export side. So like all our of our IFC testing the most important thing was to raise this issue. We were invited to speak at Graphisoft’s Key Client Conference (KCC) in 2012 and used this platform to highlight this major issue. The need to export each skin individually from a Composite Wall would provide the solution we needed to avoid unnecessary modelling effort. Like many developments this was not a straightforward fix and we had missed the development cycle for major improvements for ARCHICAD 17.
Now with the release of ARCHICAD 18 this workflow issue has been resolved. The new IFC translator export setting “Explode Composite and Complex Profile elements into parts” means that each body, the skin of the wall, can be exported individually (or still as a single element). We can now go back to using Composite Walls!
Important note for transfer to Revit: If the “Explode Composite and Complex Profile elements into parts” switch is used when linking a model the Parts will by default be switched off and will not be immediately visible in the Revit model. These elements can be viewed by using Parts Visibility.
Image: A Composite Wall built in ARCHICAD 18
Image: The same Composite Wall exported as an IFC and opened in Solibri Model Viewer
The other added switch that was also part of our discussions with BAM was how do we reduce the number of clashes when checking a federated model. As the wall was exported as a single element it meant that every column ‘clashed’ with the wall. This was the same for every Composite type of element. With ARCHICAD 18 there is the ability to switch off the cavity at export. This is done by creating Building Materials that have a check box to say whether the material participates in collision detection or not. So a Cavity (or Air Space) can be set as not participating and then when using the Geometry Representation export settings in the IFC translators you can select “Export geometries that “Participate in Collision Detection only”.
Image: ARCHICAD 18 Geometry Representation Export Settings
So the lesson learnt is that by really focussing on the detail of the issue, rather than sweepingly asserting that IFC doesn’t work, we can report these issues and find the right people and companies to resolve these issues. ARCHICAD 18 fixes and simplifies another workflow and process issue that makes IFC exchange smoother for all.
One final note that because colour is fixed from Graphisoft ARCHICAD into Autodesk Navisworks it doesn’t mean that colour transfer is fixed for all software and we recently came across a similar IFC transfer between Autodesk Fabrication and Autodesk Navisworks. We also have some issues that need to be resolved in Solibri for objects such as doors, windows and furniture. We keep reporting these issues to the appropriate vendor and slowly but surely these issues disappear to the point where we are now down to minor exchange issues from ARCHICAD.
Rob Jackson, Associate Director, Bond Bryan Architects