In the construction industry, when streaming, developing systems, databases or automating processes that work with design information and feature geometry, it is important to strive for independence from specific CAD editors and geometry kernels.
The exchange format to be used both in the calculation departments and on the construction site should not be based on a specific CAD- (BIM-) program. Geometric information should be represented in the format directly through tessellation, without reference to the geometry core or CAD architecture.
Parametric geometry from CAD can be considered as an intermediate source, but not as the basis for a universal format. Most parametric descriptions (including BREP and NURBS) are in any case converted to polygonal MESH for further processing. If the result is the same (tessellation and polygons) and the process is simpler, the choice is obvious. This is analogous to the choice between graph ontologies and structured tables (which we discussed in part four): excessive complexity is rarely justified (Fig. 3.2-10, Fig. 6.1-8).
Open formats such as: OBJ, STL, glTF, SVF, CPIXML, USD and DAE, use a universal triangle mesh structure, which gives them significant advantages. These formats have excellent interoperability – they are easy to read and visualize using available open source libraries without the need for complex specialized geometry kernels containing millions of lines of code (Fig. 6.3-3). These versatile geometry formats are used in applications ranging from relatively simple kitchen design tools in IKEA™ to complex object visualization systems in movie and VR -applications. An important advantage is the availability of a large number of free and open source libraries for working with these formats, available for most platforms and programming languages.
As well as the users themselves, CAD -vendors face problems with interpreting foreign parametric CAD formats or open IFC because of different geometry kernels. In practice, all CAD -vendors, without exception, use the reverse engineering SDK to transfer data between systems, and none of them rely on formats like IFC or USD (А. Boiko, “The Age of Change: IFC is a thing of the past or why ADSK and other CAD vendors are willing to give up IFC for USD in 14 key facts,” 24 November 2024) for interoperability purposes.
Instead of using concepts promoted by alliances of CAD- vendors that they themselves do not use – it is more productive for developers and users of CAD solutions to focus on understanding the benefits of each approach in a specific context and to choose one or another type of geometry depending on the use case. Choosing between different geometric representations is a trade-off between accuracy, computational efficiency and the practical needs of a particular task.
The complexity associated with the use of geometric kernels, which is traditionally imposed on the construction industry by large vendors when processing design data, often turns out to be redundant. The USD format based on MESH geometry can become a kind of “Pandora’s box” for the industry, opening new opportunities for developers to organize data exchange – outside the framework of IFC and parametric BREP structures typical for CAD vendors.
After a closer look at the structure of USD, DAE, gLTF, OBJ, etc., it becomes obvious that there are simpler, open formats that allow to efficiently organize the transfer and use of geometric information without the need to rely on complex parametrics and closed geometric kernels. This approach not only lowers the technical threshold of entry for developers, but also promotes the development of flexible, scalable and truly open solutions for digital construction.
