Knowing the material layers of objects (e.g. wall is 1 layer plasterboard, 1 layer stud, 1 layer plasterboard) is one of the most important, fundamental aspects of BIM model exchange.
The IFC4 Reference View MVD is the only IFC4 MVD that has a “final” status. Therefore, this is pretty much the only type of IFC4 data that we can get from people still trying to play nice with the whole MVD concept.
The IFC4 Reference View MVD does not include material layers.
I think this is a problem. Enough that we cannot specify this MVD any more in contracts because it basically means any vendor producing this MVD is not producing useful information for us.
Here is my understanding from an implementation perspective, let me know if that makes sense.
It’s not exactly easy to rebuild true multilayered element geometry using IfcMaterialLayerSet. That requires a full-blown modeling system and looks out of scope for RV, though that makes complete sense for DTV. For one thing, receiving app must be aware of multilayered wall joins which is a world of its own.
On the other hand, IfcMaterialConstituentSet+IfcShapeAspects (i.e. generalization of layers) mechanism with separate geometric items for each layer is much more straightforward for receiving applications to process and use for reference purposes. Exporting software is sorta forced to bake complex implicit layered geometry into explicit (i.e. reference) when using RV.
I vaguely recall reading @TLiebich explanation somewhere but can’t find it.
hi, sure - the best explanation is included in the IFC4 Reference View documentation. See here. Hope, this is what you are looking for.
Otherwise I agree, the use of material layer set is limited for any kind of non-standard wall configurations. Therefore we had changed the implementation preference towards material constituence set for IFC4 RV.
Thanks @TLiebich and @claimred ! Indeed I certainly see the technical logic behind it, but that wasn’t the point I was trying to make unfortunately.
The point I was trying to suggest is that DTV is still in draft status. This doesn’t matter to me personally - but there are people who specify contracts who only look at what is certified and in final status. RV is the only MVD in final status. The issue here is that no alternative to RV is stable for the market - which means that almost nobody playing by the MVD rules can produce IFCs that contain this quite fundamental BIM semantic (technical issues aside for viz and joints, from a non technical user perspective the value is in the thickness attribute).
So to rephrase my original question, is there a timeline for bS to finalise other RVs? IFC4 has been around a while - how many years do we continue to wait for another MVD? In the meantime, do we stay on 2x3 or do we ask vendors to ignore the MVD certification concept and give us the options we need (e.g. in Revit we select the DTV option regardless of certification)? Should users deviate from MVDs? How many users realise they are missing this data when they blindly copy paste contractual requirements? (It is not easy to discover for non IFC gurus)
Pure technical reasons- agree. Combined with the glacial certification process and worried about real life industry impact on the usefulness of IFC? Yes.
Hope that clarified my concerns. I hope there is a stopgap measure. My measure has been to actively discourage RV MVD specification in contracts, and encourage DTV, which nobody is “officially certified” for.
What further complicates this matter is that if users like myself realise that RV doesn’t give them what they need, the bS website gives no link to the draft documentation for DTV. This means that if a user says “well, RV isn’t good enough, give me DTV …” this user has no idea what will come out the other end! Nothing is publicly documented!
Initial testing in Revit shows that layers come through in DTV, but is this a Revit thing, or a MVD thing? Not sure.
What if DTV is also insufficient (e.g. if it mandates CSGs? This makes it impractical for projects that deal with a combination of designed and existing dilapidation survey). Then do users simply forego MVDs altogether, or do they forego IFC altogether?
from a non technical user perspective the value is in the thickness attribute
Speaking specifically about layers and transferring their data, I was under the impression that it’s still possible in RV via something like IfcPhysicalComplexQuantity. One should correctly provide Discrimination attribute & name the quantity according to the aspect name it should apply to. Maybe I am not seeing the bigger problem here?
The point I was trying to suggest is that DTV is still in draft status.
Yeah, that question is left midair I guess. I thought that “Whole IFC schema + empty mvd = DTV” i.e. everything is allowed, go nuts.
I think the point here is, DTV or not, IfcMaterialLayerSet (IfcMaterialLayer.LayerThickness) quickly loses its semantics. It becomes meaningless (or as meaningful as simply providing quantities) the second the element in question is not “StandardCase” so to say.
@claimred Thanks for the clarification on data being stored via quantities with the Discrimination attribute. I was not aware of that. That certainly does mitigate the loss of semantic issue, but has the added disadvantage that implementers and independent developers (i.e. the architect’s office resident BIM whiz scripter) now have to support two ways of both storing and extracting what is essentially the same information - it’s friction like this that really stalls IFC adoption, in my opinion, and should be reduced as much as possible.
I’m marking your answer as the solution, as it certainly mitigates the original query of how to satisfy this semantic and still play nice with MVDs. However, this is perhaps just one symptom of a larger problem with MVDs.
If indeed layer sets quickly lose their semantic, and is as meaningful as providing quantities, then one option should be deprecated.
This is currently what is actually happening in the industry, for better or worse. The utility of the MVD is decreasing, as MVDs conflict with one another, are unable to be reconciled with “whole schema” approaches, and users start creating their own MVDs where the official ones fall short, or vendors are never certified.
What is the name of the IfcElementQuantity? What is the meaning of yellow “Component Information” next to the box?
I see the relationship is to the IfcElement. Not the element type. With layer sets, there was intelligence in the ability to reuse the ForLayerSet. I guess this is not possible in the RV MVD?
To see how this works in action, ping @angel.velez I had a look at how Revit exports these complex physical quantities. See this attached export from Revit:
Specific to Revit’s implementation, I could not see any IfcElementQuantity. I assume this is a bug?
Specific to ArchiCAD’s implementation, (thanks @Cyril for helping to test), they store it all appended to the Qto_WallBaseQuantities quantity set, which seems to be incorrect (according to the MVD the Qto definition for Qto_WallBaseQuantities, there should be no extra quantities). I’m also assuming this is a bug. I have no idea who to ping or report to.
I also noticed on an ArchiCAD 24 export that IfcPhysicalComplexQuantity.Discrimination is an empty string. If I understood correctly it is supposed to be set to "layer".
intelligence in the ability to reuse the ForLayerSet
I think it’s still possible because IfcRelDefinesByProperties is a one-to-many relationship.
Specific to Revit’s implementation, I could not see any IfcElementQuantity. I assume this is a bug?
That’s strange, considering PhysicalComplexQuantities representing layers are present in the file, they are not aggregated into ElementQuantity for some reason. Relevant code snippet.
I am not well versed in Revit at all, perhaps quantity takeoff is a user setting? Here’s how it should look like in FZKViewer. I distinctly remember looking into a Revit-generated file with complex quantities for layers.
Hahaha I would never have interpreted an empty column as “store any number of…” I thought that was some weird rendering issue and checked at this page… I wish these assumptions didn’t need to be made.
After some testing: IfcPhysicalComplexQuantities are exported not matter your export options but they are only linked if the export base quantities option is ticked. They are also linked to Qto_WallBaseQuantities. Discrimination is Layer instead of layer but except that it looks ok.
I thought that was some weird rendering issue and checked at