Data Loss Don LaCourse, eDocHelp
September 21, 2004
reprinted by permission from
The tips below are intended to clarify some possible confusion over data loss and accuracy issues related to the exchange of neutral format data files such as IGES and STEP. 
How data loss can occurNeutral format data exchange standards such as IGES and STEP are extensive in structure and scope. This is in an attempt to support a varied field of disciplines; MCAD and AEC are only two among many. In the process of neutral format data exchange, a 3D model file is translated from one native CAD format (sending system) to an IGES or STEP file. This file is then translated into another native CAD format (receiving system). The process involves extensive entity mapping. The sending system maps native entities to supported neutral entities. The receiving system then has to map the neutral entities in the IGES or STEP file into its own native CAD entities. Sometimes this entity mapping can change the definition of the native CAD entity, such as mapping an analytical arc or cylinder to a b-spline curve surface. During the process, the original definition of an entity can get lost. This loss of definition in most cases has become acceptable.  | Figure 1 Each CAD system supports a subset of the IGES standard. The entity types supported by both systems are mapped from the sending system to the receiving system. Other entities with the subset may be ignored. (Courtesy of eDocHelp) |
Also, because of the size and scope of the standard, MCAD systems will only support a subset of the standard. While System A may support entities a,b,c,d and e, System B only supports entities a, c and e. So you ask, what happens to entities b and d? Well, they are ignored by System B because it chooses not to support those entities. This is another way in which data can be lost (see figure 1 above). This is not to say that data is lost due to nonsupport during every translation. This can occur when the two systems are fundamentally incompatible (such as between a high-end and a low-end system) or when the receiving system is outdated. 3D data loss can also occur due to human programming errors - how well the MCAD systems write out (translate to IGES or STEP) and read in data (translate from IGES and STEP). How well you say? Well that depends on how true the programmers that write the translators are to the specifications documented in standards. The specifications are open to interpretation and programmers then have to program their translators to act accordingly. Programmers are also human and are prone to human error. Can the accuracy of the data change?Yes, there are many ways for the “accuracy” to change. Starting from the native sending system, what you see on the screen is not necessarily what is in the 3D database. 3D modeling kernels can force geometry to connect or treat them as though they connect even though they do not. Neutral format data exchange can exposes these inconsistencies (see figure 2 below).  | | Figure 2 3D modeling kernels can force geometry to connect or treat them as though they connect even though they do not. Neutral format data exchange can exposes these inconsistencies. Note: The conditions portrayed in this figure are enhanced for better understanding. |
You may have noticed in recent years the attention paid by MCAD applications to healing 3D data. Virtually all viable MCAD applications today offer integrated tools to fix topology related geometry problems. You will also have noticed that the translation process has been integrated into the File Open and File Save commands. These two advancements together have reduced much of the stress related to translating data but has also obscured the translation process. Many MCAD applications today are very strict and thus require the geometry to be healed before adding it to the database. Duplicate vertices can be removed. Faces are extended and trimmed to form new edges eliminating gaps that are encountered (see figure 3 below). For many systems, all geometry is stored as NURBs. Primitives get converted to NURBs. Polynomial definitions get converted to NURBs. During the healing process, surfaces can be extended to catch trim loops that are defined off the surface.  | | Figure 3 Topology healing can be performed automatically when a neutral format data file is opened by the receiving system. This example illustrates how faces are extended and trimmed to form new edges (see Window C) eliminating gaps that are encountered. Note: The conditions portrayed in this figure are enhanced for better understanding. |
The tolerance used to do all this is the tolerance set by the user in the receiving system. The native system may have created the geometry in a looser tolerance than is being used by the receiving system. Even the units-conversion and local coordinate systems can play a small part in deviating the accuracy of the geometry. Large deviations typically come from the on-screen issue described in Figure 2 above. Geometry can also be malformed by defining coincident intersections or gaps with neighboring geometry. The receiving systems must clean all of this up in its attempt to produce a valid part file. Particularly difficult are sliver-surfaces. These are used by the sending system to patch gaps in the part even though they are below the sending system’s registered tolerance. Figure 3 Window B is a candidate example for a sliver surface. These cases are also healed by extending surfaces and re-intersecting with neighbors. On top of this, the receiving system also has to deal with neutral data files that do not conform to the specifications – trim loop curves out of order, reversed, not matching end to end, and missing geometry, and so on. You may also run across hand-edited neutral data files that are missing large sections, introduce control characters, etc. Some systems do a very good job of identifying and healing these anomalies on the fly. ConclusionI can’t stress enough the importance of interoperability testing to bring the potential for these problems to light prior to depending on neutral format data exchange for production purposes. If you uncover problems with your system’s translators, be sure to submit a bug report to your MCAD application vendor and if possible include any relevant error logs and neutral data files. This is your way of initiating changes to your application. Don’t be afraid to let your application vendor know about any problems you are experiencing. Users have a loud voice and vendors do listen. About the Author Don LaCourse is principal partner of eDocHelp, which provides e-documentation, online help, technical writing and 3D modeling services for the CAD/CAM, manufacturing and other service-oriented industries. eDocHelp recently launched 3DCADTips, a 3D CAD resource site. Don has over 25 years of experience in design and documentation. He gained much of his experience during his 10 years as a tier-one automotive designer with Textron, Inc. He also helped NASA and the European Space Agency (ESA) design and document their joint SpaceLab 1 project that flew on board several of the early space shuttle missions. Don also brings product and injection mold design and documentation experience to eDocHelp. Don had his first book published in 1995 serving as editor-in-chief for the McGraw-Hill publication "Handbook of Solid Modeling," where he contributed, edited and managed over 25 industry-leading authors. He is currently a contributing editor for Cadalyst magazine. More Select CAD Translation Articles | 
