Talk:IGES

CAD/CAM Interoperability

Introduction

Part of the problem with CAD/CAM interoperability is that vendors use different internal representations for geometry. For example, Vendor A may represent a circular arc as the 2D coordinates of the center point and the two endpoints of the curve, with the implicit understanding that the curve is drawn counter-clockwise, accompanied by a matrix representation of the plane on which the three points lie. Vendor B represents it as the 3D coordinates of the endpoints and an arbitrary midpoint on the curve, drawn from the first (Start) point to the third (Terminate) point through the midpoint, which is not necessarily in a counter-clockwise direction. Vendor C does it a third way, etc. (They may not even use the same name for a "circular arc".)

In one case, the Center point is given explicitly, and in the other case, it must be derived computationally. IGES defines a representation for a circular arc that may be more like one vendor's native representation than another's, but neither vendor has to know anything about the other vendor's representation to be able to read a CIRCULAR ARC entity from an IGES file, or to write one in IGES format ... someone will either have to calculate a Center point when it writes the entity to the IGES files, or else use a matrix to position the circular arc in 3D space when it reads the IGES file.

This is a fundamental rule of Product Manufacturing Information (PMI) translators, even when a neutral format like IGES is used ... either the import side or the export side is going to have to do some extra work to read or write some of the entities, and if you're lucky, it's only half of them.

Donut/Hole Problem

There is something called the Donut/Hole Problem in manufacturing, which occurs when you use a circle to represent a hole in a surface ... do you mean to remove the material inside the circle (leaving a "donut" shaped part), or the the material outside the circle (leaving just the "hole"). In the Right Hand Rule, your upwards pointing thumb represents the Z axis, and curling your fingers moves them in the direction from the X axis to the Y axis. The rule is that material to the right of a curve is removed, so the answer of which part to keep depends on which direction the circle is drawn, clockwise or counter-clockwise.

Vendor A might generate IGES files so that all circular arcs are counter-clockwise when viewed down the Z axis, but some of them might have been originally created in the opposite direction, and that caused a problem for users of Vendor B's system, not in the display of the part geometry, but when they tried to run CNC software to actually cut metal from the translated part representation. These kinds of "oversights" in the IGES standard (an attempt to keep it from being too restrictive) were one cause for the many versions published over the first decade of its life cycle.

The IGES Committee established a Recommend Practices subcommittee that produced the Recommended Practices Guide, informing translator implementors of pitfalls discovered by vendors and users. Some of these led to Request for Change (RFC) submissions to the appropriate IGES subcommittee (Drafting, Geometry, Electrical, etc.), and if approved by a general ballot, they became an Edit Change Order (ECO) for inclusion in the next published version of IGES. As soon as the ECO was approved, users could require them in a Request for Purchase (RFP) or a Purchase order, although many vendors had already incorporated the updates in beta test software released even before the RFC balloting phase.

Early versions of IGES did alright for simple 2D manufacturing operations, but as solid modeling became more common, a problem was discovered in the way IGES defined trimmed surfaces, or the 3D Donut/Hole Problem.

Imagine a sphere, represented as a parametric surface. Cut it with two planes parallel to the equator. Do you keep the area around the equator and discard the areas around the poles, or the other way around? The early IGES representation, using the TRIMMED (PARAMETRIC) SURFACE (Type 144) and CURVE ON A PARAMETRIC SURFACE (Type 142) entities, lacked sufficient information for systems to be able to correctly read the data from IGES files they wrote themselves. "That's not a bug, that's a feature!"

After a year's work in the IGES Geometry subcommittee, vendors and users had tested and agreed upon the BOUNDED SURFACE (Type 143) and BOUNDARY (Type 141) entities, which were quickly approved by RFC ballot, and publication of the next version of IGES was delayed until the ECO could be included. (Your humble friend and narrator was sent to Europe by his employer twice in six months to explain to the Vice-Presidents of Engineering at Audi and FIAT why they could not have what the salesmen of our CAD/CAM system had promised them, because the problem was with the definition of the IGES entities, not our translator, and that withholding payment from us was not going to make it happen any sooner.)

Manifold Solid Boundary representation Object (MSBO) geometry

The IGES Committee was quick to respond to these kinds of errors and omissions. The last version of IGES was delayed to include Manifold Solid BREP Object (MSBO) geometry to supplement the older (and not very widely supported) Constructive Solid Geometry (CSG) entities. The MSBO entities construct objects from vertexes, edges, faces, and shells in a hierarchy that preserves the geometric, parametric, and topological relationships between the components.

In spite of these improvements, some vendors only support the older versions of surface and solid representations in their IGES translators, which means that other vendors and users are forced to support these legacy entities as a concession to interoperability. Although a few entities in IGES were marked obsolete and moved to an appendix, they are inoperative only as of a certain version of the standard, and there are warehouses full of IGES files conforming to earlier versions that will have to be readable at a future date.

IGES Flavoring

This has led to "flavors" of IGES files that reflect which vendor's system generated them, or which system is the intended recipient. There was a serious bug in the very first Applicon IGES translator ... a programmer confused the row/column order for matrices defined in IGES with the order of the programming language they were using. (FORTRAN and the C programming language use different orders of rows and columns for arrays, i.e.., what is a [3,4] matrix to one is a [4,3] matrix to the other.)

Since the MATRIX (Type 124) entity is used to orient all entities represented by 2D coordinates (circles, conics, text) into 3D model space, as well as SUBFIGURE INSTANCE (Type 408) entities, when the Computervision (CV) IGES translator read an IGES file from the Applicon translator, the results looked like an explosion had occurred, with pieces of geometry randomly dislocated.

The developers at Applicon never saw the problem when they read their own IGES files, because they reversed the rows/columns on the matrices again, which restored them to their correct values. But they got the same "exploded" parts when they read Computervision's IGES files, because they were reading the matrix incorrectly.

There was a lot of finger pointing, because each vendor could read their own files, but not the other's. The developers at CV thought that the error was their's, and so they also swapped the rows and columns in their translator. After CV changed their translator, someone discovered that Applicon should have been the one to change, so now two vendors were creating bad IGES files.

Unfortunately, a lot of users had created IGES files using those early translators for as long as six months before it was corrected, and a few users delayed the upgrade even longer, so two flavors of IGES files are "Applicon: pre-1981" and "Computervision: pre-1981" ... each translator had to recognize its own legacy files to correct the problems caused by the earlier versions, and to protect their users from bad legacy files created by the other system. As other vendors implemented IGES translators, they also had to contend with these two flavors of legacy files.

Further Thoughts

Although there is currently no public domain or free open-source software library for reading and writing IGES files, some work was done under a contract from NIST in the 1990s to create a Web based IGES file viewer. Perhaps there will be a GNUiges library someday, because there are IGES files in storage from over 25 years ago, and someone may want to read them 25 years from now to create replacement parts for airplanes, vehicles, and ships that have been put into mothballs in some bone yard.

IGES 5.x is available in PDF

Last night, I had an epiphany ... I spent a few minutes with Google, downloaded MiKTeX, a free DOS based LaTeX → PDF system, opened a DOS window, went to the directory D:\WebSites\IGES5x\ARCHIVES\VERSION5X (which contains version6.dvi) and typed:

dvipdfm version6

The next thing I knew, I had a PDF file of "DRAFT v6.0 1998-01-05" ... the only thing missing was the figures.

All I had to do was take the LaTeX files for that version and change "Version 6.0" to "Version 5.x", reintegrate the figures (some of the X-files will be in color), and add the 39 supplemental TEX files I sent to the IGES Editor on 1998-08-21 ... note that these files have been on the Web since 2001-05-30.

Next I copied the directory with the 1998-01-05 TEX files, renamed a few, did some changes to 5 style files, made PostScript files from the 154 IGES figure files, and typed:

pdflatex version5x

Please see http://www.IGES5x.org/archives/version5x/ for the PDF version of "DRAFT v5.x 1999-01-12", complete with the Table Of Contents, List Of Figures, and the figures ... plus, all of the sections and figures are hyperlinked.

So, let us hear no more talk of IGES 6.0 ... after a decade of use, I have updated the Web based IGES 5.x from the 1992-01-26 draft to the 1999-01-12 draft as a 732 page PDF document ... it's 4.3Mb, so it takes a while to download, but man, is it ever worth it! --Dennette 16:06, 16 June 2006 (UTC)

MIL-STD-1840

Hello, fellow editors ... I added the link for MIL-STD-1840 because it is the MilSpec that calls out MIL-PRF-28000 ... I found PDF copies of both on .mil websites, so it doesn't get any more WP:RS, even if they are primary sources. :-)

Happy Editing! — 151.200.237.53 (talk · contribs) _{17:13, 20 June 2008 (UTC)}

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on IGES. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://archive.is/20120719004148/http://ts.nist.gov/Standards/IGES/rfc603.cfm to http://ts.nist.gov/Standards/IGES/rfc603.cfm
• Replaced archive link https://web.archive.org/web/20100414065725/http://ts.nist.gov/standards/iges/ with https://www.webcitation.org/66meP6swl?url=http://www.nist.gov/el/msid/standards.cfm on http://ts.nist.gov/standards/iges/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 04:24, 10 November 2017 (UTC)