Article published in September 2009 on the Novedge blog.
When we move a file from an external CAD system to our favorite design system, we are asking a sophisticated algorithm to extract geometric data from the file and translate it into a different proprietary format. Unless you get your software directly from Harry Potter, a software engineer has done all the hard work required for the magic to happen.
Franco Folini
Data translation is a critical technology, but it can also be a source of frustration. As with many other essential technologies, the better it works, the less visible it becomes. When we move a file from an external CAD system to our favorite design system, we are asking a sophisticated algorithm to extract geometric data from the file and translate it into a different proprietary format. Most of the time, the algorithm will accomplish this little magic, and the entire process goes almost entirely unnoticed. Unless you get your software directly from Harry Potter, a software engineer has done all the hard work required for the magic to happen. If you get your translation software from TransMagic, the person behind the scenes who creates and tunes the algorithms is Craig Dennis, TransMagic‘s CTO. With Craig’s interview, I’m trying to unveil some of that hidden magic and get Craig’s take on the most common problems encountered in data translation.
The Interview with Craig Dennis
Franco Folini: Hi, Craig! Can you tell us a bit about yourself and TransMagic?
Craig Dennis: My educational background is in Industrial Design and Mechanical Engineering. My career started as a Tool & Die Designer 17 years ago at a large machine shop, where I did tooling for the plastics packaging industry. I moved into design engineering for the same industry. My CAD experience has always been in 3D, starting with CADKEY, then SDRC I-DEAS and Pro/ENGINEER (although I actually learned to draw and perform projections on an actual drawing board in college).
I felt the pain with 3D and data exchange from the beginning of my career. In those days, all we had were IGES and STEP, and really, mainly just IGES. I’ve personally seen hundreds of thousands of dollars wasted on tooling cut to IGES surfaces due to faulty translation in the plastics packaging industry. The waste in Automotive, Aerospace, Heavy Equipment, PowerGen, and on and on due to data translation issues is simply astronomical.
My career then transitioned to software engineering, and I worked for a 3D software component supplier, Spatial, as an Application Engineer. I educated prospects and customers on the proper use and implementation of the ACIS kernel in C++. This leap from the trenches of manufacturing to the manufacturing software industry rewarded me with a well-rounded understanding of manufacturing’s needs as they relate to software providers. The single most lasting impression I had from those years was that data exchange was an even bigger issue than I realized as an end user.
In 2001, I became CTO and partner at TransMagic, Inc., with the goal of capitalizing on my unique, broad-scope perspective on the manufacturing industry and applying my lessons and knowledge to perfect 3D data exchange.
I felt the pain with 3D and data exchange from the beginning of my career.
Craig Dennis
Franco Folini: Data translation and data visualization are two markets with a certain overlap. Do you consider them as separate, or do you believe they require different products and different approaches?
Craig Dennis: I consider them separate technologies that belong together. In fact, that was the exact premise of our first product at TransMagic, back in the days of “black box” CAD translators that output geometry you didn’t know was faulty until you tried to open it in your CAD system. Who wouldn’t want to see their file before and after translation to do a quick visual validation if nothing else? In this way, 3D visualization and data visualization address a similar need. The big difference comes when you need to perform downstream engineering operations on the translated data. For that, you need real geometry, not triangles. There is a lot of important geometric information that is unavailable in triangulated models.
For the same reason, geometric data translation, validation, and repair can only work on true geometry. In fact, this is a very difficult and intensive science unto itself. In geometric data translation, highly sophisticated, specialized geometric algorithms are needed to properly map surface geometry from one format to another for downstream manufacturing. In purely visual terms, these algorithms are simply not required.
Data translation applications will typically persist the 3D math data in memory (RAM), where it’s always accessible for highly precise calculations. As a result, data translation apps will have a leg up on pure visualization apps in areas such as precise measurements, mass property calculations, and procedural-based polygon output, as used in high-precision STL output.
I consider visualization & translation separate technologies that belong together.
Craig Dennis
Franco Folini: In many areas of software, data translation is now considered a solved problem. Not so for CAD applications. What are the reasons moving data from one system to another is still a big issue?
Craig Dennis: The reasons are multi-fold, and each CAD vendor can likely cite one of these areas, if not publicly then internally, as the cause:
- First, there is the “single source” phenomenon, in which an engineering software provider develops applications (or add-ons) for the CAD, CAM & CAE specialties. For these companies, it is in their best interest to interoperate seamlessly between their own apps so they can provide their customers with a complete software solution. As such, it is clearly NOT in the best interests of these software firms to offer seamless interoperability with their competitors’ engineering apps, thereby losing potential revenue.
- Second, there is the complexity of 3D data exchange: Many engineering app developers are specialists in their own engineering space. Most of their development resources go to refining that specialty. 3D data exchange is a science and specialty unto itself. Sure, a sphere is a sphere, and a plane is a plane, but that view is overly simplistic. There are myriad geometric surface types, and the mathematics for each differs greatly. Likewise, the technology behind each modeling kernel differs significantly. An engineering application developer might be an expert in their 3D modeling technology, but they are typically not experts in all of them, nor do they have the bandwidth to perfect 3D data translation.
- Third, is version compatibility: Unlike some electronic formats, 3D geometric formats can and do change, constantly. Simply keeping up with these formats is a resource-intensive pursuit.
Finally, 3D data translation is not a commodity. At TransMagic, Inc. (and I would wager many of our industry contemporaries would agree), the problem of 3D data translation is largely solved. The 3D interoperability market is getting more mature. TransMagic and our contemporaries have spent the better part of the last two decades perfecting this task. The proliferation of 3D data is very mature. The difference we’re seeing now is that companies want to include all manufacturing data in a single file alongside the 3D model. There is no single commodity solution that integrates all the different CAD systems and data types. In the end, I believe it comes down to niche markets and qualities like ease, automation, and affordability.
The 3D data translation needs of the engineering software community cannot be adequately addressed solely by the engineering software developers themselves. Instead, a specialist software developer has emerged to address this need: The 3D Data Translation Expert…and the need for high-quality 3D data translation has been met. It’s our mission to get the word out.
At TransMagic, the problem of 3D data translation is largely solved.
Craig Dennis
Franco Folini: STL is consolidating its role as a key technology in every design and product development process. What user problems and issues is your recent new product, STL PRO, addressing?
Craig Dennis: We have always offered STL output since our first release. Our STL PRO is a special package to address the specific needs of the Rapid Prototype (RP) market while keeping costs down. STL PRO addresses the common problem of obtaining high-quality STL files by enabling end users to receive multiple native CAD formats from customers, rather than receiving STL files directly. This approach eliminates the other main issue we routinely hear from RP users: low-quality STL files coming from their customers’ CAD systems. While most CAD systems can output STL files, their resolution is typically very limited. In many cases, the highest-resolution STL file from a CAD system is barely usable as a rough draft by most RP bureaus.
The STL PRO approach: Obtain native CAD files from your prospects and use STL PRO to generate the STL output. This is also a welcome change for the RP bureau’s customers, as they no longer have to go through the additional steps of generating multiple STL files. In addition, STL PRO’s STL output is infinitely refineable, producing draft-quality all the way up to extreme-precision STL files. Our STL File Settings and procedural-based STL triangle generation consistently produce high-quality STL files from a solid.
STL PRO addresses the common problems of getting good quality STL files by enabling the end user to receive multiple native CAD formats from customers vs. receiving STL files themselves.
Craig Dennis
Franco Folini: TransMagic seems to be moving from a standalone approach to a more integrated plug-in architecture. What are the benefits for the end user and the implications of these changes? Is Data Translation going to become a technology hidden from the end user and embedded into software systems?
Craig Dennis: TransMagic is built on a sophisticated plug-in architecture that enables a high level of flexibility in its product offerings. The TransMagic GUI, Inventor Add-Ins, SolidWorks Add-Ins, and other partner applications from companies such as VX CAD/CAM, Dimensional Control Systems, and NGRAIN can all use the same TransMagic translation core behind the scenes. This approach is helpful for companies that choose not to re-create the wheel and become translation experts. For our customers, this means they can buy best-in-class products, and there is no code duplication with an optimized product offering. For anyone who uses the product, this means that they will experience consistent results using any application that is “Powered by TransMagic”.
Our product interface is fully documented and callable by any scripting or programming language. Most users are up and running with it within 10 minutes. It can easily be integrated with a PLM system or a custom in-house application to process jobs automatically. In fact, PTC Windchill users can now add a plug-in to their PLM that outputs to any format, not just a PRT file (Powered by TransMagic, of course).
Our new Auto Repair Wizard makes about 100 checks before it gives the green light, meaning the geometry has been validated. We automatically detect and resolve most translation issues during translation with this Wizard. The end user no longer needs to have expertise in 3D Data Translation. In most cases, it is as simple as File->Open/File->Save when using TransMagic or an application powered by TransMagic.
For anyone who uses the product, this means that they will experience consistent results using any application that is “Powered by TransMagic.
Craig Dennis
Franco Folini: Working on Data Translation and Visualization software means working with a schedule largely defined by the new releases of the major CAD systems. How do you manage a development process in such a constrained context?
Craig Dennis: We employ the Agile development philosophy and approach. This entails fully implementing, testing, and documenting features and fixes as they are completed. With this philosophy, TransMagic is never more than 2 weeks away from releasing products. However, our typical release (or service pack) cycle every three months usually aligns pretty well with the adoption rates of new CAD versions.
Another unique methodology that TransMagic has adopted is licensing the “CAD engines” directly from the various CAD vendors. We are very CAD-neutral and try to encourage our customers to use native file formats where possible. We go directly to the source and license the CAD engine from the developer. This provides three primary benefits: quality, performance, and support for the current version. When many new CAD versions are released, we’re ready to go live simultaneously.
When many new CAD versions are released, we’re ready to go live simultaneously.
Craig Dennis
Franco Folini: What are the most common mistakes of end users when moving data from one system or format to a different one?
Craig Dennis: The most common mistake is using an IGES file when you could have used a native file or any other format. Our philosophy is to use native CAD parts or assemblies, and when they are processed through TransMagic, it’s a “mapping” from one kernel to another, rather than a typical translation scenario such as IGES or STEP. We can readily handle IGES or STEP files, of course, but most contemporary CAD kernels are very high-quality, including ACIS and Parasolid. By accurately mapping geometry from one kernel to another, the process of using TransMagic is as simple as File->Open/File->Save.
Another very common mistake is that most people underestimate the power of using ACIS and Parasolid files for interoperability. When properly implemented, these two CAD kernels provide a very robust geometry engine for hundreds of engineering applications. If your source and target applications support ACIS or Parasolid natively, chances are those formats will yield the same results as a native CAD file. It’s a quantum leap from IGES and is typically better than STEP.
While moving CAD data the most common mistake is using an IGES file.
Craig Dennis
Franco Folini: If you were a CAD manager and had to choose a file format for the long-term archival of your company’s strategic data, which file format would you choose, and why?
Craig Dennis: This is an important question. Our recommendation is: Use Every Format Possible. For example, if you have a 50+ year archive requirement, don’t wager your whole future on one format such as STEP or IGES. We advocate saving them into many formats. This way if one or more of the archive formats becomes obsolete, you still have back-ups including the native CAD files themselves. Storage is now pennies per megabyte and getting cheaper all the time. This is an area where our TransMagic COMMAND interface becomes particularly valuable especially when integrated into an existing PLM/PDM system. For every PLM/PDM trigger, such as a design revision, the PLM/PDM system can make one single call to TransMagic and simultaneously produce any or all formats we support. Good future bets for archival in addition to the native CAD format itself would be: ACIS, Parasolid, JT (w/B-Rep), STEP and even IGES Solids (MSBO). The reason I mention the native CAD format commonly is that unless the CAD system becomes defunct (which can happen), TransMagic will continue to support even the earliest versions of the CAD systems and the native format may still be the first and best format to access years from now.
For the long term archival, use every format possible!
Craig Dennis
I would like to thank Craig Dennis for taking the time to answer my questions.
