Even though IGES is getting very old, it is still one of the most popular CAD formats out there. What accounts for this popularity? For one thing, it’s been around for a long time, and there are millions of IGES files out there, some of which are still in use. Secondly, though IGES has an illustrious history, not everyone recognizes that IGES is in most cases the worst CAD format to use for exchanging data, so many people continue to use it; but more about that later.

The Argument for a Neutral CAD Format

Most companies find it difficult to enforce the use of a common set of CAD/CAM tools within their organization, much less across (multiple) supply chains and among joint venture partners. Because of the lack of any common set of tools, a common format for neutral file exchange is needed. Using a neutral standard for transferring information across systems drastically reduces the requirements for translators. The cost benefits are suggested by the reduction in necessary translators shown in Fig. 1. It illustrates that by using a neutral file exchange, the number of translators (for N systems) can be reduced from scaling as n (n-1) to 2n.

Fig. 2. Illustration of the benefits of using a neutral file exchange (taken from original NIST link at

A Brief History of IGES

IGES began as an Air Force Integrated Computer-Aided Manufacturing (ICAM) initiative to reduce costs in all aerospace operations, back in 1976. Specifically, they were trying to solve the problem of incompatible CAD systems, and to bridge the gap between design and manufacturing. Those were the days when CAD dinosaurs like CADAM, Applicon, CATI (soon to be CATIA), SDRC, Anvil, ComputerVision and Intergraph roamed the earth. This process of solving CAD incompatibility was not easy. Here are some excerpts from NIST records of how IGES was birthed:

In 1979, a series of events catalyzed the CAD vendor and user community to create the first national standard for CAD data exchange, which is documented in the report Initial Graphics Exhange Spefication, Version 1.0. CAD systems were less than ten years old, and only a handful of products had any significant market penetration. Even at this early stage, users were overwhelmed by the inability to share data among these tools and with their own internally developed databases.

In September 1979, frustration came to a head at the two-day Air Force Integrated Computer-Aided Manufaturing (ICAM) Industry Days meeting. On the first day, a representative from General Electric (GE) challenged a panel of CAD vendors, which included ComputerVision, Applicon, and Gerber, to work together to enable an exhange mechanism. While this need was intuitive from a user’s perspective, this was a very threatening proposition to the CAD vendors – who feared that sharing the structure of their databases publicly would be tantamount to giving away their competitive advantage.

It would have been easy to gloss over the challenge; after all, the major vendors all had at least token representation on the ANSI (American National Standards Institute) committee responsible for CAD standards. Instead, the ComputerVision representative responded with a challenge of his own: if Boeing and General Electric (and perhaps others) would contribute the CAD translators they had already developed, the vendors would share their database structures.

What led to this offer was just the right mix of business motivation and intrigue. Large Navy contracts were looming on the horizon, and no vendor wanted to look unresponsive to customer requirements.

In the evening after the panel, several interested parties gathered and asked themselves if a common transfer was really possible. The room had the right mix of people and ideas at the right time. This included an Air Force, Navy, and NASA representative, each willing to fund $25,000 for such an effort. A National Bureau of Standards representative, after a call to his boss at home for approval, was willing to champion it as chair and coordinator. The IGES Organization was formed by NBS in the spring of 1980.


A Look at IGES

IGES files are long, so Figure 2 illustrates a simple example – four lines making up a rectangle. IGES files are 80 characters across, and are made up of four major sections: Start/Global, Directory Entry, Parameter Data, and Termination. The Start/Global is the header section, where you’ll find the name of the file, the system used to write the file and units used; in our example below, the Start section is on lines 2-5. 

Next we have the Directory Entry section (lines 6-25). The first entities are lines – entity type 110. Positions 6 and 7 designate 20 possible attributes for the first line, and the XYZ values for the first line are given on position 26, in the Parameter Data section. Likewise, the second line is defined via positions 8 and 9, and the XYZ values for the second line are given via position 27. In this way, each entity appears twice in every IGES file, once for Directory Entry properties, and once for Parameter Data definitions. 

In the Parameter Data section (lines 26-29 below), the XYZ values for the first line (entity 110) are highlighted in yellow; this describes the two endpoints of the line, at 3,2,0 and 0,2,0. This can be translated as an X value of 3, a Y value of 2, and a Z value of 0 at one endpoint of the line, and an X value of 0, a Y value of 2, and a Z value of 0 at the other endpoint of the line (see line 1 in the illustration).  

Fig. 2. – The first 29 lines of a simple rectangle IGES file, with the graphic superimposed for clarity

Import and Export of IGES

The first thing to recognize about both IGES and STEP is that not all translators are created equal; of the two, IGES has even more “looseness” in terms of how the translator can be built, and that looseness can lead to problems; for example, once an IGES file has been written by a poorly defined translator, it doesn’t matter how good your IGES reader is on the other end. Typically, a file is first written, then read, and you’ll want the best quality you can get on both ends. 

The second thing to consider are the Settings. Here are some of the settings available for IGES Import and Export in TransMagic:

  • Transfer Attributes (such as color)
  • Auto Surface Repair (repair individual surfaces upon read)
  • Read Free Edges (this one is off by default)
  • Read Free Surfaces (again, off by default)
  • Read IGES Solid (reads Manifold Solid Boundary Objects)
  • Write Free Edges
  • Write Trimmed Surfaces
  • Write All Surfaces as Spline Surfaces (IGES 128)
  • Write All Curves as Spline Curves (IGES 126)
  • Solid Output Type – Surfaces, Solids or Wireframes

What are some examples of how to use these settings? Let’s say you just received a file from a customer and nothing is showing up; that would be a good time to turn on all the switches (such as Read Free Edges) to make sure the file is really empty, and when you open it in TransMagic, from the Right Button Menu, do a Show > Show All. Then Zoom All, because most of us have seen cases where the geometry was off the screen, and a zoom all will let you see it.

Solid Output Type – You may have noticed from the list above that IGES is capable of creating solids; it’s true, but not used very often. However it does give you one more tool to try if your customer can write IGES Solids, and you can read them. 

Fig. 3. – PMI output visible in IGES as edges.

Write Free Edges – Why would you want to do that? You might be getting a file to a customer who is working with some somewhat old software which can only take IGES files, and they want to be able to view PMI (Product & Manufacturing Information).

Now, TransMagic has the ability to Read PMI, write PMI to JT and 3D PDF, and if desired, write that PMI out to graphical edges, so that anyone who can open an IGES file (or any other CAD file) can read it. 

The bottom line is that settings can be massively important when bringing in problematic CAD data, as well as when moving data from one CAD system to another. 

Once you get settings the way you want them, you can save them to a file by using Help > Export Settings File. 

The Problems with IGES

Although the speed and efficiency with which the new IGES standard was developed was impressive, there were some issues found with it. Let’s let the NIST documents speak for themselves on this point.

IGES provided a practical first solution for CAD data exchange, complete with an exchange file format. The speed with which this first draft was developed was remarkable! It may have been due, in part, to the relatively limited scope of the specification and the small size of the committee developing it. An additional contributor was the contract requirement to public a document within three months of the contract award. Once it fell under the scrutiny of an ever-broadening community, weaknesses were identified that eventually justified embarking on a new standard, which could break tradition with IGES

One of the tasks… involved an evaluation of IGES. This resulted in a thorough report and numerous constructive requests for changes to IGES. The evaluation activity helped the community clearly define IGES’s shortcomings:

Flavorings – IGES contained several ways to capture the same information, which made proper interpretation largely dependent on the particular “flavor” of the pre- and post-processors. 

File size/Processing time – IGES was criticized heavily for requiring large files that took hours or even days to parse with the average computing power available at the time. 

Loss of information during exchange – Information will inevitably be lost when information is passed between two CAD systems with inherently different capabilities. 

Lack of discipline, architecture – There was a perception that IGES was developed without rigorous technical discipline, and that formal information modeling would be useful. 

Upward compatibility – The need for generations of processors to parse files compliant with earlier versions of IGES thwarted the breadth and rate of change in succeeding versions. 

Automated a paper system – IGES was seen as a method to exchange engineering drawings, but not capable of capturing complete product data (including administrative information) to enable more sophisticated automation which would reduce or eliminated human intervention to translate. 

Additional shortcomings in IGES were later identified in a paper by Peter Wilson:

Subsetting – Vendors selected and implemented only portions of the whole of IGES, thus making exchange between two systems impossible without prior agreement on what was to be exchanged. 

Processor testing – There was no mechanism for testing processors or resolving errors between two processors. 

There was a real, long term problem with IGES that would be difficult to fix: IGES communicated the lines and symbols appearing on an engineering drawing… but it failed to communicate the meaning of the information the engineering drawing was created to convey. The… study revealed that product features must be transmitted with the geometry so that computer -based applications could “understand” the engineering drawing. For example, an application looking at an IGES representation would see merely a circle on a part. The desired result was to be able to distinguish whether that circle was a surface mark or a hole.  


Additional Issues with IGES

Some time ago I wrote Six Reasons to Avoid IGES. I will briefly summarize those points here:

  • IGES is Old – IGES began in 1980 and the last official version of IGES was release in 1996. By comparison, STEP is still being revised today. 
  • IGES Geometry is not as ‘Information Rich’ as Solid Geometry – The vast majority of IGES files are surface models, which have no mass properties, surface area, are difficult to dimension, and do not support notes and tools to add manufacturing information to the file. 
  • IGES files are Difficult to Edit – Ever try to edit a surface? Once you’ve been spoiled by editing solid models, going back to surfaces is difficult. 
  • IGES cannot carry MBD / PMI Data – The design and manufacturing world is slowly shifting towards MBD (Model-Based Definition) to define all aspects of the design in the CAD model. This includes PMI (Product and Manufacturing Information) which lets users see dimensions, GD&T, and notes right on the 3D model. MBD allows for all the information to be in one place, rather than split into two places (models and drawings), thus eliminating the risk of having out-of-sync data which could lead to manufacturing errors. 
  • Downstream Applications Prefer Solid Models – This would include Machining, FEA, 3D Printing, etc. 
  • IGES files often need to be Repaired – IGES are almost always surfaces, and surfaces do not know about neighboring surfaces, and gaps between surfaces can easily develop during translations and other operations. Solid are inherently solid and watertight.  

Many of the shortcomings of IGES were resolved in STEP, a standard which continues to evolve even today. The vast majority of the time, you’re going to get better results with STEP than you will with IGES.

Nevertheless, we honor the CAD heroes who took the first bold steps into the unknown back in 1978 to develop what would soon become IGES, because IGES solved a multitude of exchange problems and ultimately made STEP possible.

The CAD Format Ladder

Figure 4 – CAD Format Ladder

There is a hierarchy to CAD formats, and the ideal is to prefer the native format, then the geometric modeling kernel, then STEP, and last of all, IGES. You can read more about this hierarchy in The CAD Format Ladder. Many companies do not embrace this hierarchy because it is just not feasible to have all CAD systems and versions in-house; but TransMagic gives you the freedom to read and write more formats, and so can become your hub for 3D CAD interchange.

A free 7-day trial which includes video on-boarding is available here. This version will open all major CAD and polygonal formats, but only writes polygonal formats; so if you need the ability to write CAD formats, once your eval has started, you can email license@TransMagic.com and request an upgrade to Expert.