IFC files can be published to Assemble via Autodesk Revit. IFC files are created from a multitude of authoring tools, such as Tekla, and presented in IFC format with the goal of being a "universal" file format available for most major design tools.
As IFC files are imported into Revit, objects are assigned a unique identity ID, or source ID. When the model is published to Assemble, we will retain the same source ID that Revit assigned the objects.
As the project's life cycle continues, updates will be made to the model, typically using the original authoring tool. The design team again hands off the model to designated parties as an IFC file.
When a new version of the IFC is linked into Revit, the objects again are assigned a unique ID. Revit may interpret this file as a new, uncharted file, treating each new import of the updated IFC file as a new model, and thereby assigning new, unique instance IDs.
Additionally, authoring tools typically have their own naming and organizational structure, which often do not translate to Revit's concept of names, particularly family names. Revit has a vast library of families and types, as well as allowing users to build their own families. As do other applications. Unfortunately, the translation from one authoring tool to another authoring tool via IFC can get messy.
For example, a model with custom designed curtain panels designed with Inventor can be exported to IFC. When Revit sees these curtain panels in the IFC, the objects will likely be classified into the category of "Curtain Panels" but the family name may become unique for each instance of panel, such as CurtainPanel201, CurtainPanel202, etc.
These translations cause limitations for Assemble, as Assemble relies on family names and source IDs for a multitude of actions, such as comparing model versions, syncing properties, and organizing the model inventory in the Model Tree.
The limitations include:
1. Comparison between model versions may show every object as either added or deleted. Why?
There are no matching source IDs between versions, based on how Revit interpreted the IFC file. Although the comparison feature of Assemble may become less useful in this scenario than with native Revit files, we recommend utilizing Assemble's "Export to Navisworks Search Sets" as an alternative. You can assign IFC objects to custom Assemble Properties, and then group, filter, and export an XML file to Navisworks.
2. Attempting to open models may become very slow or even cause your browser to time out before the model has a chance to load. Why?
Assemble organizes objects first by their Category Name, then by their Family Name, and finally by their Type Name. With thousands of unique family names coming from a published IFC, the processing of information takes a longer time than when multiple objects are grouped into common family names. This strenuous passing of information can cause poor or slow performance, or may even cause the browser to time out and crash.
3. Syncing properties from an older version in Assemble to a new version of the model in Revit is limited. Why?
This again is due to the inconsistency of source IDs. When Revit assigns new instance IDs to a newly imported IFC file, those IDs will not match the IDs stored in Assemble. Assemble has apples and Revit has oranges, and those two things just don't match up.
IFCs created with non-Revit authoring tools can still be used and transferred to Assemble. Just be aware of the limitations and be willing to find necessary work-arounds to get your desired results.