Hi all, I have a project that uses multiple .ifc models from non-Revit capable parties. The workflow to date with these .ifc files has been to link these into a single host model, bind the links and then distribute the single model out to the design team. I've noticed an error creeping in when performing the bind where certain .ifc elements are being swapped out for different .ifc elements. It is apparent that some form of duplicated identifier in the element is telling the bind action that the element type already exists in the project and chooses to use this instead. The trouble is, the substituted elements are nothing like the required representation. The attached images show the extent of this where the circled items in image 1 are the substituted elements, the highlighted element in image 2 is one of the elements before binding and image 3 is the substituted element after binding. I have tried all manner of things to prevent this but nothing seems to work. I understand this is an issue others have seen before - any suggestions as to how to get around this?
Have you tried instead of linking the IFC files in the host model:
1. Open the IFC files separately in Revit (File - Open - IFC)
2. Save them as Revit projects
3. Create a new host project
4. Link the Revit projects you saved.
5. Bind those links.
Hi @chris.edwardsR3BJR
Thanks a lot for posting your question to the forums! Has the solution suggested by @juhani.alasalmi helped with your issue?
We look forward to hearing back from you with more information so we can help you as a community!

Jonathan Hand
Industry Community Manager | AEC (Architecture & Building)
Hi @juhani.alasalmi , I should have elaborated on this first step. The linked .ifc models are actually generated as new, stand-alone models on every occasion. The process here for each individual .ifc is to create a new blank or un-templated project, inset/link the .ifc file which of course then generates a new .rvt for each .ifc (the ones that generate using the xxx.ifc.RVT suffix), and use this new .rvt as the link in the host or federated model. Over the years I've noticed this technique effectively removes the well known issue with 'fractured' geometry that is created by directly opening the .ifc file. I believe this issue (see screen shots with a good import (insert .ifc.) vs bad/fractured import (open .ifc)) is related to the geometry and origins being too far apart where the graphics engine is showing the error creep due to distance to origin. I don't know that using the 'open .ifc' version would offer any difference to my exact problem. Is there knowledge around this or is this simply a suggestion?
Sie finden nicht, was Sie suchen? Fragen Sie die Community oder teilen Sie Ihr Wissen mit anderen.