Dr. Paul Stallings, VP of R&D for Kubotek USA, looks like a typical guy.  When I first met him at COFES, he seemed like a typical guy. Then I got to have a little conversation with him, and discovered that he’s not a typical guy.  You can do your own research on him, if you like, but suffice it to say that he’s a heavy-hitter in the world of geometric modeling kernels.  The kind of guy who doesn’t need to brag, because he’s done it.

Last week, I sent Dr. Stallings a copy of a paper that I’d found, titled Geometric Interoperability with Epsilon Solidity. I wrote about it here yesterday.  He kindly replied to me, and, surprisingly, took the time to tell me how he views interoperability. With his permission, I’m reprinting his email here, almost in its entirety.


Hi Evan,

Thanks for the paper on interoperability. It is interesting to see how the paper writing academia views the problems from time to time. While reading it I was left with the thought of “if only it were that easy”. I find that the tolerance problems, near tangent intersections, and topology mismatches are the smallest and easiest part of the problem.

The biggest problem for me is that the formats are constantly changing, and in some cases are intentionally encrypted. Ironically the intended solution to this problem—the creating of translated standards such as IGES, STEP and such—creates a new problem that accounts for the other half of all the problems that I see; that with an open standard, anyone—competent or not—can attempt to write files in the format. All too often we will see all types of mistakes made in simply making the file that range from small things like how a line is ended to larger things like missing data.

The other big problem is that geometry and topology are defined in radically different ways in different systems. One of my favorite examples is that in ACIS a cylinder is a cone and in ProE a sphere is a torus. Not a big problem but just one of many things that needs to be taken into account. Larger differences include such things as how the surfaces are parameterized. In some systems a sphere is parameterized as (latitude, longitude) in other systems (longitude, latitude). However, that is a simple flip; in the case of cones how the lateral parameterization is scaled, shifted, and flipped is more difficult. Nevertheless, the most difficult case is when it comes to advanced procedural surfaces such as blends, lofts, and such.

In the case of advanced procedural surfaces there can be many undocumented, cryptic, even unimplemented options. To add to the problem these surfaces are quite often near tangent with their neighboring surfaces or difficult to fit very accurately with general surface types such as NURBs. However, the largest problem of all is the existence of multiple flipping flags, flags to flip faces, edges, curves… get one of them wrong and all the understanding of topology, geometry, and tolerances is irrelevant.

However, I am digress. The most difficult problem with tolerances is not that one system uses one tolerance and another system uses another tolerance. The biggest problem is that some systems depend on curves in three dimensional space, and other systems depend on curves in the different two dimensional parameter space of the surfaces that they are on. The mis-match between parameter space and three dimensional space is a very big problem with ACIS and Parasolid using three dimensional space and Catia and ProE using parameter space. IGES and STEP punt by including one or both of the formats. The problem quite often comes from when both formats are included. All too often I will see a file that contains both 2D and 3D curves and the curves that were not used by the writing system are bad. IGES tries to fix this problem by actually providing a flag for the writer to set that tells which curves to trust. However, the existence of such a flag is a near admission of guilt, in that if both curves were always good, then it would not be needed.

However, the largest interoperability problem is not the format or tolerance, but the marketplace. When files are translated from expensive systems people buy less seats of that system and just rely on the ability to translate the files to less expensive systems. Hence, there is market pressure to not make the process easy. Nevertheless, no one wants to look like their files are impossible to translate because that could also decrease sales. Hence, we are left with the current situation, where fleas might be a problem until one considers how many people are employed in the flea collar industry.

  • http://www.kevindesmet.com Kevin De Smet

    Amazing insights into a real problem.

  • http://twitter.com/jchawner John Chawner

    I couldn’t agree more with Paul’s analysis. He’s covered virtually everything wrong with CAD interoperability.

  • Pingback: This Week in CFD | Another Fine Mesh

  • Anonymous

    Maybe I’m a little bit off topic. My view on interoperability isn’t technical for this comment. It seems to me roots of “interoperability” are going to the fact most of enterprise software businesses were built around “data ownership” concept. If you succeeded to own your customers’ data, your business is stable and successful. What do you think?

    • http://evanyares.com Evan Yares

      I think the historical roots of interoperability problems are both technical and business-driven. At one time, for example, CAD programs used different mathematical bases. But even in the 1970s, companies such as ComputerVision recognized that there was a business advantage to importing data, but no business advantage to exporting data.

      Funny thing about “data ownership.” It’s still a problem. You think you own your CAD data, but do you really?

      • Anonymous

        Here is the thing.. Google has an advantage of making data available, since it monetizes data traffic (ads). When/if enterprise vendors will be able to make a shift, it will become obvious that “exporting” data may have a significant business advantage. Again, I’m not saying that a new enterprise model will be the same as for Google. Just my thoughts about a possible alternative…

        • http://evanyares.com Evan Yares

          I think social issues will be a primary driver of any changes in the interoperability milieu. It’ll be interesting to watch that new enterprise model evolve.

  • Pingback: Does the modeling kernel matter? | Evan Yares