Model View Definition (MVD) - An Introduction
What is an MVD?
In general, a MVD, or "Model View Definition", is a specific use of IFC to describe facilitate a specific use or workflow. MVDs can be as broad as nearly the entire schema (e.g. for archiving a project) or as specific as a couple object types and associated data (e.g. for pricing a curtain wall system). It can add additional restrictions to the IFC schema, and even overrule some agreements.
The IFC schema is designed to accommodate many different configurations. For example, a wall can be represented:
- as a line (or curve) segment between two points;
- as one of many types of 3D geometry for visualization and analysis (such as extruded solids or triangulated surfaces);
- as simple forms or with specific construction detail (capturing individual studs, pipe fittings, wiring, etc.)
- ...along with data such as engineering properties, responsible party, scheduling, and cost information.
IFC is the large set of agreements; an MVD uses entities from IFC to define an exchange standard for a specific use-case or workflow. This exchange standard (MVD) is being implemented by Software Vendors.
Because an MVD is being implemented by Software Vendors, MVDs are the base against which the MVD based Software Certification (b-cert) takes place. Software implementations are checked against the requirements of an MVD.
An architect is sending a simple model to the client to place within a larger urban context model, allowing the client to visualize the design, the architect does not need to send all the complex modeling operations data (e.g. CSG) and object attributes, but can send a simple surface-based geometry model with simple color or texture mapping. This is a simple example for the Reference View.
Precast manufacturers define how they want to receive IFC data. They define the use of assemblies, and that they need to have precise geometry represented with BREPs. Additionally they define what properties Precast elements should have. This is an example of the IFC4Precast MVD.
For a long time, everyone could create their own MVD and approach software vendors to implement it. This created a situation with several MVDs that have been created are not interoperable with each other, and need additional efforts for implementation in Software tools. Software that supports example 1 (Reference View) cannot automatically support example 2 (Precast). Software tools need to update and extend their code to support multiple MVDs.
historically MVDs have been a good solution to deal with the limitations of the technology, but in the current market users and software vendors expect a different approach. Therefore IFC 4.3.x will have a few base MVDs that are defined by buildingSMART as a base for multiple use-cases. This will increase the interoperability between domains.
The IDS standard works hand in hand with IFC to be able to define computer interpretable exchange requirements per use-case.
MVDs in the near future
In IFC5, this will be further restricted to guarantee interoperability between different domains and software implementations of IFC. IFC5 will be modular with a shared base that has a limited number of implementation levels (similar to the 3 base MVDs in IFC 4.3.x). The definition of exchange requirements will be done using Information Delivery Specifications (IDS). More on this on the Technical Roadmap page.