It’s been almost three years since the IFC Design Transfer View was introduced, and, going by definition alone, it seemed super promising as a vehicle to allow for cross-software editing collaborations. However, it seems like this MVD has not seen much love in recent times, as there exists almost no documentation from bS on it anywhere. Have people been using this MVD and can speak on how useful it is for collaboration?
The MVD was never actually finalized. The Revit DTV implementation was based on basically CV2.0 + advanced BReps, waiting on a DTV MVD, but it wasn’t - and probably will never be - defined. As such, we now label it as unofficial to explain that you can use it if you want to play with IfcAdvancedBRep, but that your mileage may vary.
2 Likes
So if DTV was never quite finalized, which IFC4 MVD is most commonly used out in the wild these days?
The IFC4 Reference View (RV 1.2)
It is essentially the same as the IFC2x3 Coordination View, but all geometry is simplified (no parametric features).
1 Like
Wow. That seems like a big step backward from CV2 with its extruded profile geometry. What was the big road block that prevented DTV from getting finalized? Are there any other MVDs that are gaining traction?
“Simplified” or “non-parametric” may be overstating it. You still have extrusions, but no CSGs/Boolean clippings. Some applications do have an option to further simplify the geometry to surface models (IfcTessellatedItem). I have seen this used often in the past for compatibility with some viewers/tools, though I think this is not much of a technical issue anymore.
2 Likes
I think @angel.velez alluded to it earlier. Historically, Advanced BRep/CSG compatibility with a variety of tools has been an issue. The many differences between native geometry kernels and accurate processing of IFC geometric models into native ones was fraught with errors.
In addition, there are some cases where the native parametricization of building elements doesn’t match up well with IFC definitions. For example, look at IfcStair. Each tool I’ve ever encountered “builds” a stair quite differently from the others. I can’t think of any that do it exactly like IFC4 describes (other than possibly BlenderBIM). Same goes for things like IfcCurtainWall, and even the use of IfcHalfSpaceSolid for clipping elements like Slabs, Walls, Columns, Spaces, etc. on more complex configurations of edge and endpoint conditions.
1 Like
My experience has been that for IFC2x3 CV2.0 and Basic FM Handover View, along with the Space Boundary Add-on, were the majority of exchanges. For IFC4, which only recently has gained traction, again the RV1.2 is the primary exchange method. Others may have created custom MVDs, but these are the official bSI ones.
With IFC4.3 we could see this change a bit, but I think @berlotti can better explain how this may work in a new technical ecosystem that includes the bSDD and IDS. Personally, I’m still unsure about “design transfer”, though. It may be that the best means to transfer parametric geometry info is via a middle-man service (like Speckle/Dynamo/GH) and leveraging ODBC/RDF/JSON/YAML/XML.
1 Like
Personally, I think we can define schemas based on the IFC definitions that correspond to specific cases that can be exchanged more intelligently. Something like what wall standard case tried to be, but more of them. A domain-specific MVD v1.0 could specify a number of these that would represent 90% of real-world data is fully transferable/10% of real-world data is referenceable. With the right specifications and sample data, we could have a reasonable certification around that.
Agreed @angel.velez.
But another thing to be careful about, and this was recently expressed on Twitter, is that many people think “design transfer” should enable “seamless” cross-platform, back-and-forth editing of the same model. This was never the intent of DTV from the beginning, nor do I think it feasible via the previous file exchange methods we’ve relied on. My thinking about things like Speckle/Dynamo/GH/etc. and other “live linked” methods would help accommodate that, though not without further serious work on covering all object types and differing geometric authoring methods.
1 Like
“design transfer” should be a tool that helps towards the goal of “seamless” cross-platform, back-and-forth editing of the same model of some agreed-to entities for some definition of “seamless”. I don’t think we are likely ever going to have a shared anything-goes model that you can work in real-time across competitive solutions. But you may be able to get local copies of some data, update it and put it back in some central model, where IFC would carry enough information to generate intelligent enough data for some subset of data. There’s no way that that would ever be 100% - different products are different for a reason - they won’t share all information.
1 Like
Another important thing here imho - Layered structure classes are not available in RV i.e. IfcMaterialLayerSet, IfcMaterialProfileSet.
My question is: why isn’t it possible to just name IFC 4.0.2.1 schema in it’s entirety as Design Transfer View? 
Basically, empty MVD applied to schema is DTV.
You still have extrusions, but no CSGs/Boolean clippings.
Not quite. Sure, you still have extrusions but profile classes are severely constrained. You can’t use any of named profiles (LShape, UShape, …).
We had a lot of fun testing Revit/Renga AdvancedBrep, complex profiles sweeping operation interoperability and users experience was nice - smaller files, pretty, precise and actually intentional, domain-specific geometry. It’d be weird to give it up.
Historically, Advanced BRep/CSG compatibility with a variety of tools has been an issue. The many differences between native geometry kernels and accurate processing of IFC geometric models into native ones was fraught with errors.
Well, yeah, but my understanding was that those tools don’t actually need DTV at all. Not full-blown CAD programs but viewers and so on, sometimes they don’t even have geometric kernel inside.