Why CAD Haz Proprietary Formats?

Opinion by Ralph Grabowski, with Sergey Vishnevetsky

Each major CAD format is in its own world, with its own kernel, data model, and licensing. This is the result of the history and peculiarities of each design system. Some of the major CAD systems are nearing 50 years old, and each one was developed in isolation, usually by manufacturing firms, such as Boeing, HP, and GM, for their own design needs. To this day, their formats remain proprietary.

As a result, design firms must either pay for multiple CAD systems, or else ensure no data is lost when converting designs to other formats. With each new format comes new integration, new SDKs [software development kits], and ongoing maintenance. This turns into a business problem.

Kernels contain the mathematics that define the geometry and relationships of 3D solid models, surface meshes, and certain 2D entities, like regions and sketches. Models are saved in files, and these files are the subject of today’s article. By defining CAD elements differently in files, compatibility between CAD systems is hindered.

(The Open Design Alliance held a Webinar to explain the differences described here and -- no surprise! -- present their solution to solving the problem. You can watch the replay hosted by ODA director of development Sergey Vishnevetsky at https://www.youtube.com/live/e6owfUlSwlc.

This article contains text edited from the transcript of Mr Vishnevetsky’s Webinar interspersed with my opinions.)

Proprietary formats have the bonus of locking in users, some of whom were offended enough to launch in the early 1990s programs to access what they considered to be their data. The first to fall was DWG, a binary format whose layout Autodesk would not publish. (It felt ASCII-based DXF was sufficient.) Nevermind. DWG is so common, so extensible, and has so many translators available now that about three dozen non-Autodesk CAD programs use DWG as their native file format.

Proprietary file formats create problems internally for CAD vendors, too, and so even they need translators. For instance, PTC acquired Onshape, which uses the Parasolid kernel, so its models need translation to Creo, which uses the in-house Granite kernel; Creo incorporated CoCreate direct modeler (from HP), which ran ACIS. When Autodesk wrote Inventor, it was created with a new file format incompatible with AutoCAD’s DWG, so over many years it has to develop a translator. After CGM-based Dassault acquired Parasolid-based Solidworks, it urged users to switch to 3dExperience, but the lack of round-trip compatibility helped convince4406 Solidworks users to avoid switching.

Four major proprietary geometric modeling kernels used in CAD programs

The Four Major Kernels

Every major CAD system being built on its own geometric kernel, and these kernels are fundamentally different. Aspects like parametric relationships and regeneration logic are all kernel-specific. Here’s a brief overview of each one:

Granite from PTC uses tolerance-based modeling, with aggressive tolerance propagation. It is oriented toward feature regeneration, tolerance-based modeling, and geometry. It is tightly integrated into Creo (and before that, Pro/Engineer), and is not a separate product.

Elements of the Granite kernel, which is programmed by PTC

Parasolid in Siemens’ NX and SolidEdge has strict tolerance control and a well-defined BP standard. Of the four kernel ecosystems, Parasolid the most widespread kernel in the industry, used by NX, SolidWorks, SolidEdge, Onshape, and most other CAD systems. This means conversion between these specific systems is relatively straightforward, because they share the same geometric foundation.

Elements of the Parasolid kernel, which iswidely licensed by Siemens

CGM in Dassault Systemes’ Catia and 3dExperience is an entirely separate world, with non-manifold topology and multi-representation geometry. The closed world of CGM (convergence geometric modeler) is fully proprietary, with no external SDK and no public documentation. Some portions of it are licensed by Dassault subsidiary Spatial. The topology model supports non-manifold geometry and multi-representation curves. Nevertheless, through reverse engineering it was found to contain 103 entity types defined by binary streams, and does things like storing multiple curves per edge.

Elements of the CGM kernel developed by Dassault Systemes

ACIS is yet another kernel with its own math feature trees that are not portable, because they are not no longer documented. It is used in Alibre Design, BricsCAD, SpaceClaim, TurboCAD, and others. ACIS has the status as the first licensable solid modeling kernel, developed in England in 1989, and is now marketed by the Spatial division of Dassault.

IronCAD is unusual in licensing both Parasolid and ACIS in its 3D modeling software. Autodesk’s Shape Manager kernel is forked-off ACIS; it powers Inventor, AutoCAD, and others. There are numerous other kernels from smaller firms, such as SMLib by Solid Modeling Solutions, Open CASCADE open source kernel, and C3D Modeler from C3D Labs.

Degrees of Openness

The just-convert-everything-to-STEP approach inevitably results in data loss. CAD formats differ not so much by file structure as by geometric kernels and feature models. This is the main factor determining the complexity of interoperability, and so direct translation is preferable, if possible.

The ODA groups MCAD formats by their degree of openness. This classification helps understand the challenges and approaches for each group:

• Least open: Proprietary formats

• Vendor-controlled open formats

• Most open: Open standard formats

Proprietary formats, such as in SolidWorks, Catia, NX, Creo, and SolidEdge, closed binary formats with no public specification. They contain the richest data, full-featured tree B geometry, assemblies, and parametric relationships. Supporting them requires either reverse engineering the formats, or accessing vendor provided APIs, if available.

Vendor-governed open formats, such as JT, 3DM, and QIF, are an intermediate category. JT is an open specification published as ISO, but is governed by Siemens. 3DM has a fully open-source SDK maintained by McNeel & Associates. QIF is a quality information standard maintained by the Digital Metrology Standards Organization. These open formats provide geometry and metadata, but typically not full parametric models.

Open standards, like STEP and IGES, have their specifications are published by ISO (industry standards organization). They provide universal exchange capabilities, but inevitably lose format-specific data like feature trees, parametric relations, and regeneration logic.

IGES is quite a stable format, with a solid implementation despite its age. This was the first neutral format and was last updated in 1996, yet continues to be used in major CAD systems — precisely because the format has remained unchanged over thirty years. The implementation is stable and does not involve intellectual property evolution.

---

How ODA API Works

ODA covers the three groups of CAD formats — proprietary, vendor-governed open, and open standards — through a single unified API. Parasolid, CGM, and Granite are three different worlds with different mass, different tolerances, and different data models. In 2026, ODA adds support for the three kernel ecosystems. Catia, NX, and Creo are in active development, plus the full set of open standards and vendor-governed formats.

Features of the API from Open Design Alliance

ODA has two API levels. The Common API provides a single interface, where the same code works for SolidWorks, Inventor, STEP, and other formats. It does not convert data to an intermediate representation. Each format lives in its own native database, so a SolidWorks file stays as a SolidWorks database, and an Inventor file as an Inventor database.

Integrating a new format doesn’t require rewriting your application. You add a module and your existing code works. But if you need just one specific format, each SDK provides its own format-specific API with full access to native capabilities. For example, with SolidWorks, its configurations, sheet metal, design tables, and everything else specific to that format is available.

Outline showing how to integrate an API into a CAD program

MCAD Common API is an unified API for supported formats that include SolidWorks, Inventor, STEP, IGES, PRC, KE, OBG, STL and even external formats like 3DM.

opendesign.com/products/mcad-sdk