IFC round-tripping

VisualARQ
,
1

Can I expect to open an IFC file, make a change, and save the IFC file with 100% certainty that I won’t lose any information? For example, I’d like to optimize the geometry within a Block Definition or modify some parameter values. However, as I mentioned in the introduction, I need to ensure that the IFC hierarchy and all data are preserved after resaving the file to IFC.

From what I’ve experienced so far, a resaved file viewed in BIMCollab Zoom doesn’t display the same hierarchy in the tree, and elements aren’t assigned to building levels in the same way.

Is lossless round-trip possible for IFC files, and if so, is this the VisualARQ team’s goal to provide?

3

Hi @Czaja,

Any import or export process between different file formats or applications will inevitably result in some loss of information, or at the very least, in certain changes. This happens because it’s usually not possible to represent the exact same data from the source format or application in the target one.

In this case, converting geometry from IFC to Rhino involves changes in many aspects. Visually, objects may look the same, and the geometry might appear identical (within a tolerance), but some IFC object types simply cannot be represented in Rhino. A simple example is a sphere (IfcSphere), which has no direct representation in Rhino. Instead, we must use either a NURBS surface, or a revolved surface generated from a 360º arc. As a result, when exporting this geometry back to IFC, the output file will inevitably be “different.” The same happens in the opposite direction: some Rhino geometry types don’t exist in IFC, such as NURBS surfaces (in IFC2x3) or SubDs.

The same issue applies to many other aspects: materials, attributes, concepts such as “By Parent” or “By Layer,” parameters, data types, object hierarchies, units, and so on.

Trying to make Rhino work as a true IFC editor without any changes is, in my opinion, either impossible or extremely complex. Only an IFC editor designed from the ground up with that purpose could realistically avoid losing or altering IFC data.

Currently, our approach is to import all the IFC data we understand and support, and discard the rest. VisualARQ is not an IFC editor — it’s a BIM application with the ability to read and write IFC files.

And I want to be honest here: our long-term goal is to minimize data loss as much as possible when importing and exporting IFC files, but I don’t think it will ever be possible to completely avoid it. I’d rather be sincere about this than make false promises. I also believe this situation is the same in every other BIM application (ArchiCAD, Revit, Tekla, etc.).

Enric

4

You may also want to test it in different IFC viewers. I’ve noticed that sometimes doors will come in flipped in BIMCollab but not in the Autodesk viewer, or vice versa. When I am sending folks project for revit it seems the autodesk viewer seems the closest (but not perfect) to what they will see when they import it into revit.

5

Thank you for your detailed answer. I think I understand your point and agree with it.

I’m wondering if some value or geometry swaps would be possible if we bypassed importing and restoring geometry in Rhino and kept it entirely in Grasshopper, but that’s more of a question for @jonm and GeometryGym. It’s a procedure where, almost like a surgeon, we carefully cut away only the necessary amount and make any modifications only at the point of operation, without modifying the rest, then close the whole thing and export it.

Regarding VisualARQ and its IFC-related capabilities, I’m actively testing them. I’ve sent a file to the @fsalla that would be worth checking out and started several threads with various issues. Thanks for all your help.

Thanks for this tip. I will check it in some spare time.

In general, I’d like Rhino to work a bit differently when it comes to overriding object appearances based on the view (I’m talking about Model Views, not Detail Views, which we don’t have that much control over and don’t work well as a Viewport for 3D navigation). Then, thanks to Grasshopper, Rhino would be great for analyzing values ​​assigned to elements in IFC models.