Machine Design


Different CAD systems still don’t talk well with each other. What lies under the hood of today’s datatransfer problems?

Paul Hamilton

Edited by Leslie Gordon

You would think that by now, CAD data exchange would almost always go smoothly, especially considering all the research that has been done in this area. No doubt interoperability has improved. But, in general, data-exchange problems seem to grow only more complex. Interoperability issues obviously arise because of the many proprietary CAD file formats in use today. But problems also come from CAD-neutral formats, the CAD geometry itself, and so-called intelligent models.

As a quick refresher, neutral formats are defined by industry standards. These formats are intended to be viewable and editable in almost any CAD application. IGES, for example, is the oldest of the neutral formats and still widely used. But it includes many flavors and relies on experienced designers to know which to select. STEP provides yet a better mechanism for the exchange of solid models, but it also includes many configurations including AP203, AP204, and AP214, to name a few. Each has differences in how geometry gets described. Other neutral formats include the Parasolid kernel’s Parasolid and the ACIS kernel’s SAT. Add to this mix a plethora of tools that translate geometry from one proprietary CAD format to another with varying degrees of success.

Making things more confusing are the numerous ways of representing geometry. Years ago, wire-frame CAD created objects out of individual edges tacked together. Objects lacked volume, an inside, and an outside, but they did have shape and size. Other CAD systems build objects with surfaces, typically using curves or wires to trim or bound the surface. And, finally, there is solid modeling.

Different data-translation issues arise from each kind of geometry representation. For example, the translation of vectors or wire geometry is relatively simple for 2D drawings and wire frames. Some problems can come from wires being described differently with Nurbs, B-spline, or analytics. But for the most part, such translations are reasonably reliable and acceptable.

Surfaces are also relatively simple to translate. About the only problem comes from the surface normal being reversed from what is expected. Most CAD systems make it easy to switch normals and continue working. But even when the surface looks the same and can be manipulated, it still might not be identical to the original. A Nurbs-to-Nurbs translation will be close, and a B-spline-to-B-spline transfer is usually identical. But Nurbs to B-spline, or vice versa, only makes for a close approximation.

Solid modeling gets yet more interesting. A solid must be watertight, with no gaps. Solids are basically made up of edges (with a vertex at each edge) that connect to form loops. The loops trim surfaces to form faces, and the faces connect to form the solid. Solids are all about connectivity, or more accurately, topology. Solids have volume and, therefore, mass, weight, and the like.

Accuracy is Accuracy, right?
Note that so-called graphical accuracy is different than geometry accuracy. The graphical or visual accuracy of the model — what you see on the screen — depends on the graphics processing of the computer. A brief explanation helps clear things up:

A graphics card in the computer converts geometry to facets. The higher the numbers of facets, the smoother models look. Most 3D CAD systems use a default graphics resolution that is fairly low so graphics performance won’t get too slow. Graphical accuracy has nothing to do with interoperability.

That all said, there are graphical formats used frequently that are based on the faceted model, such as STL and VRML. But these formats are not typically used for data exchange.

A significant factor affecting connectivity is geometry accuracy. CAD companies use different terms for geometry accuracy, so there might be confusion about what it means. Some systems use relative model accuracy, while others use an absolute accuracy. Some use both. Regardless, an application’s accuracy determines such things as how close two points are in space before being considered one point, or how close an edge can be to another before they are deemed connected. The big problem around geometry accuracy is almost every 3D CAD system uses a different default setting. Of course, it’s possible to adjust the setting, but most designers just accept the default. Some CAD goes to 1.0E-2 mm (0.01 mm) and some as high as 1.0E-6 mm. Others run at 1.0E-3 in., and so on. (Accuracy settings are independent of the unit settings you use to describe the geometry. Accuracy settings are also independent of the number of decimal places you might see in a measurement or dimension.)

Accuracy settings are used as the model is created and also when exporting geometry into IGES, STEP, or other neutral formats. (You can find geometry accuracy information in the header section of an IGES file.) Reading a low-accuracy file into a high accuracy system requires the reading system to downsize its accuracy, a recipe for data-translation disaster. A good practice is to make the sending system’s geometry accuracy higher before writing a file. But this approach often won’t handle complex features such as blends or shells. Unfortunately, some CAD systems are just not capable of creating high-accuracy geometry.

The upshot: If you are on the receiving end of 3D geometry and paying for it, you might be wise to set a standard for the level of geometry accuracy you are willing to accept. “Garbage in, garbage out” could easily apply here.

Another significant factor affecting data translation is the intelligence of the models. Many 3D CAD applications embed intelligence into the model in the form of sketches, feature definitions, constraints, and structure and order. These systems, typically referred to as parametric or history based, do not interact directly with the geometry, but rather through the layer of information. Unfortunately, there is no industry standard for the translation of intelligence. Some protocols such as STEP, for example, accommodate information such as 3D dimensions or feature definitions, but the intelligence required by the typical history-based system is different.

The problem is further exacerbated because each CAD system uses different intelligence. For example, applications define feature definitions and orders and structures differently, and resolve constraints and parameters differently. These differences exist only to provide software developers a competitive advantage.

For the typical history-based CAD user, even when the geometry translates accurately, the ability to interact with it might be limited depending on the program. Some CAD software imports geometry while stripping its intelligence and then interrogates the resulting so called dumb model to reconstruct the necessary features.

There are ways those using history-based CAD can work around interoperability issues with varying degrees of success. One method is to ensure all your customers and partners use the same CAD system you use. Or you can just import geometries and use them as references to rebuild intelligent models. Lastly, you can bite the bullet and purchase a dedicated intelligent model translator.

Depending on your business requirements and processes, a history- based modeler might not be the best choice. Here, history-free or explicit modelers that interact directly with geometry might do well. Most allow adding intelligence, but the intelligence is not necessary to manipulate and interact with the geometry.


Because different CAD systems use different geometry accuracy, a solid model from one program (top) imported into another might lose the connection between its faces (bottom).


Solids are basically made up of edges (with a vertex at each edge) that connect to form loops. The loops trim surfaces to form faces, and the faces connect to form a solid.


The top image shows how a typical history based modeling system works. It does not interact directly with the geometry but rather through the “intelligence” — sketches, features, constraints, and structure. The bottom image shows what happens when a history-based system reads in an IGES, STEP, or other geometry file. The intelligence does not survive the translation and what is left is just the geometry. (Some history-based systems allow for direct geometry editing, but this capability is usually somewhat limited.)


An explicit or history-free modeler interacts directly with the geometry.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.