CAD interoperability: blast from the past (#ThrowbackThursday)

September 6, 2018Debankan Chattopadhyay

No it’s not 1999, but it is #ThrowbackThursday So why not use this opportunity to talk of CAD interoperability as it relates to feature-based translations?

People have been discussing transfer of fully-featured CAD models for years now. But do people really need feature-based translations? And if they do, should it be handled via automated software or manual service?

Given that there aren't really any fully automated tools around that transfer 100% of features/parametrics from one CAD system to another, and leading CAD ISVs already have the capability to import multi-CAD data (thanks to our multi-CAD interop toolkits!), is there still a case to be made for standalone feature translation tools? Direct editing capabilities and built-in feature recognition tools in most CAD systems today are mature enough to recognize fillets, chamfers, simple holes etc. and one can argue, serve as a great workaround.

So I ask again - why are we still discussing feature-based translations after all these years? Because it’s still the Holy Grail of CAD interoperability and no, there isn’t a perfect solution in the market. Let’s pretend to be 4-year olds and play the “Why” game for a moment. There isn’t a perfect feature-based solution. Why? Because different CAD systems have different features. Why? Because they represent parametrics in different ways? Why? Because they have different data models? Why? Because they are not all based on the same kernel? Why? Because…ok, let’s stop. You get the picture

The reason why feature-based translators haven’t caught fire in the turnkey end-user CAD translator space is precisely because it can’t be fully automated in a way that the output is readily usable. Go back and read that last italicized part again. That is key to whatever we will discuss next.

Without some level of manual intervention, there is no “perfect” solution. Some might argue that providing output that is even partially parametric (say, 40%) is still a good start. To those people I say, instead of using unreliable feature-based translation tools, why not pick from our roster of reliable B-rep viewer/translator software instead, and then use some feature recognition tool on the (loss-less) translated b-rep data? If you are willing to settle for translation to neutral formats (like IGES & STEP), perhaps EnSuite-Lite will work for you. If not, you might want to explore EnSuite for direct translation to native formats like CATIA V5, NX, SOLIDWORKS etc.

So, what’s the point I’m making? The point is that there is no reliable way today, and there hasn’t been one in years, to translate features & parametrics from one CAD system to another using turnkey feature-based translation tools. And this has more to do with technical constraints, than business. Given the constraints we have, there really are three different options:

(a) CAD ISVs continue adopting our data interoperability toolkits to access features directly in their software and to provide end-users a seamless experience if they choose to use the in-built feature recognition tools on the imported data;

(b) End-users use reliable & robust standalone b-rep translation tools like EnSuite and EnSuite-lite and then use the CAD system’s feature recognition tools;