Friday, 27 January 2012

Revit IFC Plugin by Geometry Gym

I've recently been advancing development on a tool/workflow that's really needed to use Grasshopper to somewhere near it's full potential for Architecture/Engineering.  And that's to export the model into other BIM software with strengths and functionality that are not always evident or easily accessible in Rhino.

I started developing my IFC (neutral BIM format Industry Foundation Class) plugin (within Rhino/Grasshopper software) with the intent of enabling generation of BIM attributes and relationships to the already powerful geometric tool that is Rhino/Grasshopper, and then utilizing this in other BIM software without having to model everything again from scratch, and then maintaining/coordinating multiple models.

I touched a little about the current use of IFC as a model exchange in my technical paper last year.  Presently to be IFC certified (and there is a current drive to improve on this) you effectively need to import/export IFC models for coordination.  This can be done (with accuracy but certainly not efficiency) utilizing only two shape representations, linear extrusions and meshed/faceted breps.

This has led to a chicken/egg scenario, where BIM software vendors haven't imported advanced (and more efficient) shape representations (IFC is based on STEP model specification) because other vendors haven't exported them, and vice versa.

So whilst there is a long list of Software that interacts with IFC, it's really difficult (and I've discussed this with a number of big and small design firms in the past year or two) to use this "bridge" as it's intended.

Autodesk Revit is a very popular tool for Architects/Engineers to document and detail their projects.  However testing of means to import models using neutral BIM formats (primarily IFC and SDNF) hasn't resulted in much to boast about and utilize.  SDNF can generate native beam elements but can take hours (without succeeding) to import a pratical size roof model.  The Autodesk IFC plugin import generates reference objects, useful for coordination, drawing and even schedules, but as soon as you wish to edit or manipulate the objects, you nearly need to model it again (as families aren't utilized and aspects such as analytical representations not created).

So, with a few Geometry Gym users looking for a work flow to get Grasshopper models into Revit, I've been looking for improved ways to do this using the Revit SDK.  I started looking at direct model interaction, but for technical and practical reasons have decided a neutral bridge is the best way to do this.  Most of my c# IFC code is reusable (with some interaction changes) as a Revit plugin (this is my first plugin outside of the Rhino/Grasshopper environment), and I've today posted an example import of a steel frame roof (British Museum Great Court Roof) using my own IFC engine.



There's lots of improvements and work to do, but I'm confident with time I can create a powerful IFC engine within Revit (as I've already achieved within Rhino/Grasshopper).  The priorities for improvements are being driven by real project use of this tool (let me know if you have your own use for it) and will include curved members, orientations and synchronization options.  If you look closely at the image you'll see Revit has still tried to be clever with the bevel/miter at element connections, hopefully I can find a way to disable this (as an option) as I believe its significantly part of a slow import process.  Other objects including slabs, walls, MEP, etc etc will also be quickly added to the toolset.

It will be interesting to encounter the other hurdles and pitfalls in front of this development, but stay tuned to the blog for public release of this tool and examples of it's use.  Feel free to get in touch to learn more (and influence it's development) in the interim.

14 comments:

  1. Nice work! Can't wait to try it.

    ReplyDelete
  2. good job.....knowledge sharing is always profitable to all of us...

    ReplyDelete
  3. I have been using IFC files to clash against architectural elements, working to coordinate mechanical shafts. I haven't had much use for IFC files, but it seems to work best when inserting information back into a Revit "container" file. However, when I import the IFC file all the model information is dumped into Generic Model. It would be great if you could keep a database info in the IFC when you import it into Revit.

    ReplyDelete
  4. Hi Daveo,

    Thanks for the comment. Your experience of using IFC for coordination and model overlay is typical of it's use for date (IFC certification for software companies has been for coordination model).

    But my personal project experience has always been trying to minimize the number of times an aspect of a project is modeled, and that is the premise of model exchange using IFC.

    Lots of early project work is being down in software such as Rhino/Grasshopper, or sketchup or .... and it's not effecient use of man power to trace or start modeling from scratch if the project has reached a stage where it needs BIM software such as Revit.

    Building Smart Certification is also changing to a model exchange which is great to see. I will be considering means of IFC data retention in Revit, but the real focus is to as many native Revit objects created with attributes to use the software as intended.

    Cheers,

    Jon

    ReplyDelete
  5. Great Work Jon,

    Looking forward to the day this becomes a two way process with Revit, I have one question though, did the member sizes in the Revit model come from Rhino/Grasshopper or are they applied to the exported geometry once inside Revit.

    I also see Revit has played its usual trick of pulling apart the beam end joins randomly, in my experience it also does this when 3D snapping beams to mesh stick geometry imported from .dwg and can be a real pain to get the result you're looking for.

    ReplyDelete
  6. Hi David, I look forward to that day too, hopefully sooner rather than later.
    The plugin at present creates (most) profile shapes as a family from the IFC data, or uses existing family if the same name already exists. It doesn't validate "consistent" profile shape yet, but I hope to develop that.

    The beam end joins are a problem, they slow down the process and don't produce great results in this example. I have requested to Autodesk a mean to disable this (for early scheme design overlap would be acceptable) and hope to be able to override this junction data if it exists in the IFC data. Not sure how quickly this will be enabled but customer support will help.

    Cheers,

    Jon

    ReplyDelete
  7. Great work! Definitely has lot of potential. Can't wait to try it!

    ReplyDelete
  8. Hi jon

    Great work, I was wondering if you have tested IFC in Bentley Architecture (or AECO Building Design)?

    This might be not needed as for Revit, GC has implemented BIM features allready, but I would love to play around, mixing GH and Bentley BIM software package.

    ReplyDelete
  9. Hi Pep,

    I welcome and encourage you to test interaction of GH generated IFC models with Bentley. I don't have access to this software so I have no idea of the level of comprehension they have developed their IFC engine.

    Other users are doing similar with Archicad and Digital Project. I will consider in time developing plugins for other software to import IFC as required. I chose to do Revit first and foremost due to it's popularity and the ability to adopt my C# engine.

    I'm happy to assist and advise with users of any BIM software out their in the process of model interaction.

    Cheers,

    Jon

    ReplyDelete
  10. I am finding it impossible to load grasshopper for Rhino. Its a great option!

    ReplyDelete
    Replies
    1. It's probably the c++ runtimes, refer http://www.grasshopper3d.com/forum/topics/loading-error-unable-to-load-dll-rhcommon-c
      Feel free to email me with any error messages if this doesn't help.

      Delete
  11. Hi Jon,
    By any chance you are releasing your C# IFC engine as an open source project?
    Le

    ReplyDelete
    Replies
    1. Hi Le,

      It's not impossible that the project could be released as openSource, but at this stage it's highly unlikely. I rely on revenues from licensing to commercial users to sustain full time development of it, and I'm not confident there is means to continue if it became openSource. You should take a look at the IfcOpenShell as an option for open c# code.

      Delete