@claimred Correct, that is the source
1 Like
One of the challenges you have is describing what constitutes a difference!
- We assume GUID is stable (same object always exports with same GUID - initially this was not always implemented in software). But if I create 100% the same object (properties, geometry, location) in the same software as you do, we both generate a different GUID. Does that imply a different object? I’m not convinced, personally.
- Number and Name and Description and other identifications occur both on Type and on Occurrence level. This may change or not, but is mostly independent from geometry and even properties.
- Geometry? This is very dependent of the IFC export settings (e.g. you can export the same geometry in different ways AND you can export different geometry in the same way if you go to BREP) - Not every modeling method in the native software has an equivalent in IFC. Even the way we create a BREP and the more parametric geometric descriptions (e.g. extrusions, sweeps, CSG) can lead to huge differences. That is even before taking tessellation into account.
- Properties? We have both the predefined buildingSMART property sets (with some possibilities for local interpretation), and in some cases local-standardised sets. And a lot of project- and company specific properties (alongside the software-specific properties).
- Base Quantities? While defined by buildingSMART, we notice huge differences between software: not all quantities are filled in and since the method of quantity calculation may differ from the native software, this is not always visible for the user in the native software. E.g. the “NetSideArea” for a Wall may not have an equivalent native quantity calculated following the same method, so we completely rely on the native software correctly following the buildingSMART method and calculating this upon export (only visible for the user in the IFC output)
This is complicated by the fact that every software is free to organise the IFC export how they see fit. The order of entries is irrelevant, the STEP ID (#123) doesn’t matter.
So all in all, I mostly see difference tools being useful to compare “versions” of a model coming from the same software.
So, this is bSI’s and software vendors’ problem
This is why still “few” who know IFC well say “IFC is not explicit”