Are you still in the “darkroom” about CAD file formats?

Using drawings to create product documentation is like using chemistry for photos instead of a digital camera

We’re back from a long holiday weekend here in the US, and I wanted to pick up the discussion thread started last week when we posted our assertion that the file translation problem has been solved.

Articulating that fact resulted in this comment from Deelip Menezes:

In the response to Scott Shepard, Alex says, “the manic focus on converting things obscures the need to do something with the info”. I could not agree more. I have a small question though. How the hell are you going to do something worthwhile with the info if you do not have the correct info to begin with?

With apologies to Deelip, I don’t want to get pulled into the sub-topic of file-format conversion accuracy, because that is, ahem, a religious war without solution.

Suffice it to say that I am happy to use a digital camera for my picture taking today and that I no longer retreat into the basement, block all light and spend hours with dangerous chemicals in order to produce snapshots of the family cookout. Is the darkroom “better,” more “accurate”? Arguably. But it’s also less useful. And, it’s a barrier to picture taking itself because I have added time and expense to develop the photos.

That was our point: 3D design data today is bottled up in engineering and design, hostage to fanatical worrying about “accuracy” (like having to have precisely the right temperature for the developer in a darkroom) and prisoner to the extra effort needed to “develop” it for use outside engineering.

One of my colleagues in Seemage, Garth Colman, sent me this comment after reading Deelip’s post:

Geometry-based CAD translators are a dime a dozen, full of all the necessary healing features, and are cheap. So yeah, they’re necessary, but the translator itself does not add value, it’s what you do with the translated data. If [Deelip] wants to start a thread about the “quality” or “accuracy” of translated data, fine. It’s only a relevant point in the world of engineering, it adds zero value to external departments. And that’s the entire point of [the post]… that engineers only think about engineering…

If Kodak has stopped selling film cameras, it’s time for MCAD to stop worrying about previous-generation issues and come out of the darkroom.

3 comments to Are you still in the “darkroom” about CAD file formats?

  • Deelip Menezes  says:

    True, the translation process does not add any value and I don’t think anyone claims that it does.

    I am not talking about accuracy about translated data here. Poorly translated data, such as cracks in a solid model, may sometimes be fixed using healing techniques, although even they are not guaranteed to work. I am talking about missing, incorrect or incomplete data. I will try to drive the point in here by taking Seemage for an example.

    Imagine that you import an IGES file of an aircraft engine to create an animation in Seemage and find that the propeller fan is missing? The act of importing the IGES file does not add value. The act of animating the engine does. But what is the use if you do not have the fan to animate in the first place?

    It seems to me that your assumption that all CAD translations happen “accurately” and “completely” forms the basis of your assertion that the CAD file translation problem has been solved. I am afraid, your assumption itself is flawed and I have been in the CAD translation business long enough to assert that.

  • Garth Coleman  says:

    Deelip, if you are saying that the IGES files does not contain the propeller fan to begin with, then I agree that this would be a problem. If someone is asking me to animate their engine but then fails to give me the necessary data to do that, then there is something wrong with the process of collecting the data prior to translation.

    If, however, you are suggesting that the propeller fan actually is in the IGES file, but it is failing to be extracted for some reason or another (or perhaps it was not exported properly into the IGES file to begin with), then I agree it would be problematic. Bad geometry can be fixed, missing geometry cannot.

    So underlying all of the value added capabilities of reusing such geometry, there is an important need to have this data made available – from the initial collecting of data, to the exporting and importing of that data. It’s the geometry “gas” that goes into our Seemage “car” – no geometry, no gas, no race.

    Our main point is that these geometry exchange issues have a variety of solutions available. Many of them work and provide either the process framework and/or the tracking and reporting of exchanged data, and so on. And if one format doesn’t work, you can always pick from a host of other formats. We agree that this is an important issue relative to the need to share and use engineering data, and there are a number of vendors in this area that one can evaluate and ultimately choose for their engineering collaboration needs.

    But for adding true value to this data, there is only one Seemage.

  • Chris  says:

    Unfortunately the world is not absolute black or white, but that said at the end of the day while it may be fair to say translators could get better, it is truer that people are delivering products to market without a lot of fan fare on the translations required. It is also true that there are companies out there stating they can add value or maybe preserve more value – look at the failed link to proficiency.com. What I find interesting about the feature translation approach they have been pushing for years is it seems to fall on deaf ears… if translation is such a wonderful time waster and reduces a team’s ability to get product to market, then why wasn’t proficiency a smashing success? Even if it only worked 80% wouldn’t people invest in order to make sure they got 100%?

Leave a reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.